यह एक छोटी सी श्रृंखला है जिसे मैं एडब्ल्यूएस पर "लागत अनुकूलन" की मूल बातें के बारे में लंबे समय से साझा करना चाहता था।

आइए इस यात्रा की शुरुआत DocumentDB से करते हैं!

अगर आपको यह पोस्ट पसंद आया हो तो करने में संकोच न करें;)

ठीक है, सच कहूं तो, यह शीर्षक क्लिकबेट * है।

मैं निश्चित रूप से कुछ लिख सकता था जैसे "मैंने दस्तावेज़ीकरण में प्रदान किए गए कुछ सामान्य दिशानिर्देशों का सम्मान करके हमारे एडब्ल्यूएस आधारभूत संरचना पर लागत अनुकूलन कैसे किया " लेकिन यह कम आकर्षक है, नहीं?

हो सकता है कि आप में से कुछ लोग इन तरकीबों और अच्छे अभ्यासों को पहले से ही जानते हों।

यदि आप सीधे उस चेकलिस्ट की तलाश कर रहे हैं जिसका मैं सुझाव दे रहा हूं, तो यहां स्क्रॉल करें।

DocumentDB सेवा से जटिल I/O लागत को समझें

यदि आप उनके मूल्य निर्धारण पृष्ठ को देखें, तो यह 4 लागत आयामों से विभाजित है, मैं इसे यहां फिर से शुरू करता हूं:

• उदाहरण की कीमत : अच्छी तरह से यह लागत जल्दी समझ में आती है: आप एक उदाहरण के लिए भुगतान करते हैं, और मूल्य निर्धारण इसके संसाधनों (सीपीयू, रैम, आदि) पर निर्भर करेगा।
• भंडारण और बैकअप भंडारण लागत : ऊपर के समान, यह काफी समझ में आता है, और हम आसानी से उनकी लागतों को ट्रैक और अनुमान लगा सकते हैं, एडब्ल्यूएस बिल प्रति जीबी संग्रहीत। वैध।
• सबसे मुश्किल हिस्सा डेटाबेस I/O है : AWS 0.20$ और 0.30$ (उदाहरण के क्षेत्र के आधार पर) प्रति 1 मिलियन I/O के बीच बिल करेगा !!

तो, I/O के पीछे क्या है?

AWS बताता है कि DocumentDB सेवा के साथ, आपको पहले से I/O संसाधनों का प्रावधान करने की आवश्यकता नहीं है, जो कि दिलचस्प है, क्योंकि आपके पास भंडारण सीमाएँ नहीं हैं और आप आसानी से I/O संचालन का चयन कर सकते हैं। यह उचित लगता है, क्योंकि आप उपयोग के लिए बिल हैं।

AWS अपने दस्तावेज़ीकरण में वर्णन करता है कि I/O संचालन में क्या शामिल है, यह मुख्य रूप से सभी संचालन जैसे ढूँढना, सम्मिलित करना, अद्यतन करना और हटाना या कुछ सुविधाएँ जैसे परिवर्तन धाराएँ और TTL (रहने का समय) अनुक्रमणिकाएँ हैं।

खैर, स्टोरेज वॉल्यूम को प्रभावित करने वाली हर चीज का बिल आपको दिया जाएगा।

रुको, क्या, 0.20$ प्रति मिलियन I/O?

आइए, अभी AWS को पैसे गंवाने दें!

AWS DocumentDB प्रलेखन पर एक वाक्यांश है जो आपकी आँखों को पकड़ लेगा (और बटुआ ):

एक बार, डेटा को स्टोरेज वॉल्यूम से पढ़ लिया गया है और मेमोरी में रहना जारी रखता है, उसी डेटा के बाद के पढ़ने पर अतिरिक्त I/Os नहीं लगते हैं।

यह वाक्यांश यह समझने की कुंजी है कि I/Os के पीछे क्या है।

कौन से ऑपरेशन कम I/Os का उपयोग करते हैं?

अनुक्रमणिका का उपयोग करने वाली क्वेरीज़ कम I/Os का उपयोग करेंगी क्योंकि आप अपने संग्रह के संपूर्ण संग्रहण को स्कैन नहीं कर रहे हैं। यह निश्चित रूप से I/Os का उपभोग करेगा लेकिन पूरे संग्रह को स्कैन करने से कम है।

इसके अलावा, आपके इंस्टेंस की रैम को आपके इंडेक्स आकार को कवर करने की आवश्यकता है, यह आपको अतिरिक्त I/Os नहीं करने की अनुमति देगा।

कृपया ध्यान रखें कि आपको अनुक्रमणिका उपयोग के साथ कुछ सिद्धांतों का सम्मान करने की आवश्यकता है।

चेकलिस्ट

जब आप अपने I/O उपयोग को अनुकूलित करना चाहते हैं और अपनी लागत कम करना और प्रदर्शन में सुधार करना चाहते हैं तो मेरी सलाह/चेकलिस्ट यहां दी गई है।

आप देखेंगे कि मैं एक प्रतिभाशाली व्यक्ति नहीं हूं क्योंकि मैं एडब्ल्यूएस दस्तावेज़डीबी दस्तावेज़ीकरण पृष्ठ से कुछ सामान्य सर्वोत्तम प्रथाओं के साथ जानकारी एकत्र करता हूं जो दस्तावेज़ डीबी पर सख्ती से लागू नहीं होते हैं।

अपने दिमाग को सिद्धांतों से तरोताजा करना हमेशा अच्छा होता है।

• 🧠 सबसे पहले, इसे याद रखें : कम I/O = सस्ता = बेहतर प्रदर्शन, यहां यह लागतों के बारे में नहीं है या सभी प्रदर्शनों के बारे में नहीं है, लेकिन दो चीजें जुड़ी हुई हैं।

• अप्रयुक्त अनुक्रमणिका निकालें : आप नहीं जानते कि एक व्यस्त संग्रह के लिए अप्रयुक्त अनुक्रमणिका कितनी महंगी है। मैंने अपनी कंपनी को की तरह ही 2,000$/माह की बचत की, अप्रयुक्त अनुक्रमणिका को हटाकर। और इस क्वेरी के साथ अप्रयुक्त अनुक्रमणिका को ट्रैक करना बहुत आसान है:

  
  

सूचकांक आँकड़े क्वेरी

क्वेरी फ़ील्ड ops को आउटपुट करेगी जो आपके इंडेक्स के हिट होने की संख्या के अनुरूप है। आपके आवेदन के भार के आधार पर, कृपया अप्रयुक्त अनुक्रमणिका को हटाने पर विचार करें।

• प्रदर्शन अंतर्दृष्टि और प्रोफाइलिंग संचालन सक्रिय करें: यदि आप आरडीएस का उपयोग करते हैं, तो आप प्रदर्शन अंतर्दृष्टि से अवगत हो सकते हैं, यह आपको कुछ बहुत उपयोगी मीट्रिक और उन प्रश्नों के बारे में जानकारी देता है जो आपके दस्तावेज़ डीबी प्रदर्शन को प्रभावित कर रहे हैं, और आप उन प्रश्नों को जल्दी से देख सकते हैं जो मुझे उपभोग करते हैं I /ओएस संचालन (और उनमें से राशि), इसलिए आसानी से एक बाधा को ट्रैक करना बहुत अच्छा है। धीमी क्वेरी या कॉलस्कैन प्रश्नों की निगरानी करने का एक अन्य तरीका प्रोफाइलिंग संचालन को सक्रिय करना है, जैसा कि नाम से पता चलता है कि यह आपके लिए कुछ संचालन (यहां अधिक जानकारी प्राप्त करने के लिए एक लिंक है:), आप एक थ्रेशोल्ड सेट कर सकते हैं जो क्लाउडवॉच पर एक लॉग डाल देगा ऑपरेशन जो n ms से अधिक ले रहा है। उदाहरण के लिए COLLSCAN निष्पादित करने वाली क्वेरी की संख्या को ट्रैक करने के लिए बहुत उपयोगी है। कृपया इन दोनों विकल्पों को सक्रिय करें क्योंकि ये बहुत मूल्यवान हैं!

  
  

• 💾 अपने डेटा को हमेशा पहले देखें : यदि आप इंडेक्स कार्डिनैलिटी की अवधारणा के अभ्यस्त नहीं हैं, तो आपको सबसे अच्छे हाई-कार्डिनैलिटी फ़ील्ड की पहचान करनी होगी, जिसे आप इंडेक्स करना चाहते हैं, AWS DocumentDB के दस्तावेज़ीकरण को अच्छी तरह से समझाया गया है :)

  
  

• छोटे पेचीदा संग्रहों से बचें : यदि आप एक संग्रह की योजना बना रहे हैं जिसमें तीन फ़ील्ड होंगे जिनमें से एक में एक अद्वितीय कुंजी होगी, और यदि आप बहुत सारे अपडेट/आवेषण करने की योजना बना रहे हैं, तो कृपया अपने संग्रह के मॉडलीकरण पर विचार करें, क्योंकि आपके I/O ऑप्स नरक की तरह हिट होंगे और इसलिए आपका I/O उपयोग।

  
  

• ️ टीटीएल, उर्फ टाइम-टू-लीव इंडेक्स से बचें : (ज्यादातर समय) आप इसे टाइम-टू-लीव इंडेक्स सेट किए बिना संभाल सकते हैं, इसलिए कृपया जांच लें कि इंस्टेंस या क्लस्टर पर टीटीएल पैरामीटर सक्षम नहीं है।

  
  

• समझाओ! जब आप एक नई क्वेरी (या नहीं) बना रहे हों, तो क्वेरी प्लानर की इंडेक्स चयनात्मकता की जांच करने का एक बहुत ही सरल तरीका है executionStats पैरामीटर के साथ एक व्याख्या ऑपरेशन करना। आपको आश्चर्य होगा कि कुछ प्रश्न जो आप हिट इंडेक्स के बारे में सोच रहे हैं, बस किसी भी इंडेक्स को हिट न करें ...

  
  

• ️ बूलियन फ़ील्ड के लिए इंडेक्स न बनाएं । बस मत करो। कार्डिनैलिटी याद रखें।

  
  

• ️ इस आदेश के साथ आपके पास मौजूद प्रत्येक संग्रह के लिए किसी ऑब्जेक्ट के औसत आकार की निगरानी करें : db.<mycollection>.stats(1024) एक चरम औसत आकार आपके प्रश्नों पर जल्दी से लॉक बना सकता है और I/Os ops बढ़ा सकता है क्योंकि RAM आपका उदाहरण पर्याप्त नहीं है। कृपया वस्तुओं की बारीकी से निगरानी करें और अनावश्यक क्षेत्रों को संग्रहित न करें। यदि आपको कई फ़ील्ड संग्रहीत करने की आवश्यकता है, तो सभी फ़ील्ड का चयन न करके प्रश्नों को अनुकूलित करने पर विचार करें।

  
  

• ️ ध्यान रखें कि DocumentDB MongoDB नहीं है। यह मुख्य रूप से मोंगोडीबी के साथ संगत है लेकिन यह मोंगोडीबी नहीं है क्योंकि कुछ छोटे विशिष्ट व्यवहार हैं। उदाहरण के लिए, यदि आप $regex ऑपरेटर के साथ कोई क्वेरी निष्पादित करना चाहते हैं, तो आपको 'संकेत()' की आवश्यकता होगी, क्योंकि यह अनिवार्य है। बहिष्करण ऑपरेटर कभी भी किसी अनुक्रमणिका का उपयोग नहीं करेंगे, इसलिए कृपया अपनी अनुक्रमणिका बनाते या अनुकूलित करते समय इन व्यवहारों पर विचार करें!

  
  

• कभी इशारा न करें। ऊपर वर्णित बहुत विशिष्ट उपयोग-मामलों को छोड़कर, आपको hint के उपयोग से बचना चाहिए, ध्यान रखें कि यदि क्वेरी प्लानर आपकी अनुक्रमणिका का चुनाव नहीं करता है, तो यह एक अच्छे कारण के लिए है। अधिकांश समय ऐसा इसलिए होता है क्योंकि यह संग्रह से सभी दस्तावेज़ों के बजाय अनुक्रमणिका को स्कैन करने के लिए लंबा या समकक्ष होता है।

• 
  

आशा है कि आप मेरी कंपनी के लिए एडब्ल्यूएस लागत अनुकूलन पर काम करते समय सीखी गई इन युक्तियों की सराहना करेंगे।

एक और पोस्ट के लिए बने रहें!

अगर आपको यह पोस्ट पसंद आया हो तो करने में संकोच न करें;)

पुनश्च: अगर कुछ गलत या गलतफहमी लगती है, तो मुझे डीएम करने में संकोच न करें।

यहाँ भी प्रकाशित