PgBouncer बनाम Supavisor बनाम PgCat: कौन सा Postgres पूलर?

PgBouncer न्यूनतम करता है, बहु-किरायेदार पैमाने पर सुपरवाइज़र पूल करता है, PgCat रॉ पूलिंग में नेटवर्क फ़ंक्शंस जोड़ता है। तीनों में से कोई भी अन्य दो का प्रत्यक्ष प्रतिस्थापन नहीं है, हालाँकि अक्सर समान पृष्ठों पर उनकी शब्द दर शब्द तुलना की जाती है।

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

PgBouncer केवल एक ही काम करता है: पूल पोस्टग्रेज़ कनेक्शन, बिना किसी अतिरिक्त फ़ंक्शन के। यह जानबूझकर संकीर्ण दायरा काफी हद तक इसकी लंबी उम्र और उत्पादन में अधिकांश पोस्टग्रेज स्टैक में बुनियादी बिल्डिंग ब्लॉक के रूप में इसके अपनाने की व्याख्या करता है।

Three pooling modes are available. Session mode opens one server connection per client connection, the most permissive. Transaction mode reuses a server connection between several clients, released at each end of a transaction. Statement mode goes even further, and is rarely used in production. It is the transaction mode that brings the real pooling gain, but it imposes strict rules. Any session state (SETvariables, advisory locks, LISTEN/NOTIFY) does not survive beyond a transaction. We detail these rules and their pitfalls in our dedicated article on the transaction pooling mode of PgBouncer.

ऐतिहासिक रूप से एकल-प्रक्रिया, एक PgBouncer उदाहरण डिफ़ॉल्ट रूप से एकल CPU कोर का उपयोग करता है। एक ही पोर्ट के पीछे कई इंस्टेंस चलाना (SO_REUSEPORTके माध्यम से) प्रोजेक्ट का हालिया विकास है, प्रारंभिक डिज़ाइन सुविधा नहीं। प्रमाणीकरण पक्ष पर, PgBouncer एक कॉन्फ़िगर करने योग्य auth_queryका समर्थन करता है, जो किसी भूमिका के पासवर्ड को गतिशील रूप से हल करने के लिए प्रत्येक कनेक्शन पर निष्पादित एक SQL फ़ंक्शन है। यह तंत्र प्रत्येक उपयोगकर्ता को पहले से सूचीबद्ध करने वाली एक स्थिर फ़ाइल पर निर्भर होने से बचाता है। यह बिल्कुल यही तंत्र है जिसका उपयोग ऑराबेस अपनी प्रति-प्रोजेक्ट भूमिकाओं (धारा 05) के लिए करता है।

सुपरवाइज़र एक ऐसी समस्या का समाधान करता है जिसे PgBouncer को इस पैमाने पर हल करने के लिए कभी डिज़ाइन नहीं किया गया था। इसमें प्रति डेटाबेस एक पूलर उदाहरण के बजाय एक ही सेवा से बहुत बड़ी संख्या में अलग-अलग किरायेदार डेटाबेस की सेवा करना शामिल है। एलिक्सिर में लिखा गया है और एरलांग वर्चुअल मशीन (बीईएएम) पर निष्पादित किया गया है, यह प्रोजेक्ट सुपरबेस द्वारा अपने स्वयं के गिटहब रिपॉजिटरी पर खुले स्रोत में विकसित और रखरखाव किया गया है।

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

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

PgCat को स्पष्ट रूप से रस्ट में लिखे गए PgBouncer के विकल्प के रूप में तैनात किया गया है। यह क्लासिक पूलिंग में नेटवर्क फ़ंक्शंस जोड़ता है जिसे न तो PgBouncer और न ही Supavisor मूल रूप से एम्बेड करता है। विशेष रूप से तीन: विभाजन कुंजी द्वारा एप्लिकेशन शार्डिंग, पढ़ी गई प्रतिकृतियों के बीच लोड संतुलन, और एक विफल प्रतिकृति से दूर स्वचालित विफलता। इस परियोजना का जन्म इंस्टाकार्ट में हुआ था, जिसे आज पोस्टग्रेसएमएल द्वारा संभाला और बनाए रखा गया है।

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

विपरीत समझौता भी मौजूद है: PgCat एक युवा परियोजना है, जिसमें PgBouncer की तुलना में दस्तावेज़ीकरण और उत्पादन प्रतिक्रिया का बहुत छोटा पारिस्थितिकी तंत्र है। इसके शार्डिंग और फेलओवर कार्यों को अपनाने का अर्थ केवल इसकी पूलिंग क्षमता पर नहीं, बल्कि इस विशिष्ट घटक की परिपक्वता पर निर्भर रहने के लिए सहमत होना भी है।

ऑराबेस रिपॉजिटरी लेनदेन मोड में, दो अलग-अलग स्तरों पर PgBouncer को तैनात करती है। साझा बेड़े के लिए, हेल्म चार्ट साझा डेटा-प्लेन (deploy/helm/aurabase/templates/infra/pgbouncer.yaml, छवि edoburu/pgbouncer) के सामने एक समर्पित PgBouncer तैनाती को परिभाषित करता है। एक समर्पित उदाहरण पर किरायेदार के लिए, प्रावधानकर्ता एक संसाधन Pooler उत्पन्न करता है जिसे मूल रूप से CloudNativePG (deploy/cnpg/tenant-pooler.yaml, k8s_tenant.rsद्वारा प्रस्तुत) द्वारा प्रबंधित किया जाता है। न तो सुपवाइज़र या पीजीकैट का उपयोग करता है। कोड इस विकल्प से पहले की किसी स्पष्ट तुलना का दस्तावेजीकरण नहीं करता है। दूसरी ओर, यह CloudNativePG पारिस्थितिकी तंत्र के साथ एक गहरा और पहले से ही परिचालन एकीकरण दिखाता है, इस तथ्य के अनुरूप है कि PgBouncer देशी पूलिंग ईंट है।

हालाँकि, सब कुछ पूलर के माध्यम से नहीं जाता है, और यह कोड में ही प्रलेखित एक जानबूझकर किया गया विकल्प है। PostgREST Postgres से लाइव जुड़ा रहता है, PgBouncer के माध्यम से कभी नहीं। हेल्म चार्ट टिप्पणी कारण के बारे में स्पष्ट है: लेनदेन पूलिंग इसके स्कीमा पुनः लोड को तोड़ देगी, जो pgrstचैनल पर LISTEN पर निर्भर करता है। यह तंत्र क्लाइंट के बीच पुनर्नवीनीकरण सर्वर कनेक्शन के साथ असंगत है।aura-db प्रशासन पूल (स्कीमा, डीडीएल, सत्र सलाहकार लॉक) भी उसी मूल कारण से सीधे कनेक्शन में रहता है। गैर-लेनदेन-स्कोप वाले SET search_path और सत्र लॉक लेनदेन मोड पूलर से बच नहीं पाते हैं।

# डेटा-प्लेन ऑरा-डीबी: पीजीबाउंसर के माध्यम से, सब कुछ लेनदेन के दायरे में है (स्थानीय सेट करें)
DATABASE_URL: postgresql://aura_authenticator:...@pgbouncer:5432/aura_db_master

# पूल व्यवस्थापक (डीडीएल, आत्मनिरीक्षण): सीधे पोस्टग्रेज पर, पीजीबाउंसर पर कभी नहीं
# SET search_path गैर-स्थानीय + सत्र लॉक लेनदेन पूलिंग को तोड़ते हैं
ADMIN_DATABASE_URL: postgresql://aura:...@postgres:5432/aura_db_master

प्रमाणीकरण अनुभाग 02 में वर्णित auth_query पैटर्न का अनुसरण करता है: AUTH_QUERY: SELECT * FROM pgbouncer.user_lookup($1), बिना किसी स्थिर userlist.txt फ़ाइल के। यह वह है जो प्रति प्रोजेक्ट (project_<uuid>_authenticator) में गतिशील रूप से बनाई गई भूमिकाओं को प्रत्येक नए प्रोजेक्ट के लिए पूलर को फिर से तैनात किए बिना PgBouncer के माध्यम से प्रमाणित करने की अनुमति देता है।

एक आखिरी विवरण, मामूली लेकिन खुलासा करने वाला: हेल्म चार्ट डिफ़ॉल्ट रूप से edoburu/pgbouncer:v1.24.1-p1 पिन करता है, जबकि स्थानीय k3d बेंच v1.25.2-p0का उपयोग करता है। यह एक वास्तुशिल्प विकल्प नहीं है, बस दो परिवेशों के बीच संस्करण सिंक्रनाइज़ेशन की थोड़ी सी कमी है, जिस तरह का विवरण एक कोड समीक्षा ब्लॉग पोस्ट की तुलना में तेजी से पकड़ती है। हम इसे सजाने-संवारने के बजाय इसे वैसे ही प्रलेखित करते हैं जैसे यह है। इस पूलर द्वारा कार्य किए जाने वाले स्कीमा विभाजन के विवरण के लिए,मल्टी-टेनेंट आरएलएस आइसोलेशनपर हमारा आलेख देखें।

पीजीबाउंसर चुनें यदि…

• पोस्टग्रेज़ क्लस्टर सामान्यतः CloudNativePG या Kubernetes द्वारा प्रबंधित किया जाता है
• आप सबसे सिद्ध और अच्छी तरह से प्रलेखित पूलर चाहते हैं
• प्रति पूलर उदाहरण के लिए एक लक्ष्य आधार आपके लिए उपयुक्त है

पर्यवेक्षक चुनें यदि…

• एक ही सेवा के पीछे सैकड़ों या हजारों आधार
• पुनर्नियोजन के बिना, एपीआई के माध्यम से किरायेदारों को गतिशील रूप से पंजीकृत करने की आवश्यकता है
• पहले से ही सुपाबेस पारिस्थितिकी तंत्र में है या उस पर निर्भर रहने को तैयार है

PgCat चुनें यदि…

• एप्लिकेशन साझाकरण पहले से ही मौजूद है या पूलर स्तर पर नियोजित है
• अलग अनुप्रयोग परत के बिना लोड संतुलन और फेलओवर प्रतिकृति
• एक युवा परियोजना के साथ सहज, PgBouncer की तुलना में कम दस्तावेजित

जो भी पूलर चुना जाता है, वह पोस्टग्रेज़ के आकार को प्रतिस्थापित नहीं करता है। पूल आकार और सर्वर max_connections पर एक साथ विचार किया जाना चाहिए, एक के बाद एक नहीं। बहुत कम max_connections के सामने एक उदार पूल बस संतृप्ति को एक स्तर से दूसरे स्तर पर स्थानांतरित कर देता है। ट्यूनिंग max_connections पर हमारी मार्गदर्शिका आपके पूल का आकार निर्धारित करने से पहले लागू करने के लिए आकार निर्धारण सूत्र का विवरण देती है।

PgBouncer, Supavisor और PgCat एक ही समस्या के तीन संस्करण हल करते हैं, एक ही टूल के तीन संस्करण नहीं। जब आपका प्लेटफ़ॉर्म पहले से ही Kubernetes और CloudNativePG पर निर्भर है, या जब आप बस सबसे अधिक दस्तावेज़ीकृत पूलर चाहते हैं, तो PgBouncer सबसे सुरक्षित विकल्प बना रहता है। पर्यवेक्षक एक ही सेवा से सेवारत आधारों की एक निश्चित संख्या से परे प्रासंगिक हो जाता है। यदि आप नेटवर्क स्तर पर शार्डिंग और रेप्लिका फेलओवर से चूक जाते हैं, तो PgCat चक्कर लगाने लायक है, बशर्ते आप एक युवा प्रोजेक्ट की परिपक्वता को स्वीकार करें।

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