MongoDB में धीमी क्वेरी से निपटना

उत्पादन में होने पर, किसी एप्लिकेशन को आपके एप्लिकेशन के साथ उपयोगकर्ता इंटरैक्शन को बेहतर बनाने के उद्देश्य से उपयोगकर्ता को समय पर प्रतिक्रिया प्रदान करनी चाहिए। हालांकि, कभी-कभी, डेटाबेस क्वेरीज़ पिछड़ने लगती हैं, इसलिए उपयोगकर्ता तक पहुंचने के लिए प्रतिक्रिया के लिए लंबी विलंबता लगती है या सेट औसत टाइमआउट को पार करने के कारण थ्रूपुट ऑपरेशन समाप्त हो जाता है।

इस ब्लॉग में हम यह जानने जा रहे हैं कि आप MongoDB में इन समस्याओं की पहचान कैसे कर सकते हैं, जब भी वे उत्पन्न हों तो उन्हें ठीक करने के तरीके और संभावित रणनीतियाँ क्या हैं ताकि ऐसा दोबारा न हो।

अक्सर, धीमी क्वेरी प्रतिक्रियाओं के कारण सीपीयू की क्षमता में गिरावट आती है जो अंतर्निहित कार्य सेट का सामना करने में असमर्थ होती है। इस मामले में वर्किंग सेट डेटा और इंडेक्स की मात्रा है जो उस पल में सक्रिय थ्रूपुट इंस्टेंस के अधीन होगा। यह विशेष रूप से क्षमता नियोजन में माना जाता है जब किसी को समय के साथ शामिल डेटा की मात्रा और आपके प्लेटफ़ॉर्म से जुड़े उपयोगकर्ताओं की संख्या में वृद्धि की उम्मीद होती है।

एक धीमी क्वेरी समस्या की पहचान करना

MongoDB में धीमी क्वेरी की पहचान करने के दो तरीके हैं।

1. प्रोफाइलर का उपयोग करना
2. db.currentOp() हेल्पर का उपयोग करना

MongoDB प्रोफाइलर का उपयोग करना

MongoDB में डेटाबेस प्रोफाइलर एक चल रहे mongod उदाहरण के विरुद्ध निष्पादित डेटाबेस कमांड के बारे में विस्तृत जानकारी एकत्र करने के लिए एक तंत्र है:थ्रूपुट संचालन (बनाएं, पढ़ें, अपडेट करें और हटाएं) और कॉन्फ़िगरेशन और प्रशासन आदेश।

प्रोफाइलर सिस्टम.प्रोफाइल नामक एक कैप्ड संग्रह का उपयोग करता है जहां यह सभी डेटा लिखता है। इसका मतलब है, जब संग्रह आकार के मामले में भरा होता है, तो नए डेटा के लिए जगह देने के लिए पुराने दस्तावेज़ हटा दिए जाते हैं।

प्रोफाइलर डिफ़ॉल्ट रूप से बंद है लेकिन प्रोफाइलिंग स्तर के आधार पर कोई इसे प्रति-डेटाबेस या प्रति उदाहरण पर सक्षम कर सकता है। संभावित प्रोफाइलिंग स्तर हैं:

• 0 - प्रोफाइलर बंद है इसलिए कोई डेटा एकत्र नहीं करता है।
• 1 - प्रोफाइलर उन कार्यों के लिए डेटा एकत्र करता है जो धीमी गति के मान से अधिक समय लेते हैं
• 2- प्रोफाइलर सभी कार्यों के लिए डेटा एकत्र करता है।

 हालांकि, प्रोफाइलिंग को सक्षम करने से डेटाबेस और डिस्क उपयोग पर एक प्रदर्शन प्रभाव उत्पन्न होता है, खासकर जब प्रोफाइलिंग स्तर 2 पर सेट होता है। किसी प्रोडक्शन परिनियोजन पर प्रोफाइलर को सक्षम और कॉन्फ़िगर करने से पहले किसी भी प्रदर्शन प्रभाव पर विचार करना चाहिए।

प्रोफाइलिंग सेट करने के लिए, हम db.setProfilingLevel() हेल्पर का उपयोग करते हैं जैसे:

db.setProfilingLevel(2)

एक नमूना दस्तावेज़ जो सिस्टम में संग्रहीत किया जाएगा। प्रोफ़ाइल संग्रह होगा:

{ "was" : 0, "slowms" : 100, "sampleRate" : 1.0, "ok" : 1 }

“ok”:1 की-वैल्यू पेयर इंगित करता है कि ऑपरेशन सफल हुआ जबकि स्लोम्स मिलीसेकंड में थ्रेशोल्ड समय है जो एक ऑपरेशन को लेना चाहिए और डिफ़ॉल्ट रूप से 100ms है।

इस मान को बदलने के लिए

db.setProfilingLevel(1, { slowms: 50 })

सिस्टम के विरुद्ध डेटा के लिए पूछताछ करने के लिए।प्रोफाइल संग्रह रन:

db.system.profile.find().pretty()

db.currentOp()helper का उपयोग करना

यह फ़ंक्शन वर्तमान चल रहे प्रश्नों को बहुत विस्तृत जानकारी के साथ सूचीबद्ध करता है जैसे कि वे कितने समय से चल रहे हैं। चल रहे मोंगो खोल पर, उदाहरण के लिए आप टिप्पणी चलाते हैं:

db.currentOp({“secs_running”:{$gte:5}}) 

जहां secs_running फ़िल्टरिंग रणनीति है, ताकि आउटपुट को कम करने के लिए केवल 5 सेकंड से अधिक समय लेने वाले संचालन को वापस किया जा सके। इसका उपयोग अक्सर तब किया जाता है जब सीपीयू के स्वास्थ्य को प्रतिकूल प्रदर्शन प्रभाव के कारण 100% रेट किया जा सकता है, यह डेटाबेस पर प्रभाव डाल सकता है। इसलिए मूल्यों को बदलकर आप सीखेंगे कि किन प्रश्नों को निष्पादित करने में अधिक समय लग रहा है।

लौटाए गए दस्तावेज़ों में रुचि की कुंजी के रूप में निम्नलिखित हैं:

• क्वेरी :क्वेरी में क्या शामिल है
• सक्रिय : अगर क्वेरी अभी भी जारी है।
• ns :संग्रह का नाम जिसके विरुद्ध क्वेरी निष्पादित की जानी है
• सेकंड_रनिंग :  वह अवधि जो क्वेरी ने अब तक सेकंडों में ली है

जिन प्रश्नों में अधिक समय लग रहा है, उन्हें हाइलाइट करके, आपने यह पहचान लिया है कि CPU क्या ओवरलोड कर रहा है।

परिणामों की व्याख्या करना और समस्याओं को ठीक करना

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

यदि व्याख्या सहायक वापस आता है

{

   "queryPlanner" : {

         "plannerVersion" : 1,

         ...

         "winningPlan" : {

            "stage" : "COLLSCAN",

            ...

         }

   },

   "executionStats" : {

      "executionSuccess" : true,

      "nReturned" : 3,

      "executionTimeMillis" : 0,

      "totalKeysExamined" : 0,

      "totalDocsExamined" : 10,

      "executionStages" : {

         "stage" : "COLLSCAN",

         ...

      },

      ...

   },

   ...

}

queryPlanner.winingPlan.stage:COLLSCAN कुंजी मान इंगित करता है कि परिणामों की पहचान करने के लिए mongod को पूरे संग्रह दस्तावेज़ को स्कैन करना पड़ा, इसलिए यह एक महंगा ऑपरेशन बन जाता है जिससे धीमी क्वेरी होती है।

executionStats.totalKeysExamed:0 का अर्थ है कि संग्रह अनुक्रमण रणनीति का उपयोग नहीं कर रहा है

किसी दिए गए प्रश्न के लिए, शामिल दस्तावेजों की संख्या शून्य के करीब होनी चाहिए। यदि दस्तावेजों की संख्या काफी बड़ी है तो दो संभावनाएं हैं:

1. संग्रह के साथ अनुक्रमण का उपयोग नहीं करना
2. ऐसी अनुक्रमणिका का उपयोग करना जो इष्टतम नहीं है।

एक संग्रह के लिए एक इंडेक्स बनाने के लिए कमांड चलाएँ: 

db.collection.createIndex( { quantity: 1 } )

जहां मात्रा एक उदाहरण फ़ील्ड है जिसे आपने अनुक्रमण रणनीति के लिए इष्टतम होने के लिए चुना है।

यदि आप अनुक्रमण के बारे में अधिक जानना चाहते हैं और किस अनुक्रमण रणनीति का उपयोग करना चाहते हैं, तो इस ब्लॉग को देखें

निष्कर्ष

डेटाबेस के प्रदर्शन में गिरावट को धीमी क्वेरी द्वारा आसानी से चित्रित किया जा सकता है जो कि कम से कम उम्मीद है कि हम प्लेटफ़ॉर्म उपयोगकर्ताओं का सामना करना चाहेंगे। प्रोफाइलर को सक्षम करके और इसे कुछ विशिष्टताओं के लिए कॉन्फ़िगर करके या चल रहे मोंगोड इंस्टेंस पर db.currentOp() निष्पादित करके मोंगोडीबी में धीमी क्वेरी की पहचान कर सकते हैं।

लौटे हुए परिणाम पर समय मापदंडों को देखकर, हम पहचान सकते हैं कि कौन से प्रश्न पिछड़ रहे हैं। इन प्रश्नों की पहचान करने के बाद, हम अधिक विवरण प्राप्त करने के लिए इन प्रश्नों पर व्याख्या सहायक का उपयोग करते हैं उदाहरण के लिए यदि क्वेरी किसी अनुक्रमणिका का उपयोग कर रही है।

अनुक्रमण के बिना, संचालन महंगा हो जाता है क्योंकि परिवर्तनों को लागू करने से पहले बहुत सारे दस्तावेजों को स्कैन करने की आवश्यकता होती है। इस झटके के साथ, सीपीयू अधिक काम करेगा, जिसके परिणामस्वरूप धीमी क्वेरी और सीपीयू स्पाइक्स बढ़ेंगे।

एक बड़ी गलती जो धीमी क्वेरी की ओर ले जाती है, वह है अक्षम निष्पादन योजना जिसे शामिल संग्रह के साथ एक इंडेक्स का उपयोग करके आसानी से हल किया जा सकता है।