निम्नलिखित में से 1 अध्याय से एक निष्कर्ष है स्केल पर डेटाबेस प्रदर्शन (एक ओपन एक्सेस किताब जो मुफ्त में उपलब्ध है)। कुछ बहुत ही वास्तविक डेटाबेस प्रदर्शन चुनौतियों के साथ जोआन की अत्यधिक काल्पनिक साहसिकताओं का पालन करें. आप हंसेंगे. आप रोएंगे. आप आश्चर्यचकित होंगे कि हम इस "चीसी कहानी" को एक गहराई से तकनीकी पुस्तक में कैसे काम किया। स्केल पर डेटाबेस प्रदर्शन "हाइब्रिड क्लाउड," "सेवरलेस" और "ईज पहले" जैसे प्रभावशाली बज़्ज़ॉम शब्दों से आकर्षित, जोआन आसानी से एक नई कंपनी में शामिल हो गए और अपनी प्रौद्योगिकी स्टॉक के साथ पकड़ना शुरू कर दिया। उनकी पहली परियोजना ने हाल ही में एक डेटाबेस सिस्टम के अपने आंतरिक कार्यान्वयन से एक संक्रमण शुरू किया, जो ग्राहकों की संख्या के साथ एक ही गति से नहीं बढ़ रहा था, उद्योग मानक डेटाबेस प्रबंधन समाधानों में से एक में। SQL दुनिया में ज्ञात गारंटी एसिड कुछ नए डेटा संरक्षण अधिनियमों के कारण जो आजकल हर साल दिखाई देते हैं, कंपनी के बोर्ड ने फैसला किया कि वे अपने स्वयं के डेटा सेंटर को बनाए रखने जा रहे हैं, बजाय लोकप्रिय क्लाउड प्रदाताओं में से एक का उपयोग संवेदनशील जानकारी को संग्रहीत करने के लिए। बहुत उच्च स्तर पर, कंपनी का मुख्य उत्पाद केवल दो परतों से बना था: फ्रंटेंड, उपयोगकर्ताओं के लिए प्रवेश बिंदु, जो वास्तव में अपने ब्राउज़रों में चलता है और बाकी सिस्टम के साथ संचार करता है ताकि जानकारी का आदान-प्रदान और निरंतर हो। सब कुछ-else, आमतौर पर "बाकेंड" के रूप में जाना जाता है, लेकिन वास्तव में लोड बैलेंसर, सत्यापन, अधिकृत, कई कैश परतों, डेटाबेस, बैकअप, और इतने पर शामिल हैं। जोआन का पहला परिचय कार्य डेटाबेस से विभिन्न आंकड़ों को एकत्र करने और सारांश करने के लिए एक बहुत ही सरल सेवा लागू करना था, और उस सेवा को पूरे पारिस्थितिकी तंत्र के साथ एकीकृत करना था, ताकि यह वास्तविक समय में डेटाबेस से डेटा प्राप्त कर सके और डेवओप्स टीमों को आंकड़ों की लाइव जांच करने की अनुमति दे। प्रबंधन को प्रभावित करने और उन्हें आश्वस्त करने के लिए कि जोआन को भर्ती करना इस तिमाही में उनका बिल्कुल सर्वश्रेष्ठ निर्णय था, जोआन ने अपने पहले दिन पर एक अवधारणा अनुमोदन कार्यान्वयन प्रदान करने का फैसला किया! कंपनी की अनिवार्य नीति रूस्ट में सॉफ्टवेयर लिखना थी, इसलिए उसने एक संक्षिप्त crates.io खोज से अपने डेटाबेस के लिए पहला ड्राइवर पकड़ लिया और अपने स्वयं-संपादित हैकथन में बैठ गया। दिन वास्तव में सुचारू रूप से गुजर रहा था, रस्ट के एर्गोनोमी पर केंद्रित पारिस्थितिकी तंत्र ने एक उत्कृष्ट डेवलपर्स अनुभव प्रदान किया. लेकिन फिर जोआन ने एक वास्तविक प्रणाली पर अपने पहले धूम्रपान परीक्षण चलाए. अविश्वास निराशा और असहायता में बदल गया जब उसने महसूस किया कि हर तीसरे अनुरोध (आमतौर पर) एक त्रुटि में समाप्त हो गया, भले ही पूरे डेटाबेस क्लस्टर को एक स्वस्थ, संचालित स्थिति में होने की सूचना दी गई थी. इसका मतलब था कि डिबगिंग सत्र ठीक था! दुर्भाग्य से, ड्राइवर जोआन ने जल्दी से अपने काम के आधार के लिए चुना, हालांकि खुले स्रोत अपने आप में, पूर्व संकलित, विरासत सी कोड पर केवल एक पतला कवर था, जिसके बिना कोई स्रोत नहीं पाया गया था। और उसने एक शिक्षित अनुमान लगाया कि कंपनी द्वारा उपयोग किए जाने वाले डेटाबेस में, कुंजी उपयुक्त नोड्स के लिए बाद में रास्ता अनुरोधों के लिए हैश किए जाते हैं. यदि एक हैश मूल्य गलत तरीके से गणना किया जाता है, तो अनुरोध गलत नोड पर भेजा जा सकता है जो इसे अस्वीकार कर सकता है और इसके बजाय एक त्रुटि वापस कर सकता है. Wireshark के लिए बैग हैशिंग कुंजी कार्यान्वयन में होना चाहिए संसाधन कोड की कमी के कारण दावा की पुष्टि करने में असमर्थ, जोआन ने एक सरल मार्ग पर फैसला किया - मूल रूप से चुने गए ड्राइवर को छोड़ दिया और आधिकारिक तौर पर समर्थित, डेटाबेस विक्रेता द्वारा समर्थित खुले स्रोत ड्राइवरों में से एक पर समाधान को पुन: लागू किया, एक ठोस उपयोगकर्ता आधार और नियमित रूप से अपडेट किए गए रिलीज कार्यक्रम। Joan's Diary of Lessons Learned, भाग I प्रारंभिक सबक शामिल हैं: एक ड्राइवर को सावधानीपूर्वक चुनें. यह आपके कोड के प्रदर्शन, मजबूतता और विश्वसनीयता के मूल में है। ड्राइवरों में भी बग हैं, और उन्हें रोकना असंभव है. फिर भी, अनुपालन करने के लिए अच्छे प्रथाएं हैं: यदि कोई अच्छा कारण नहीं है, तो आधिकारिक तौर पर समर्थित ड्राइवर को पसंद करें (यदि ऐसा है); ओपन-सॉर्ड ड्राइवरों के फायदे हैं: वे न केवल समुदाय द्वारा सत्यापित किए जाते हैं, बल्कि इसकी कोड की गहरी जांच भी कर सकते हैं, और यहां तक कि ड्राइवर कोड को संशोधित करने के लिए डबगिंग के लिए और भी अधिक अंतर्दृष्टि प्राप्त करने के लिए; अच्छी तरह से स्थापित रिलीज कार्यक्रम के साथ ड्राइवरों पर भरोसा करना बेहतर है क्योंकि वे एक उचित अवधि के भीतर बग फिक्स प्राप्त करने की अधिक संभावना रखते हैं (सुरक्षा कमजोरियों के लिए भी)। 3. Wireshark नेटवर्क पैकेज को व्याख्या करने के लिए एक महान ओपन सोर्स टूल है; यदि आप अपने कार्यक्रम के कैप के नीचे देखना चाहते हैं तो इसे एक कोशिश करें। प्रारंभिक कार्य को अंततः सफलतापूर्वक पूरा किया गया, जिससे जोआन को अपना पहला वास्तविक कार्य प्राप्त करने के लिए तैयार हो गया। ट्यूनिंग प्रारंभिक कार्य पर काम करने के अनुभव के साथ सशस्त्र, जोआन ने योजना बनाना शुरू कर दिया कि वह अपने नए कार्य को कैसे पहुंच सकता है: एक गलत व्यवहार एप्लिकेशन. एप्लिकेशनों में से एक ने पूरे सिस्टम के लिए स्थिरता मुद्दों का कारण बनने के लिए प्रसिद्ध हो गया था, जब भी किसी भी समस्या का अनुभव होता है तो अन्य कार्य भार को बाधित करता है. गुमराह ऐप पहले से ही एक आधिकारिक रूप से समर्थित ड्राइवर पर आधारित था, इसलिए जोआन संभावित जड़ कारणों की सूची से उस एक को पार कर सकता था. इस विशेष सेवा को पुराने सिस्टम से बैकअप किए गए डेटा को नई डेटाबेस में इंजेक्शन करने के लिए जिम्मेदार था. क्योंकि कंपनी बहुत जल्दी में नहीं थी, एप्लिकेशन को कम प्राथमिकता रखने और उपयोगकर्ता कार्य भारों के साथ हस्तक्षेप नहीं करने के लिए ध्यान में रखते हुए कम समानता के साथ लिखा गया था. दुर्भाग्य से, हर कुछ दिन में एक बार कुछ अनियमितता का कारण बन रहा था. सामान्य रूप से शांतिपूर्ण एप्लिकेशन अपनी खुद की डेटाबेस पर एक सेवा अस्वीकरण हमला करने की कोशिश कर रहा था, अनुरोधों के साथ इसे बाउंड एंड को पर्याप्त रूप से अवरोधित होने तक बाउंड एंड के साथ बाढ़ कर रहा था ताकि पारिस्थितिकी तंत्र के अन्य हिस्सों के लिए समस्याएं पैदा हों। जैसा कि जोआन ने ग्रेफाना डैशबोर्ड में प्रस्तुत मीट्रिक को देखा, जो स्पष्ट रूप से सुझाव देता है कि इस एप्लिकेशन द्वारा उत्पन्न अनुरोधों की दर अनियमितता के समय के आसपास बढ़ने लगी, वह आश्चर्यचकित थी कि पृथ्वी पर यह कार्य भार इस तरह से कैसे व्यवहार कर सकता है. आखिरकार, यह स्पष्ट रूप से नए अनुरोधों को केवल तब भेजने के लिए लागू किया गया था जब उनमें से कम से कम 100 वर्तमान में चल रहे थे. चूंकि इनबॉर्डिंग सत्रों के दौरान कंपनी के "मन और सांस्कृतिक नींव" में से एक के रूप में सहयोग को भारी रूप से प्रचारित किया गया था, इसलिए उसने अपने सहयोगी टोनी के साथ इस मुद्दे पर चर्चा करने का फैसला किया। "देखो, टोनी, मैं इस बारे में अपना सिर नहीं लपेट सकता," उसने समझाया। "यह सेवा कोई नया अनुरोध नहीं भेजती है जब उनमें से 100 पहले से ही उड़ान भर रहे हैं। "ठीक है, धन्यवाद टॉनी, आप एक प्रिय हैं - सबसे अच्छा कभी भी! " उसने समाप्त कर दिया और कोड को ठीक करने के लिए वापस चला गया। रबर डैक मूल कारण का पता लगाने के लिए नेतृत्व करने वाली निरीक्षण काफी सरल थी: अनुरोध वास्तव में *अवलोकन* एक समय-अवलोकन त्रुटि नहीं था क्योंकि डेटाबेस सर्वर ने कभी भी ऐसी प्रतिक्रिया नहीं भेजी थी. अनुरोध को ड्राइवर द्वारा समय-अवलोकन के रूप में वर्गीकृत किया गया था, और फेंक दिया गया था. लेकिन केवल तथ्य यह है कि ड्राइवर अब किसी विशेष अनुरोध के लिए जवाब का इंतजार नहीं करता है इसका मतलब यह नहीं है कि डेटाबेस इसे संसाधित कर रहा है! यह पूरी तरह से संभव है कि अनुरोध इसके बजाय बस स्थिर था, अपेक्षा से अधिक समय लेता था, और केवल ड्राइवर ने अपनी प्रतिक्रिया का इंतजार करना छोड़ दिया। उस ज्ञान के साथ, यह कल्पना करना आसान है कि एक बार ग्राहक पक्ष पर 100 अनुरोधों का समय समाप्त हो गया है, ऐप गलती से सोच सकता है कि वे अब प्रगति में नहीं हैं, और खुशी से डेटाबेस में 100 अतिरिक्त अनुरोध भेजते हैं, जो उड़ान में अनुरोधों की कुल संख्या को 200 तक बढ़ाता है। जोआन के सीखे गए सबक के डायरी, भाग II पढ़ाई जारी है: क्लाइंट-साइड टाइमओट प्रोग्रामर के लिए सुविधाजनक हैं, लेकिन वे सर्वर-साइड टाइमओट के साथ बुरी तरह से बातचीत कर सकते हैं। उंगली का नियम: क्लाइंट-साइड टाइमओट को सर्वर-साइड टाइमओट की तुलना में लगभग दो गुना लंबे समय तक करें, जब तक कि आपके पास अन्यथा करने का एक बेहद अच्छा कारण न हो। कुछ अप्रत्याशित परिस्थितियों के तहत दृढ़ संतुलन के साथ कार्य वास्तव में स्पाइक्स का कारण बन सकते हैं. लॉग और डैशबोर्ड की जांच ऐसे मामलों की जांच में उपयोगी है, इसलिए सुनिश्चित करें कि देखभाल उपकरण दोनों डेटाबेस क्लस्टर में और सभी क्लाइंट अनुप्रयोगों के लिए उपलब्ध हैं. वितरित ट्रैकिंग के लिए बोनस अंक, जैसे कि OpenTelemetry एकीकरण। क्लाइंट-साइड टाइमओट को सही ढंग से संशोधित करने के साथ, एप्लिकेशन बहुत कम बार और एक छोटे से स्तर पर डूब गया, लेकिन यह अभी भी वितरित प्रणाली में एक आदर्श नागरिक नहीं था। यह कभी-कभी पीड़ित डेटाबेस नोड को चुना और इसे बहुत अधिक अनुरोधों के साथ परेशान करना जारी रखा, जबकि इस तथ्य को अनदेखा कर रहा था कि सात अन्य नोड काफी कम लोड किए गए थे और कार्य भार को संभालने में मदद कर सकते थे। अन्य समयों में, इसकी सहभागिता को कॉन्फ़िगरेशन द्वारा अपेक्षित से सटीक 200% बड़ा होने की सूचना दी गई थी। जब भी दो अनियमितताएं समय में मिलती थीं, गरीब नोड सभी अनुरोधों को संभालने में असमर्थ था, और उन्हें उनमें प्रारूप और उचित रूप से अद्यतन बनाए रखा, जोआन ने उन दर्दों को भी कम करने में मदद की। एमडीबुक पहला समस्या बस गैर-अनुमानित लोड संतुलन नीति की गलत कॉन्फ़िगरेशन थी, जो सभी उपलब्ध लोगों में से "कम से कम लोड किए गए" डेटाबेस नोड को चुनने के लिए बहुत मेहनत कर रहा था, जो समय-समय पर डेटाबेस द्वारा अद्यतन किए गए heuristics और आंकड़ों के आधार पर था। दुर्भाग्य से, यह नीति भी "सबसे अच्छा प्रयास" थी, और इस तथ्य पर भरोसा करती थी कि डेटाबेस से आते हुए आंकड़े हमेशा वैध थे - लेकिन एक तनावपूर्ण डेटाबेस नोड इतना भारी हो सकता है कि यह समय पर अपडेट किए गए आंकड़ों को वापस नहीं भेज रहा था! जिसने ड्राइवर को गलत तरीके से यह मानने के लिए प्रेरित किया कि यह विशेष सर्वर वास्तव में व्यस्त नहीं था। दूसरी समस्या (सामान्य मुद्रा का अस्थायी दोगुनाकरण) एक अन्य गलतफहमी के कारण थी: एक अधिक से अधिक स्पेक्ट्रमिक रिट्री नीति। डेटाबेस से एक मान्यता प्राप्त किए बिना एक पूर्व-आधारित अवधि के लिए प्रतीक्षा करने के बाद, ड्राइवरों को सफलता के लिए अपनी संभावनाओं को अधिकतम करने के लिए एक अनुरोध फिर से भेजते थे। यह तंत्र अनुरोधों की सफलता दर को बढ़ाने के लिए बहुत उपयोगी है। हालांकि, यदि मूल अनुरोध भी सफल होता है, तो इसका मतलब है कि स्पेक्ट्रमिक एक बेकार भेजा गया था। लाभों और नुकसानों को संतुलित करने के लिए, स्पेक्ट्रमिक रिट्री को केवल अनुरोधों को फिर से भेजने के लिए कॉन्फ़िगर किया जाना चाहिए यदि यह बहुत सं वाह, कुछ भी एक ही समय में एंडोर्फिन की धड़कन और डोपामाइन को एक गुणवत्ता डिबगिंग सत्र की तरह नहीं देता है जो एक अद्भुत सफलता में समाप्त होता है (स्वास्थ्यकर रूप से एक गहरी तकनीकी पुस्तक में एक सुगंधित कहानी लिखने के अलावा)। अंत है। यदि आप इसे इतनी दूर तक कर चुके हैं और सूखे डेटाबेस प्रदर्शन कहानियों से पर्याप्त नहीं हो सकते हैं, तो देखें कि गरीब पुराने पैट्रिक के साथ क्या हुआ। “और यदि आप इस हास्य की सराहना करते हैं, तो पियटर के . Editor’s note: डेटाबेस प्रदर्शन की एक कहानी: पैट्रिक के दुर्भाग्यपूर्ण ग्रीन फेडोरास इंजीनियरिंग ब्लॉग पोस्ट लिखने पर नई किताब
