डेटाबेस प्रदर्शन में महारत: व्यावहारिक निगरानी और अनुकूलन तकनीकें

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

इस पोस्ट में, हम आपकी आर्किटेक्चर के डेटाबेस भाग में गोता लगाएंगे ताकि दिखा सकें कि आप अपने डेटाबेस प्रदर्शन की निगरानी और अनुकूलन कैसे कर सकते हैं। निम्नलिखित अधिकांश सिद्धांत लागू होते हैं, चाहे आपका स्टैक कुछ भी हो, या आप PostgreSQL, MongoDB, या किसी अन्य डेटाबेस के लिए प्रदर्शन की निगरानी और अनुकूलन करना चाहते हों।

डेटाबेस प्रदर्शन की निगरानी क्यों करें?

मान लीजिए एक क्वेरी बहुत धीमी है, और आपके ऐप को परिणामों के लिए इंतजार करना पड़ता है - जिससे आपके अंतिम उपयोगकर्ताओं और/या आपके ऐप के एक हिस्से के लिए चीजें रुक जाती हैं।

ट्रैफिक जाम की तरह, एक हिस्सा कहीं और होने वाली किसी चीज के प्रभाव के रूप में स्थिर हो सकता है। यदि बहुत सारी क्वेरी हल होने में बहुत लंबा समय लेती हैं, तो ऐसा इसलिए हो सकता है क्योंकि अन्य क्वेरी रास्ते में आ रही हैं।

आपका लक्ष्य यह पता लगाना है कि कोई समस्या कहां से आ रही है इससे पहले कि आपके ऐप के अन्य हिस्सों में चीजें गलत होने लगें।

अगला कदम सक्रिय रूप से मॉनिटरिंग का उपयोग करके अपनी आर्किटेक्चर को अनुकूलित करना और यह देखना है कि आप चीजों को कैसे तेज बना सकते हैं। लेकिन हम खुद से आगे निकल रहे हैं - आइए चरण 1 से शुरू करें:

चरण 1: मापना उर्फ डेटाबेस प्रदर्शन को इंस्ट्रूमेंट करना

डेटाबेस मॉनिटरिंग यह सुनिश्चित करने से शुरू होती है कि आप सही चीजों को माप रहे हैं:

• त्रुटियां

• प्रदर्शन

• क्वेरी अवधि के माध्य और 90वें पर्सेंटाइल

• कुल थ्रूपुट - आपको थ्रूपुट के मुद्दे होने पर ट्रिगर/फ्लैग सेट करने का एक और तरीका देता है

सौभाग्य से, वह डेटा प्राप्त करना पहले ही आपके लिए किया जा चुका है: आपका APM सॉफ्टवेयर संभवतः आपको यह कॉन्फ़िगर करने देता है कि आप क्या इंस्ट्रूमेंट और मापना चाहते हैं। यदि आप AppSignal का उपयोग करते हैं, तो डेटा एकत्र करना और एकत्रित करना स्वचालित रूप से होता है, बिना अधिक सेटअप के। हमने आपके लिए भारी काम किया है!

चरण 2: एक प्रारंभिक बिंदु - उच्च-प्रभाव वाली क्वेरी खोजें

एक बार जब आपका ऐप इंस्ट्रूमेंटेड हो जाता है और वास्तविक दुनिया का डेटा आना शुरू हो जाता है, तो आप पैटर्न उभरते देखेंगे। AppSignal पर, हमने नेविगेशन में 'इम्प्रूव' के तहत सबसे धीमे API अनुरोधों और सबसे धीमी क्वेरी के लिए स्क्रीन बनाई हैं:

यह स्क्रीन आपको अनुकूलन के लिए एक बेहतरीन प्रारंभिक बिंदु देगी। डिफ़ॉल्ट रूप से, धीमी क्वेरी प्रभाव के आधार पर सॉर्ट की जाती हैं। ये वे क्वेरी हैं जो आप अक्सर करते हैं। प्रभाव थ्रूपुट x माध्य क्वेरी समय है।

इन सॉर्टिंग के बीच टॉगल करने से आपको सबसे अधिक वॉल्यूम वाली क्वेरी, जो सबसे धीमी हैं (लेकिन शायद एक बार की रात की पृष्ठभूमि नौकरियां हैं जिन्हें आप आसानी से अनदेखा कर सकते हैं), और जिनका सबसे अधिक प्रभाव है, का अंदाजा मिलेगा।

एक त्वरित साइड-स्टेप: कुछ व्यक्तिगत क्वेरी को ठीक करें

अब आप ठीक करने के लिए कुछ क्वेरी ढूंढ सकते हैं।

यदि आप एक धीमी क्वेरी पर क्लिक करते हैं, तो आप दाईं ओर इसके सभी विवरण देखेंगे, थ्रूपुट और क्वेरी के लिए प्रतिक्रिया समय से लेकर क्वेरी नाम तक:

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

हमने एक विशेष एंटी-पैटर्न के लिए इसे बहुत दृश्यमान बना दिया है: N+1। N+1 एंटी-पैटर्न तब होता है जब पिछली क्वेरी के प्रत्येक परिणाम के लिए एक क्वेरी निष्पादित की जाती है।

क्वेरी की संख्या N + 1 होती है, जहां N प्रारंभिक क्वेरी परिणामों के लिए क्वेरी की संख्या है। यदि उस प्रारंभिक क्वेरी का एक परिणाम है, तो N+1 = 2। यदि इसके 1,000 परिणाम हैं, तो N+1 = 1,001 क्वेरी। बूम।

यदि क्वेरी N+1 एंटी-पैटर्न का पालन करती हैं, तो यह एक सुखद संयोग है - वे यहां लेबल की गई हैं ताकि आप उन्हें जल्दी से ढूंढ सकें:

हम यहां उन्हें हल करने के तरीके पर नहीं जाएंगे - हमने N+1 क्वेरी पर एक अलग ब्लॉग पोस्ट लिखी है।

ठीक है, अब मान लेते हैं कि हमने कुछ पागल चीजें ठीक कर दी हैं, और जैसे ही हमने उन्हें ठीक किया, हमने देखा कि वे कब हुईं और सबसे खराब प्रतिक्रिया समय क्या थे।

चरण 3: खोजना पैटर्न पर निर्णय लेना - क्या गलत है?

मॉनिटरिंग अक्सर यह देखने के बारे में होती है कि चीजें कब गलत होती हैं। लेकिन मॉनिटरिंग की जटिलता का एक हिस्सा यह परिभाषित करना है कि आपके सेटअप के लिए क्या 'गलत' माना जाना चाहिए। साथ ही, क्या आप एक ऐसे मुद्दे से अलर्ट होना पसंद करेंगे जो फिर खुद हल हो जाता है या एक ऐसे मुद्दे को मिस करेंगे जो हल नहीं होता?

आइए औसतन अपनी क्वेरी के थ्रूपुट और अवधि को देखें। आप इसे अपने APM सॉफ्टवेयर पर सेट कर सकते हैं। यदि आप Node.js की निगरानी के लिए AppSignal का उपयोग कर रहे हैं और अपने डेटाबेस के रूप में PostgreSQL का उपयोग करते हैं, तो हम स्वचालित रूप से आपके लिए सबसे महत्वपूर्ण मेट्रिक्स के साथ डैशबोर्ड बनाते हैं।

node-postgres डैशबोर्ड इस तरह डेटा दिखाएगा:

यदि आप इसे अपने ऐप के लिए सेट करना चाहते हैं, तो यहां कुछ आगे पढ़ने के लिए है।

जब आप विभिन्न समय सीमाओं के बीच स्विच करते हैं, तो आप छोटी चोटियों को देखेंगे जो एक घंटे के औसत में गायब हो जाती हैं, साथ ही ऐसी चोटियां जो लंबी समय सीमा में ज़ूम आउट करने पर उच्च बनी रहती हैं।

सबसे धीमी क्वेरी स्क्रीन को देखने के हमारे अनुभव से, अब हमारे पास मुख्य दोषियों और जब वे चरम पर थे, के बारे में एक विचार है।

थ्रूपुट में कुछ छोटी चोटियां ठीक हो सकती हैं - होस्ट अन्य प्रक्रियाएं चला रहा होगा जो क्वेरी को धीमा कर देती हैं, उदाहरण के लिए।

आप लंबे समय तक चलने वाली क्वेरी समय या चरम थ्रूपुट में ज़ूम इन करना चाहेंगे। 95वें पर्सेंटाइल बनाम माध्य को देखने से आपको बता सकता है कि क्या धीमी क्वेरी का अनुभव हर किसी को हो रहा है या केवल एक छोटे सबसेट को, जो कभी-कभी आपको यह बताने में मदद कर सकता है कि क्या ठीक करना है।

चरण 4: क्या आपको रखना रात में जगाए रखना चाहिए?

हम आमतौर पर स्पेक्ट्रम के शोर वाले पक्ष से शुरू करने की सलाह देते हैं: कुछ ट्रिगर सेट करें जो आपको ऐसे चैनल पर अलर्ट करें जो आपको न जगाए, जैसे ईमेल या स्लैक, बजाय PagerDuty के।

"event_duration" मेट्रिक पर एक कस्टम मेट्रिक्स ट्रिगर बनाएं और औसत क्वेरी समय पर अलर्ट पाने के लिए माध्य फील्ड चुनें। अपने ऐप द्वारा सामना की जाने वाली सबसे धीमी क्वेरी पर अलर्ट पाने के लिए 90वें या 95वें पर्सेंटाइल का चयन करें।

फिर उस घटना के प्रकार के लिए "ग्रुप" और "नेमस्पेस" टैग कॉन्फ़िगर करें जिसके बारे में आप अलर्ट चाहते हैं और किस नेमस्पेस में। उदाहरण के लिए, ग्रुप के लिए "active_record" (Rails) या "postgres" (Node.js) या "ecto" (Elixir), और नेमस्पेस के लिए "web" या "background":

एक सप्ताह के बाद, आप कुछ पैटर्न देखना शुरू कर देंगे और अंदाजा लगा लेंगे कि किन मामलों पर आपके ध्यान की आवश्यकता है और कौन से मामले आमतौर पर खुद हल हो जाते हैं।

फिर आप ट्रिगर्स को कम शोर वाला बनाने के लिए समायोजित कर सकते हैं और उन विशिष्ट अलर्ट के लिए चैनल जोड़ सकते हैं जब आप जगना चाहते हैं।

चरण 5: डेटाबेस मॉनिटरिंग सेटअप के साथ पूरा

अब, सिद्धांत रूप में, हमारे पास एक अच्छा मॉनिटरिंग सेटअप होना चाहिए: सही डेटा आता है, हमने बिट्स के पंखे से टकराने से पहले हमें चेतावनी देने के लिए ट्रिगर सेट किए हैं, और हमने कुछ बड़े दोषी ढूंढे हैं। हमें पूरा होना चाहिए, है ना?

वास्तव में, आपके ऐप का उपयोग बढ़ सकता है और नए बॉटलनेक बना सकता है। या कोड परिवर्तन आपके डेटाबेस को प्रभावित कर सकते हैं, जिससे अवधि बढ़ जाती है। या एक विशेष फ़ील्ड एक विशाल पेलोड के साथ कुछ ट्रिगर करेगा। आप कितने भी अनुभवी हों, नई समस्याएं और बॉटलनेक होंगे।

लेकिन आप इस तथ्य में आराम पा सकते हैं कि, उचित सेटअप के साथ, आपको चेतावनी दी जाएगी और आप अपनी आर्किटेक्चर में गहराई से गोता लगाकर इन मुद्दों को हल करना जानेंगे।

और शायद आप किसी अन्य स्क्रू के ढीले होने से पहले बड़े 'प्रभावशाली' क्वेरी को सुधारने में आनंद पा सकते हैं। यह वही है जो हमें सबसे ज्यादा पसंद है - वह, और स्ट्रॉपवाफल्स।

AppSignal आज़माएं, स्ट्रॉपवाफल्स पाएं 🍪

स्ट्रॉपवाफल्स की बात करें तो, हम उन्हें पूरी दुनिया में भेजते हैं। Ruby, Elixir और Node.js के लिए हमारे AppSignal APM सॉफ्टवेयर को आज़माएं। यदि आप एक मुफ्त ट्रायल सेट करते हैं और हमसे संपर्क करते हैं, तो हम आपको मुफ्त में स्ट्रॉपवाफल्स का एक बॉक्स भेजेंगे।