कैशिंग का विषय 22 साल पहले PostgreSQL में दिखाई दिया था, और उस समय डेटाबेस की विश्वसनीयता पर ध्यान केंद्रित किया गया था।
2020 तक तेजी से आगे बढ़ते हुए, डिस्क प्लैटर्स वर्चुअलाइज्ड वातावरण, हाइपरवाइजर और संबंधित स्टोरेज उपकरणों में और भी गहरे छिपे हुए हैं। इसके अलावा, वैश्विक स्तर पर काम कर रहे इंटरकनेक्टेड, वितरित एप्लिकेशन कम विलंबता कनेक्शन और अचानक ट्यूनिंग सर्वर कैश के लिए चिल्ला रहे हैं, और SQL क्वेरीज़ यह सुनिश्चित करने के साथ प्रतिस्पर्धा करती हैं कि परिणाम मिलीसेकंड के भीतर ग्राहकों को वापस कर दिए जाएं। एप्लिकेशन स्तर और इन-मेमोरी कैश पैदा होते हैं, और पढ़ी गई क्वेरी अब एप्लिकेशन सर्वर के करीब सहेजी जाती हैं। नतीजतन, I/O संचालन केवल लिखने के लिए कम हो जाते हैं, और नेटवर्क विलंबता नाटकीय रूप से सुधारती है। एक कैच के साथ। कार्यान्वयन अपने स्वयं के कैश प्रबंधन के लिए जिम्मेदार होते हैं जो कभी-कभी प्रदर्शन में गिरावट का कारण बनते हैं।
कैशिंग लेखन एक अधिक जटिल मामला है, जैसा कि PostgreSQL विकी में बताया गया है।
यह ब्लॉग इन-मेमोरी क्वेरी कैश और लोड बैलेंसर्स का अवलोकन है जिनका उपयोग PostgreSQL के साथ किया जा रहा है।
पोस्टग्रेएसक्यूएल लोड बैलेंसिंग
लोड संतुलन का विचार उसी समय कैशिंग के रूप में सामने आया था, 1999 में, जब ब्रूस मोम्जियम ने लिखा था:
[...] यह संभव है कि निकट भविष्य में हम _very_ लोकप्रिय हों।
पोस्टग्रेएसक्यूएल में लोड बैलेंसिंग को लागू करने की नींव बिल्ट-इन हॉट स्टैंडबाय फीचर द्वारा प्रदान की जाती है। एप्लिकेशन के लिए एकमात्र आवश्यकता विफलता को संभालने के लिए है और यही वह जगह है जहां तीसरे पक्ष के समाधान आते हैं। हम अगले अनुभागों में उनमें से कुछ समाधानों को देखेंगे।
लोड संतुलित क्वेरी केवल तभी तक सुसंगत परिणाम दे सकती हैं जब तक कि सिंक्रोनस प्रतिकृति अंतराल को कम रखा जाता है। व्यवहार में, यहां तक कि अत्याधुनिक नेटवर्क अवसंरचना जैसे AWS भी दसियों मिलीसेकंड विलंब प्रदर्शित कर सकती है:
हम आमतौर पर 10 मिलीसेकंड के अंतराल में समय देखते हैं। [...] हालांकि, विशिष्ट परिस्थितियों में, प्रतिकृति के एक मिनट के तहत अंतराल आम है। [...]
तार्किक प्रतिकृति का उपयोग करने वाले क्रॉस-क्षेत्र प्रतिकृतियां चयनित विशिष्ट क्षेत्रों के बीच नेटवर्क संचार में परिवर्तन/लागू दर और विलंब से प्रभावित होंगी। Aurora Global Database का उपयोग करने वाले क्रॉस-रीजन प्रतिकृतियों में एक सेकंड से कम का विशिष्ट अंतराल होगा।
जैसा कि पहले बताया गया है कि तृतीय पक्ष समाधान कोर पोस्टग्रेएसक्यूएल सुविधाओं पर निर्भर करते हैं। उदाहरण के लिए, कई सिंक्रोनस स्टैंडबाय का उपयोग करके रीड क्वेरीज़ का लोड बैलेंसिंग हासिल किया जाता है।
समाधान
pgpool-II
pgpool-II एक सुविधा संपन्न उत्पाद है जो लोड संतुलन और इन-मेमोरी क्वेरी कैशिंग दोनों प्रदान करता है। यह एक ड्रॉप-इन प्रतिस्थापन है, आवेदन पक्ष में किसी परिवर्तन की आवश्यकता नहीं है।
लोड बैलेंसर के रूप में, pgpool-II प्रत्येक SQL क्वेरी की जांच करता है — लोड संतुलित होने के लिए, SELECT क्वेरीज़ को कई शर्तों को पूरा करना होगा।
सेटअप एक नोड जितना आसान हो सकता है, जैसा कि नीचे दिखाया गया है, एक डुअल-नोड क्लस्टर है:
जैसा कि किसी भी बड़े सॉफ्टवेयर के मामले में होता है, कुछ सीमाएं होती हैं। , और pgpool-II कोई अपवाद नहीं बनाता है:
- यह मल्टी-स्टेटमेंट क्वेरी को हैंडल नहीं करता है।
- अस्थायी तालिकाओं पर चुनिंदा प्रश्नों के लिए /*कोई लोड शेष नहीं*/ SQL टिप्पणी आवश्यक है।
उच्च प्रदर्शन वातावरण में चल रहे अनुप्रयोगों को मिश्रित कॉन्फ़िगरेशन से लाभ होगा जहां pgBouncer कनेक्शन पूलर है और pgpool-II लोड संतुलन और कैशिंग को संभालता है। परिणाम 4 गुना प्रभावशाली वृद्धि और 40 प्रतिशत विलंबता में कमी है:
इन-मेमोरी कैशिंग काम करता है, फिर से, केवल पढ़े गए प्रश्नों पर, कैश्ड के साथ डेटा को या तो साझा मेमोरी में या बाहरी मेमकैच्ड इंस्टॉलेशन में सहेजा जा रहा है। जबकि दस्तावेज़ीकरण विभिन्न कॉन्फ़िगरेशन विकल्पों की व्याख्या करने में बहुत अच्छा है, यह अप्रत्यक्ष रूप से सुझाव देता है कि कार्यान्वयन को SHOW POOL CACHE आउटपुट की निगरानी करनी चाहिए ताकि हिट अनुपात 70% से नीचे गिरने पर सतर्क हो सके, जिस बिंदु पर कैशिंग द्वारा प्रदान किया गया प्रदर्शन लाभ खो जाता है।
बुकार्डो
Bucardo Perl और PL/Perl में लिखा गया एक PostgreSQL प्रतिकृति उपकरण है।
मैंने बुकार्डो का उल्लेख किया है, क्योंकि लोड संतुलन इसकी विशेषताओं में से एक है, PostgreSQL विकी के अनुसार, हालांकि, एक इंटरनेट खोज कोई प्रासंगिक परिणाम नहीं देती है। स्पष्ट करने के लिए मैंने आधिकारिक दस्तावेज की ओर रुख किया, जो इस बात का विवरण देता है कि सॉफ्टवेयर वास्तव में कैसे काम करता है:
इससे यह स्पष्ट हो जाता है कि बुकार्डो लोड बैलेंसर नहीं है, ठीक उसी तरह जैसे डेटाबेस सूप पर लोगों द्वारा इंगित किया गया था।
HAProxy
HAProxy एक सामान्य प्रयोजन लोड बैलेंसर है जो टीसीपी स्तर (डेटाबेस कनेक्शन के उद्देश्य के लिए) पर संचालित होता है। स्वास्थ्य जांच यह सुनिश्चित करती है कि प्रश्न केवल जीवित नोड्स को भेजे जाते हैं।
pgpool-II की तुलना में, लोड बैलेंसर के रूप में HAProxy का उपयोग करने वाले एप्लिकेशन को रीडर नोड्स को एंडपॉइंट प्रेषण अनुरोधों से अवगत कराया जाना चाहिए।
अपाचे इग्नाइट
अपाचे इग्नाइट एक दूसरे स्तर का कैश है जो एएनएसआई-99 एसक्यूएल को समझता है और एसीआईडी लेनदेन के लिए समर्थन प्रदान करता है। अपाचे इग्नाइट पोस्टग्रेएसक्यूएल फ्रंटएंड/बैकएंड प्रोटोकॉल को नहीं समझता है और इसलिए अनुप्रयोगों को हाइबरनेट ओआरएम जैसे दृढ़ता परत का उपयोग करना चाहिए। अनुप्रयोगों को संशोधित करने के विकल्प के रूप में, अपाचे इग्नाइट `memcached एकीकरण`_ प्रदान करता है जिसके लिए memcached PostgreSQL एक्सटेंशन की आवश्यकता होती है। दुर्भाग्य से, यह बाद वाला विकल्प PostgreSQL के हाल के संस्करणों के साथ संगत नहीं है, क्योंकि pgmemcache एक्सटेंशन को अंतिम बार 2017 में अपडेट किया गया था।
हेमडॉल डेटा
एक वाणिज्यिक उत्पाद के रूप में, Heimdall Data दोनों बॉक्सों की जांच करता है:लोड संतुलन और कैशिंग। यह एक परिपक्व उत्पाद है, जिसे पोस्टग्रेएसक्यूएल सम्मेलनों में पीजीकॉन 2017 में प्रदर्शित किया गया है:
अधिक विवरण और उत्पाद डेमो Azure for PostgreSQL ब्लॉग पर पाया जा सकता है ।
निष्कर्ष
आज के वितरित कंप्यूटिंग में, क्वेरी कैशिंग और लोड बैलेंसिंग PostgreSQL के प्रदर्शन ट्यूनिंग के लिए उतने ही महत्वपूर्ण हैं जितने कि जाने-माने GUC, OS कर्नेल, स्टोरेज और क्वेरी ऑप्टिमाइजेशन। जबकि pgpool-II और Heimdall Data खुले स्रोत हैं और क्रमशः वाणिज्यिक पसंदीदा समाधान हैं, ऐसे मामले हैं जहां जानबूझकर बनाए गए टूल समान परिणाम प्राप्त करने के लिए बिल्डिंग ब्लॉक्स के रूप में उपयोग किए जा सकते हैं।
