बहुत समय पहले, बहुत दूर आकाशगंगा में, 'थ्रेड्स' एक प्रोग्रामिंग नवीनता थी जिसका शायद ही कभी उपयोग किया जाता था और शायद ही कभी उस पर भरोसा किया जाता था। उस माहौल में, पहले पोस्टग्रेएसक्यूएल डेवलपर्स ने फैसला किया कि डेटाबेस से प्रत्येक कनेक्शन के लिए एक प्रक्रिया को फोर्क करना सबसे सुरक्षित विकल्प है। अगर आपका डेटाबेस क्रैश हो गया तो यह शर्म की बात होगी।
तब से, उस पुल के नीचे बहुत सारा पानी बह चुका है, लेकिन PostgreSQL समुदाय अपने मूल निर्णय पर अड़ा हुआ है। उनके तर्क को गलत ठहराना मुश्किल है - क्योंकि यह बिल्कुल सच है कि:
- प्रत्येक क्लाइंट की अपनी प्रक्रिया होती है, जो खराब व्यवहार करने वाले क्लाइंट को पूरे डेटाबेस को क्रैश होने से रोकता है।
- आधुनिक Linux सिस्टम पर, प्रक्रिया को फोर्क करने और थ्रेड बनाने के बीच ओवरहेड में अंतर पहले की तुलना में बहुत कम है।
- मल्टीथ्रेडेड आर्किटेक्चर में जाने के लिए व्यापक पुनर्लेखन की आवश्यकता होगी।
हालांकि, आधुनिक वेब अनुप्रयोगों में, क्लाइंट बहुत सारे कनेक्शन खोलते हैं। डेवलपर्स अक्सर डेटाबेस कनेक्शन रखने से दृढ़ता से हतोत्साहित होते हैं जबकि अन्य ऑपरेशन होते हैं। "जितनी जल्दी हो सके एक कनेक्शन खोलें, जितनी जल्दी हो सके एक कनेक्शन बंद करें"। लेकिन यह पोस्टग्रेएसक्यूएल के आर्किटेक्चर के साथ एक समस्या का कारण बनता है - जब लेनदेन बहुत कम होता है, तो एक प्रक्रिया को महंगा करना महंगा हो जाता है, जैसा कि सामान्य ज्ञान बताता है कि उन्हें होना चाहिए।
कनेक्शन पूल आर्किटेक्चर
आधुनिक भाषा पुस्तकालय का उपयोग करने से समस्या कुछ हद तक कम हो जाती है - कनेक्शन पूलिंग सबसे लोकप्रिय डेटाबेस-एक्सेस लाइब्रेरी की एक अनिवार्य विशेषता है। यह सुनिश्चित करता है कि 'बंद' कनेक्शन वास्तव में बंद नहीं हैं, लेकिन एक पूल में वापस आ गए हैं, और एक नया कनेक्शन 'खोलने' से वही 'भौतिक कनेक्शन' वापस आ जाता है, जिससे PostgreSQL पक्ष पर वास्तविक फोर्किंग कम हो जाती है।
हालांकि, आधुनिक वेब एप्लिकेशन शायद ही कभी अखंड होते हैं, और अक्सर कई भाषाओं और तकनीकों का उपयोग करते हैं। प्रत्येक मॉड्यूल में कनेक्शन पूल का उपयोग करना शायद ही कुशल हो:
- अपेक्षाकृत कम संख्या में मॉड्यूल और प्रत्येक में एक छोटे पूल आकार के साथ, आप बहुत सारी सर्वर प्रक्रियाओं के साथ समाप्त होते हैं। उनके बीच प्रसंग-स्विच करना महंगा है।
- पूलिंग समर्थन पुस्तकालयों और भाषाओं के बीच व्यापक रूप से भिन्न होता है - एक बुरी तरह से व्यवहार करने वाला पूल सभी संसाधनों का उपभोग कर सकता है और अन्य मॉड्यूल द्वारा डेटाबेस को दुर्गम छोड़ सकता है।
- कोई केंद्रीकृत नियंत्रण नहीं है - आप क्लाइंट-विशिष्ट पहुंच सीमा जैसे उपायों का उपयोग नहीं कर सकते।
परिणामस्वरूप, PostgreSQL के लिए लोकप्रिय मिडलवेयर विकसित किए गए हैं। ये डेटाबेस और क्लाइंट्स के बीच बैठते हैं, कभी-कभी एक अलग सर्वर (भौतिक या वर्चुअल) पर और कभी-कभी एक ही बॉक्स पर, और एक पूल बनाते हैं जिससे क्लाइंट कनेक्ट हो सकते हैं। ये मिडलवेयर हैं:
- पोस्टग्रेएसक्यूएल और आधुनिक डीबीएमएस के बीच इसकी अनूठी वास्तुकला के लिए अनुकूलित।
- विभिन्न ग्राहकों के लिए केंद्रीकृत अभिगम नियंत्रण प्रदान करें।
- आपको क्लाइंट-साइड पूल के समान पुरस्कार प्राप्त करने की अनुमति देता है, और फिर कुछ और (हम अपनी अगली पोस्ट में इन पर और अधिक विस्तार से चर्चा करेंगे)!
PostgreSQL कनेक्शन पूलर विपक्ष
एक कनेक्शन पूलर उत्पादन के लिए तैयार PostgreSQL सेटअप का लगभग अनिवार्य हिस्सा है। जबकि एक कनेक्शन पूलर का उपयोग करने के लिए बहुत सारे अच्छी तरह से प्रलेखित लाभ हैं, वहां हैं किसी एक का उपयोग करने के विरुद्ध किए जाने वाले कुछ तर्क:
- संचार में एक मिडलवेयर का परिचय अनिवार्य रूप से कुछ विलंबता का परिचय देता है। हालांकि, जब एक ही होस्ट पर स्थित होता है, और कनेक्शन फोर्किंग के ऊपरी हिस्से में फैक्टरिंग होता है, तो व्यवहार में यह नगण्य है जैसा कि हम अगले भाग में देखेंगे।
- एक मिडलवेयर विफलता का एकल बिंदु बन जाता है। इस स्तर पर क्लस्टर का उपयोग करने से इस समस्या का समाधान हो सकता है, लेकिन यह वास्तुकला में अतिरिक्त जटिलता का परिचय देता है।
- एक मिडलवेयर का अर्थ है अतिरिक्त लागत। आपको या तो एक अतिरिक्त सर्वर (या 3) की आवश्यकता है, या आपके डेटाबेस सर्वर के पास PostgreSQL के अलावा, एक कनेक्शन पूलर का समर्थन करने के लिए पर्याप्त संसाधन होने चाहिए।
- विभिन्न मॉड्यूल के बीच कनेक्शन साझा करना सुरक्षा भेद्यता बन सकता है। यह बहुत महत्वपूर्ण है कि पूल में वापस आने से पहले हम कनेक्शन को साफ करने के लिए pgPool या PgBouncer को कॉन्फ़िगर करें।
- प्रमाणीकरण DBMS से कनेक्शन पूलर में शिफ्ट हो जाता है। यह हमेशा स्वीकार्य नहीं हो सकता है।
- यह हमले के लिए सतह क्षेत्र को बढ़ाता है, जब तक कि अंतर्निहित डेटाबेस तक पहुंच को केवल कनेक्शन पूलर के माध्यम से एक्सेस की अनुमति देने के लिए लॉक नहीं किया जाता है।
- यह एक और घटक बनाता है जिसे बनाए रखा जाना चाहिए, आपके कार्यभार के लिए ठीक ट्यून किया जाना चाहिए, सुरक्षा को अक्सर पैच किया जाता है, और आवश्यकतानुसार अपग्रेड किया जाता है।
क्या आपको PostgreSQL कनेक्शन पूलर का उपयोग करना चाहिए?
हालांकि, इन सभी समस्याओं पर PostgreSQL समुदाय में अच्छी तरह से चर्चा की गई है, और शमन रणनीतियां सुनिश्चित करती हैं कि कनेक्शन पूलर के फायदे उनके नुकसान से कहीं अधिक हैं। हमारे परीक्षणों से पता चलता है कि कनेक्शन पूलर का उपयोग करने से ग्राहकों की एक छोटी संख्या भी महत्वपूर्ण रूप से लाभान्वित हो सकती है। वे अतिरिक्त कॉन्फ़िगरेशन और रखरखाव के प्रयास के लायक हैं।
अगले पोस्ट में, हम PostgreSQL दुनिया में सबसे लोकप्रिय कनेक्शन पूलर्स में से एक पर चर्चा करेंगे - PgBouncer, उसके बाद Pgpool-II, और अंत में इन दोनों के प्रदर्शन परीक्षण की तुलना श्रृंखला के हमारे अंतिम पोस्ट में PostgreSQL कनेक्शन पूलर।
PostgreSQL कनेक्शन पूलिंग सीरीज
|
|---|
