PostgreSQL के लिए लोड बैलेंसर्स की तुलना करना

लोड बैलेंसिंग सिस्टम के प्रदर्शन को बढ़ाता है, विशेष रूप से एप्लिकेशन के दृष्टिकोण से, कई कंप्यूटरों को समान डेटा प्रदान करने की अनुमति देता है। यह इस तरह काम करता है कि लोड क्लाइंट क्वेरी के बीच अपने प्राथमिक या मास्टर नोड से अलग नोड्स को प्रतिकृति करने के लिए वितरित किया जा रहा है, जबकि डेटाबेस संशोधनों को केवल मास्टर नोड में ही रूट किया जा रहा है। मास्टर नोड में कोई भी संशोधन बाद में PostgreSQL स्ट्रीमिंग प्रतिकृति का उपयोग करके प्रत्येक प्रतिकृति के लिए प्रचारित किया जाता है।

लोड बैलेंसर्स PostgreSQL को कैसे प्रभावित कर सकते हैं?

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

PostgreSQL का उपयोग करके, इसे काम करने के लिए पहले से ही कुछ मौजूदा समाधान मौजूद हैं। ये समाधान मूल रूप से काम कर सकते हैं या लोड संतुलन वर्तमान टोपोलॉजी के साथ काम कर सकता है - प्राथमिक और स्टैंडबाय नोड्स के साथ - फिर भी लोड संतुलन को एप्लिकेशन परत में ही लागू किया जाता है। लोड संतुलन को सिंक्रनाइज़ेशन समस्याओं के साथ चुनौतियों का सामना करना पड़ता है जो एक साथ काम करने वाले सर्वरों के लिए मूलभूत कठिनाई है। क्योंकि कोई एक समाधान नहीं है जो सभी उपयोग के मामलों के लिए सिंक समस्या के प्रभाव को समाप्त करता है, कई समाधान हैं। प्रत्येक समाधान इस समस्या को एक अलग तरीके से संबोधित करता है, और एक विशिष्ट कार्यभार के लिए इसके प्रभाव को कम करता है।

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

PostgreSQL के लिए HAProxy लोड बैलेंसिंग

HAProxy एक इवेंट-संचालित, गैर-अवरुद्ध इंजन है जो एक प्रॉक्सी को बहुत तेज़ I/O परत और प्राथमिकता-आधारित, बहु-थ्रेडेड शेड्यूलर के साथ जोड़ता है। चूंकि इसे डेटा फ़ॉरवर्डिंग लक्ष्य को ध्यान में रखकर डिज़ाइन किया गया है, इसलिए इसकी वास्तुकला को एक हल्की प्रक्रिया में संचालित करने के लिए डिज़ाइन किया गया है जो कि कम से कम संभव संचालन के साथ जितनी जल्दी हो सके डेटा को स्थानांतरित करने के लिए अनुकूलित है। यह यथासंभव लंबे समय तक एक ही सीपीयू से कनेक्शन चिपकाकर सीपीयू कैश दक्षता को अनुकूलित करने पर केंद्रित है। जैसे कि यह प्रत्येक स्तर पर बाईपास तंत्र की पेशकश करने वाले एक स्तरित मॉडल को लागू करता है, यह सुनिश्चित करता है कि जब तक आवश्यक न हो तब तक डेटा उच्च स्तर तक नहीं पहुंचता है। अधिकांश प्रसंस्करण कर्नेल में किया जाता है। HAProxy कुछ संकेत देकर या कुछ निश्चित संचालन से बचने के द्वारा कर्नेल को जितनी जल्दी हो सके काम करने में मदद करने के लिए अपनी पूरी कोशिश करता है जब यह अनुमान लगाता है कि उन्हें बाद में समूहीकृत किया जा सकता है। परिणामस्वरूप, विशिष्ट आंकड़े HAProxy में बिताए गए प्रोसेसिंग समय का 15% बनाम TCP या HTTP क्लोज़ मोड में कर्नेल में 85% और HAProxy के लिए लगभग 30% बनाम HTTP कीप-अलाइव मोड में कर्नेल के लिए 70% दिखाते हैं।

HAProxy में लोड बैलेंसिंग की अतिरिक्त विशेषताएं भी हैं। उदाहरण के लिए, टीसीपी प्रॉक्सीइंग सुविधा हमें डेटाबेस कनेक्शन के लिए विशेष रूप से पोस्टग्रेएसक्यूएल के लिए इसके अंतर्निहित चेक सेवा समर्थन का उपयोग करने की अनुमति देती है। हालांकि डेटाबेस सेवा समर्थन है, यह विशेष रूप से क्लस्टर के प्रतिकृति प्रकार के लिए वांछित स्वास्थ्य जांच के लिए पर्याप्त नहीं है। उत्पादन के लिए इसे तैनात करते समय मानक दृष्टिकोण टीसीपी जांच का उपयोग करना है, फिर HAProxy के साथ xinetd पर निर्भर है।

PostgreSQL के लिए HAProxy का उपयोग करने के लाभ

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

PostgreSQL के लिए HAProxy का उपयोग करने के विपक्ष

HAProxy क्वेरी फ़िल्टरिंग प्रदान नहीं करता है और न ही अनुरोध किए जा रहे कथनों के प्रकार की पहचान करने के लिए क्वेरी विश्लेषण प्रदान करता है। इसमें एक पोर्ट पर रीड/राइट स्प्लिट करने की क्षमता का अभाव है। HAProxy के शीर्ष पर एक लोड बैलेंसर सेट करने के लिए आवश्यक है कि आपको अपने लिखने के लिए कम से कम अलग-अलग पोर्ट और अपने पढ़ने के लिए अलग-अलग पोर्ट सेट करने हों। इसके लिए आपकी आवश्यकताओं के अनुरूप एप्लिकेशन परिवर्तन की आवश्यकता है।

HAProxy भी स्वास्थ्य जांच के लिए PostgreSQL के साथ एक बहुत ही सरल फीचर सपोर्ट करता है, फिर भी यह केवल यह निर्धारित करता है कि नोड ऊपर है या नहीं, जैसे कि यह सिर्फ नोड को पिंग कर रहा है और बाउंस बैक प्रतिक्रिया की प्रतीक्षा कर रहा है। यह नहीं पहचानता है कि क्लाइंट से वांछित नोड तक अनुरोधित कनेक्शन को अग्रेषित करने के लिए नोड किस भूमिका का प्रयास कर रहा है। इसलिए, प्रतिकृति टोपोलॉजी को समझने के लिए HAProxy में यह समझ में नहीं आता है या कोई विशेषता नहीं है। हालाँकि, एक उपयोगकर्ता अलग-अलग पोर्ट के आधार पर अलग-अलग श्रोता बना सकता है, लेकिन फिर भी यह लोड संतुलन आवश्यकताओं को पूरा करने के लिए एप्लिकेशन के भीतर परिवर्तन जोड़ता है। इसका मतलब यह है कि या तो xinetd के साथ बाहरी स्क्रिप्ट का उपयोग करना आवश्यकताओं को पूरा करने का समाधान हो सकता है। फिर भी, यह HAProxy से एकीकृत नहीं है और मानवीय त्रुटि के लिए प्रवण हो सकता है।

यदि एक नोड या नोड्स के समूह को रखरखाव मोड के तहत रखा जाना है, तो आपको अपने HAProxy में परिवर्तन लागू करने की भी आवश्यकता होगी, अन्यथा यह विनाशकारी हो सकता है।

Pgpool-II आपके पोस्टग्रेएसक्यूएल लोड संतुलन के लिए

Pgpool-II एक ओपन-सोर्स सॉफ्टवेयर है और लोड संतुलन को लागू करने के लिए बड़े पैमाने पर PostgreSQL समुदाय द्वारा अपनाया गया है और इसका उपयोग एप्लिकेशन से प्रॉक्सी लेयर तक उनके मिडलवेयर के रूप में कार्य करने के लिए किया जाता है, फिर लोड को वितरित करता है प्रति क्वेरी या डेटाबेस कनेक्शन के अनुरोध के प्रकार का पूरी तरह से विश्लेषण करने के बाद। Pgpool-II 2003 के बाद से इतने लंबे समय से है जिसे मूल रूप से Pgpool नाम दिया गया था जब तक कि यह 2006 में Pgpool-II नहीं बन गया, जो न केवल लोड संतुलन के लिए बल्कि कई शांत सुविधाओं के लिए एक बहुत ही स्थिर प्रॉक्सी टूल के एक वसीयतनामा के रूप में कार्य करता है। ।

Pgpool-II को PostgreSQL के लिए स्विस आर्मी नाइफ के रूप में जाना जाता है और यह एक प्रॉक्सी सॉफ्टवेयर है जो PostgreSQL सर्वर और एक PostgreSQL डेटाबेस क्लाइंट के बीच बैठता है। PgPool-II का मूल विचार यह है कि यह क्लाइंट पर बैठता है, फिर रीड क्वेश्चन को स्टैंडबाय नोड्स में डिलीवर करना होता है, जबकि राइट या मॉडिफिकेशन सीधे प्राइमरी में जाता है। यह एक बहुत ही बुद्धिमान लोड संतुलन समाधान है जो न केवल लोड संतुलन करता है, बल्कि उच्च उपलब्धता का भी समर्थन करता है और कनेक्शन पूलिंग प्रदान करता है। बुद्धिमान तंत्र स्वामी और दासों के बीच भार को संतुलित करने की अनुमति देता है। इसलिए राइट्स मास्टर को लोड किए जाते हैं, जबकि प्रोसेसिंग रीड को उपलब्ध रीड-ओनली सर्वर पर निर्देशित किया जाता है, जो आपके कथित हॉट स्टैंडबाय नोड्स हैं। Pgpool-II तार्किक प्रतिकृति भी प्रदान करता है। जबकि PostgreSQL सर्वर साइड पर इनबिल्ट प्रतिकृति विकल्पों में सुधार के रूप में इसका उपयोग और महत्व कम हो गया है, यह अभी भी PostgreSQL के पुराने संस्करणों के लिए एक मूल्यवान विकल्प बना हुआ है। इन सबसे ऊपर, यह कनेक्शन पूलिंग भी प्रदान करता है।

Pgpool-II में सभी सुविधाओं का समर्थन करने के लिए PgBouncer की तुलना में अधिक शामिल आर्किटेक्चर है। चूंकि दोनों कनेक्शन पूलिंग का समर्थन करते हैं, बाद वाले में कोई लोड संतुलन सुविधाएँ नहीं होती हैं।

Pgpool-II एकाधिक PostgreSQL सर्वर प्रबंधित कर सकता है। प्रतिकृति फ़ंक्शन का उपयोग 2 या अधिक भौतिक डिस्क पर रीयलटाइम बैकअप बनाने में सक्षम बनाता है, ताकि डिस्क विफलता के मामले में सर्वर को रोके बिना सेवा जारी रह सके। चूंकि पीजीपूल-द्वितीय भी एक कनेक्शन पूलिंग सक्षम है, यह अधिक कनेक्शन पर सीमित कर सकता है। PostgreSQL के साथ समवर्ती कनेक्शनों की अधिकतम संख्या की एक सीमा है, और इसके बाद कई कनेक्शनों को अस्वीकार कर दिया जाता है। हालाँकि, कनेक्शन की अधिकतम संख्या निर्धारित करने से संसाधन की खपत बढ़ जाती है और सिस्टम प्रदर्शन प्रभावित होता है। pgpool-II में कनेक्शन की अधिकतम संख्या की भी एक सीमा है, लेकिन तुरंत एक त्रुटि वापस करने के बजाय अतिरिक्त कनेक्शन कतारबद्ध हो जाएंगे।

लोड संतुलन में, यदि किसी डेटाबेस को दोहराया जाता है, तो किसी भी सर्वर पर एक SELECT क्वेरी निष्पादित करने से वही परिणाम प्राप्त होगा। pgpool-II सिस्टम के समग्र थ्रूपुट में सुधार करते हुए, कई सर्वरों के बीच SELECT क्वेरी को वितरित करके प्रत्येक PostgreSQL सर्वर पर लोड को कम करने के लिए प्रतिकृति सुविधा का लाभ उठाता है। सबसे अच्छा, प्रदर्शन आनुपातिक रूप से PostgreSQL सर्वरों की संख्या में सुधार करता है। लोड बैलेंस उस स्थिति में सबसे अच्छा काम करता है जहां बहुत सारे उपयोगकर्ता एक ही समय में कई क्वेरी निष्पादित कर रहे हों।

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

Pgpool का PostgreSQL के लिए उपयोग करने के लाभ

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

Pgpool-II में SQL पार्सर भी है। इसका मतलब है कि यह SQL को सटीक रूप से पार्स करने और क्वेरी को फिर से लिखने में सक्षम है। यह Pgpool-II को क्वेरी अनुरोध के आधार पर समानता को बढ़ावा देने की अनुमति देता है।

Pgpool का PostgreSQL के लिए उपयोग करने के नुकसान

Pgpool-II STONITH (सिर में दूसरे नोड को शूट करें) की पेशकश नहीं करता है जो नोड फेंसिंग तंत्र प्रदान करता है। यदि PostgreSQL सर्वर विफल हो जाता है, तो यह सेवा की उपलब्धता को बनाए रखता है। पीजीपूल-द्वितीय विफलता का एकल बिंदु (एसपीओएफ) भी हो सकता है। एक बार नोड नीचे चला जाता है, तो उस बिंदु से आपका डेटाबेस कनेक्टिविटी और उपलब्धता बंद हो जाती है। हालांकि यह Pgpool-II के साथ अतिरेक होने और कई Pgpool-II नोड्स को समन्वित करने के लिए वॉचडॉग का उपयोग करके तय किया जा सकता है, जो अतिरिक्त काम जोड़ता है।

दुर्भाग्य से, कनेक्शन पूलिंग के लिए, केवल कनेक्शन पूलिंग पर ध्यान केंद्रित करने वालों के लिए, Pgpool-II जो बहुत अच्छा नहीं करता है, वह है कनेक्शन पूलिंग, विशेष रूप से ग्राहकों की एक छोटी संख्या के लिए। चूंकि प्रत्येक चाइल्ड प्रोसेस का अपना पूल होता है, और यह नियंत्रित करने का कोई तरीका नहीं है कि कौन सा क्लाइंट किस चाइल्ड प्रोसेस से कनेक्ट होता है, कनेक्शन का पुन:उपयोग करने की बात आती है तो बहुत कुछ भाग्य पर छोड़ दिया जाता है।

अपने PostgreSQL लोड को संतुलित करने के लिए JDBC ड्राइवर का उपयोग करना

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

PostgreSQL JDBC ड्राइवर (संक्षेप में PgJDBC) जावा प्रोग्राम को मानक, डेटाबेस स्वतंत्र जावा कोड का उपयोग करके PostgreSQL डेटाबेस से कनेक्ट करने की अनुमति देता है। एक खुला स्रोत JDBC ड्राइवर है जो Pure Java (टाइप 4) में लिखा गया है, और PostgreSQL नेटिव नेटवर्क प्रोटोकॉल में संचार करता है। इस वजह से, ड्राइवर प्लेटफॉर्म स्वतंत्र है; एक बार संकलित हो जाने पर, ड्राइवर का उपयोग किसी भी सिस्टम पर किया जा सकता है।

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

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

targetServerType - PostgreSQL सर्वर के लिए परिभाषित कारक के अनुसार केवल आवश्यक स्थिति/भूमिका वाले सर्वर से कनेक्शन खोलने की अनुमति देता है। अनुमत मान कोई भी, प्राथमिक, मास्टर (बहिष्कृत), दास (बहिष्कृत), माध्यमिक, वरीयता दास, और पसंद माध्यमिक हैं। राज्य या भूमिका यह देखकर निर्धारित की जाती है कि सर्वर लिखने की अनुमति देता है या नहीं।
hostRecheckSeconds - यह नियंत्रित करता है कि JVM वाइड ग्लोबल कैश में होस्ट राज्य के बारे में ज्ञान कितने सेकंड में कैश किया जाता है। डिफ़ॉल्ट मान 10 सेकंड है।
loadBalanceHosts - यदि पहले होस्ट को हमेशा आजमाया जाता है (जब गलत पर सेट किया जाता है) या यदि कनेक्शन यादृच्छिक रूप से चुने जाते हैं (जब सत्य पर सेट होते हैं) तो आपको कॉन्फ़िगर करने की अनुमति देता है

तो loadBalanceHosts का उपयोग करना जो एक बूलियन मान स्वीकार करता है। loadBalanceHosts अपने डिफ़ॉल्ट मोड के दौरान अक्षम है और होस्ट दिए गए क्रम में जुड़े हुए हैं। यदि सक्षम मेजबानों को उपयुक्त उम्मीदवारों के समूह से यादृच्छिक रूप से चुना जाता है। jdbc का उपयोग करके डेटाबेस से कनेक्ट करते समय मूल सिंटैक्स इस प्रकार है,

jdbc:postgresql:database
jdbc:postgresql:/
jdbc:postgresql://host/database
jdbc:postgresql://host/
jdbc:postgresql://host:port/database
jdbc:postgresql://host:port/

यह देखते हुए कि loadBalanceHosts और कनेक्शन को नीचे की तरह कॉन्फ़िगर किए गए कई होस्ट प्राप्त होते हैं,

jdbc:postgresql://host1:port1,host2:port2,host3:port3/database

यह JDBC को उपयुक्त उम्मीदवारों के समूह से बेतरतीब ढंग से चुनने की अनुमति देता है।

PgJDBC का PostgreSQL के लिए उपयोग करने के लाभ

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

PgJDBC का PostgreSQL के लिए उपयोग करने के विपक्ष

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

आपके PostgreSQL लोड संतुलन के लिए libpq के साथ लागू किए गए रैपर या टूल के बारे में क्या?

libpq PostgreSQL के लिए C एप्लिकेशन प्रोग्रामर का इंटरफ़ेस है। libpq लाइब्रेरी फ़ंक्शंस का एक सेट है जो क्लाइंट प्रोग्राम को PostgreSQL बैकएंड सर्वर पर क्वेरी पास करने और इन प्रश्नों के परिणाम प्राप्त करने की अनुमति देता है।

libpq कई अन्य PostgreSQL एप्लिकेशन इंटरफेस के लिए अंतर्निहित इंजन भी है, जिनमें C++, PHP, Perl, Python, Tcl, Swift और ECPG के लिए लिखे गए इंटरफेस शामिल हैं। तो यदि आप उन पैकेजों में से किसी एक का उपयोग करते हैं तो libpq के व्यवहार के कुछ पहलू आपके लिए महत्वपूर्ण होंगे।

libpq लोड संतुलन को स्वचालित नहीं करता है और इसे लोड संतुलन समाधान के लिए एक उपकरण के रूप में नहीं माना जाना चाहिए। फिर भी, यदि कनेक्शन के लिए सूचीबद्ध पिछले सर्वर विफल हो जाते हैं, तो यह अगले उपलब्ध सर्वर से कनेक्ट होने में सक्षम है। उदाहरण के लिए, यदि आपके पास दो उपलब्ध हॉट स्टैंडबाय नोड्स हैं, यदि पहला नोड बहुत व्यस्त है और संबंधित टाइमआउट मान का जवाब देने में विफल रहता है, तो यह दिए गए कनेक्शन में अगले उपलब्ध नोड से जुड़ता है। यह इस बात पर निर्भर करता है कि आपने किस प्रकार की सत्र विशेषताएँ निर्दिष्ट की हैं। यह पैरामीटर target_session_attrs पर निर्भर करता है।

पैरामीटर target_session_attrs पढ़ने-लिखने के मानों को स्वीकार करता है, और कोई भी जो निर्दिष्ट नहीं होने पर डिफ़ॉल्ट मान है। क्या पैरामीटर target_session_attrs यह है कि, यदि पढ़ने-लिखने के लिए सेट किया जाता है, तो केवल एक कनेक्शन जिसमें कनेक्शन के दौरान पढ़ने-लिखने के लेनदेन स्वीकार किए जाते हैं। किसी भी सफल कनेक्शन पर SHOW transaction_read_only क्वेरी भेजी जाएगी। यदि परिणाम चालू है, तो कनेक्शन बंद हो जाएगा, जिसका अर्थ है कि नोड को प्रतिकृति के रूप में पहचाना जाता है या लिखने की प्रक्रिया नहीं करता है। यदि कनेक्शन स्ट्रिंग में एकाधिक होस्ट निर्दिष्ट किए गए थे, तो किसी भी शेष सर्वर को वैसे ही आज़माया जाएगा जैसे कनेक्शन प्रयास विफल हो गया था। इस पैरामीटर का डिफ़ॉल्ट मान, कोई भी, जिसका अर्थ है कि सभी कनेक्शन स्वीकार्य हैं। हालांकि लोड संतुलन के लिए target_session_attrs पर निर्भर होना पर्याप्त नहीं है, आप राउंड-रॉबिन फैशन का अनुकरण करने में सक्षम हो सकते हैं। libpq का उपयोग करके नीचे मेरा उदाहरण सी कोड देखें,

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <time.h>

#include <unistd.h>

#include <libpq-fe.h>




const char* _getRoundRobinConn() {

   char* h[2];

   h[0] = "dbname=node40 host=192.168.30.40,192.168.30.50";

   h[1] = "dbname=node50 host=192.168.30.50,192.168.30.40";



   time_t t;

   //srand((unsigned)time(&t));

   sleep(1.85);

   srand((unsigned)time(NULL));



   return h[rand() % 2];

}



void

_connect()

{

  PGconn *conn;

  PGresult *res;

  char strConn[120];




  snprintf(strConn, 1000, "user=dbapgadmin password=dbapgadmin %s target_session_attrs=any", _getRoundRobinConn());

  //printf("\nstrConn value is: %s\n", strConn);



  conn = PQconnectdb(strConn);



  res = PQexec(conn, "SELECT current_database(), inet_client_addr();");



  if ( PQresultStatus(res)==PGRES_TUPLES_OK )

  {

    printf("current_database = %s on %s\n", PQgetvalue(res, 0, 0),

PQhost(conn));

  } else {



    printf("\nFailed... Message Code is: %d\n", PQresultStatus(res));

  }



  PQclear(res);

  PQfinish(conn);



}



int main(void)

{

  int i;

  for (i=0 ; i<5 ; i++)

    _connect();



  return 0;

}

परिणाम से पता चलता है,

[email protected]:/home/vagrant# gcc -I/usr/include/postgresql -L/usr/lib/postgresql/12/lib libpq_conn.c -lpq -o libpq_conn; ./libpq_conn

current_database = node40 on 192.168.30.40

current_database = node40 on 192.168.30.40

current_database = node50 on 192.168.30.50

current_database = node40 on 192.168.30.40

current_database = node50 on 192.168.30.50

ध्यान दें कि, यदि नोड .40 (प्राथमिक नोड) नीचे चला जाता है, तो यह हमेशा कनेक्शन को .50 पर निर्देशित करेगा, जब तक कि आपका target_session_attrs मान कोई भी हो।

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

PostgresQL के लिए libpq का उपयोग करने के लाभ

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

PostgresQL के लिए libpq का उपयोग करने के विपक्ष

लोड समानांतरवाद के लिए कार्यान्वयन के अनुसार सही नहीं है और आपको कोड द्वारा अपना लोड संतुलन तंत्र लिखना होगा। ऐसा कोई कॉन्फ़िगरेशन नहीं है जिसे आप उपयोग या अनुकूलित कर सकते हैं क्योंकि यह केवल PostgreSQL डेटाबेस के लिए target_session_attrs param की सहायता से एक प्रोग्रामिंग इंटरफ़ेस है। इसका मतलब है, डेटाबेस कनेक्शन की रचना करते समय, आपके पास अपने प्रतिकृति/स्टैंडबाय नोड्स पर जाने वाले रीड कनेक्शन की एक श्रृंखला होनी चाहिए, फिर प्रश्न लिखें जो आपके कोड में लेखक या प्राथमिक नोड पर जाते हैं, चाहे वह आपके आवेदन में हो या आपको बनाना हो लोड संतुलन समाधान का प्रबंधन करने के लिए आपका अपना एपीआई।

इस दृष्टिकोण का उपयोग करने से निश्चित रूप से बैकएंड के रूप में डेटाबेस के लिए फ्रंट-एंड एप्लिकेशन परिप्रेक्ष्य से मिडलवेयर की आवश्यकता नहीं होती है या भरोसा नहीं होता है। बेशक यह हल्का है लेकिन कनेक्शन पर सर्वर की सूची भेजते समय, इसका मतलब यह नहीं है कि लोड को समझा जाता है और समान रूप से भेजा जाता है जब तक कि आपको इस दृष्टिकोण के लिए अपना कोड जोड़ना न पड़े। यह सिर्फ परेशानी जोड़ता है, फिर भी, पहले से मौजूद समाधान हैं तो पहिया को फिर से शुरू करने की आवश्यकता क्यों है?

निष्कर्ष

PostgreSQL के साथ अपने लोड बैलेंसर्स को लागू करने की मांग हो सकती है, लेकिन यह इस बात पर निर्भर करता है कि आप किस प्रकार के एप्लिकेशन और लागत के साथ काम कर रहे हैं। कभी-कभी, उच्च लोड मांग के लिए, लोड को ठीक से वितरित करने के लिए प्रॉक्सी के रूप में कार्य करने वाले मिडलवेयर की आवश्यकता होती है और इसकी नोड स्थिति या स्वास्थ्य की निगरानी भी होती है। दूसरी ओर, यह सर्वर संसाधनों की मांग कर सकता है या तो इसे एक समर्पित सर्वर पर चलाना पड़ता है या जरूरतों को पूरा करने के लिए अतिरिक्त सीपीयू और मेमोरी की मांग करता है और यह लागत जोड़ता है। इसलिए, एक आसान तरीका है जो अभी तक समय लेने वाला है लेकिन आपके पास पहले से उपलब्ध सर्वरों को लोड का वितरण प्रदान करता है। फिर भी इसके लिए प्रोग्रामिंग कौशल और एपीआई की कार्यक्षमता की समझ की आवश्यकता होती है।