PgDog - अलग एक्सटेंशन के बिना Postgres को shard करने का टूल

• Rust में बना PostgreSQL के लिए ट्रांज़ैक्शन पूलर और logical replication manager, जो horizontal scaling और sharding automation सुविधाएँ देता है
• एक्सटेंशन के बिना आसानी से PostgreSQL database को shard किया जा सकता है, और यह सैकड़ों database तथा लाखों के करीब connections को संभालने के लिए अनुकूलित है
• application layer (OSI 7) पर काम करने वाला DB load balancer के रूप में, SELECT को replica पर और बाकी को primary पर अपने-आप route कर सकता है
• PgBouncer की तरह transaction/session pooling को support करता है, साथ ही query को parse करके shard पर अपने-आप route करता है और result merge भी करता है
• COPY और logical replication का उपयोग करके data को shard में अपने-आप बाँटा जा सकता है या मौजूदा DB को बिना downtime के shard किया जा सकता है
• configuration को TOML फ़ाइल से आसानी से define किया जा सकता है, और runtime reconfiguration भी संभव है
• Postgres extension का उपयोग करने वाले Citus के विपरीत, यह DB के बाहर का proxy है, इसलिए RDS, Cloud SQL आदि में भी इस्तेमाल किया जा सकता है

---

प्रोजेक्ट परिचय और मुख्य मूल्य

• PgDog PostgreSQL database के लिए आसान sharding, logical replication, transaction pooling और L7 load balancing सहित हर दिशा में horizontal scaling को support करने वाला open source solution है
• Rust में विकसित होने के कारण यह high performance और security प्रदान करता है
• PgDog extension install किए बिना, सिर्फ एक proxy deployment से sharding, data distribution, failover recovery, और flexible load balancing संभव बनाता है
• प्रतिस्पर्धी उत्पादों (जैसे PgBouncer, PgCat) से अलग, यह auto sharding और logical replication दोनों को support करता है, और running system में config change तथा real-time monitoring इसकी बड़ी ताकत हैं

मुख्य फीचर्स

load balancing

• PgDog OSI layer 7 का application-level proxy है, जो कई PostgreSQL replicas और primary nodes में query बाँटकर failure और load को रोकने का काम करता है
• distribution strategy के तौर पर round robin, random, least connections आदि कई विकल्प मिलते हैं
• query के प्रकार को पहचानकर SELECT को replica और बाकी write queries को primary node पर अपने-आप भेजता है
• healthcheck और failure होने पर automatic failover करता है, जिससे network error या hardware failure में भी availability बनी रहती है

transaction pooling

• PgDog, PgBouncer की तरह transaction/session pooling के जरिए connection resources का कुशल प्रबंधन करता है, जिससे लाखों के करीब clients को भी कम backend connections से संभाला जा सकता है

sharding

• query syntax को सीधे parse करके sharding key extraction और optimal routing algorithm लागू करता है
• कई shard databases के बीच cross-shard query को भी support करता है, और result को memory में merge करके पारदर्शी रूप से client तक पहुँचाता है
• COPY command चलाने पर CSV parsing के जरिए data का multi-shard distribution support करता है, जो बड़े पैमाने पर loading के लिए सुविधाजनक है
• PostgreSQL logical replication protocol के आधार पर बिना downtime के background synchronization करता है, और running system में real-time shard add तथा scale-out संभव बनाता है

monitoring

• PgBouncer style admin database और OpenMetrics endpoint दोनों को support करता है
• Datadog जैसे external monitoring और dashboard examples भी उपलब्ध हैं

configuration और runtime

• मुख्य environments: Kubernetes (Helm chart उपलब्ध), Docker, और local environment (Rust build), जिनमें इसे आसानी से deploy और test किया जा सकता है
• आम तौर पर 2 config files (pgdog.toml, users.toml) लिखकर न्यूनतम sharding और user-based production environment तैयार किया जा सकता है
• ज़्यादातर config values को real-time में बदला जा सकता है और process restart के बिना dynamically लागू किया जा सकता है

performance और license

• PgDog, Rust और Tokio पर आधारित high-performance asynchronous network proxy है, जो data movement को न्यूनतम रखने और performance degradation को दबाने पर केंद्रित है
• benchmark results आधिकारिक docs में दिए गए हैं, जिससे performance baseline तय की जा सकती है
• AGPL v3 open source license लागू है, और enterprise internal use तथा private customization के लिए पूरी तरह खुला है
• हालांकि, public cloud service देने वाली कंपनियों के लिए code modification होने पर उसकी जानकारी साझा करने की शर्त मौजूद है

प्रोजेक्ट की स्थिति और योगदान

• फिलहाल यह शुरुआती चरण में है, इसलिए early adopters को self-adoption की सलाह दी जाती है, जबकि feature stability लगातार अपडेट हो रही है
• feature-wise testing और benchmark भी लगातार जारी हैं
• open source community से contribution का स्वागत है; अधिक जानकारी के लिए Contribution Guidelines देखें

निष्कर्ष

• PgDog, production environment में PostgreSQL की horizontal scalability, high availability, और auto sharding की ज़रूरत रखने वाली development teams और enterprises के लिए बेहतरीन solution देता है
• अलग extension या जटिल infrastructure setup के बिना भी इसे तेज़ी से लागू और customize किया जा सकता है, जो इसकी बड़ी खासियत है

[GN⁺]

Hacker News टिप्पणियाँ

• Lev को नमस्ते कहकर बताया कि वे इस समय 40TB आकार के Postgres डेटाबेस को shard करने के लिए PgDog और खुद बनाया गया समाधान, दोनों की तुलना कर रहे हैं। उन्होंने कहा कि उन्हें Vitess for PostgreSQL जैसा काम करने वाला समाधान चाहिए। scatter-gather फीचर के अलावा etcd जैसी किसी चीज़ पर आधारित config management, shard split, और सभी shards पर schema change लागू करने के लिए best-effort transaction जैसी क्षमताएँ भी ज़रूरी हैं। उन्होंने pg_query.rs के साथ query rewriting का अनुभव पूछा और साझा किया कि AST types की immutability और deep clone की कमी के कारण rewriting कठिन लगी। अंत में बताया कि वे अभी Visitor pattern को support करने वाले sqlparser crate का उपयोग कर रहे हैं, और shadow tables व logical replication पर आधारित PG के लिए online schema change का एक side project भी बना रहे हैं.

  • सहयोग के प्रस्ताव पर खुशी जताते हुए संपर्क जानकारी साझा की। बताया कि config management पहले से K8s या अलग-अलग CD tools से संभाला जा सकता है और PgDog की config reload भी sync की जा सकती है। पूरे shard schema change के लिए best-effort transaction पहले से काम कर रहा है, और idempotent schema change सबसे अच्छा है, लेकिन failure की स्थिति में 2-phase commit भी विचाराधीन है। shard split को logical replication से संभव बताया और Instacart में 10TB+ के अनुभव का ज़िक्र किया। replication slot खोलने के बाद N instances में restore, shard number से मेल न खाने वाला डेटा हटाना, और logical replication से resync करने की प्रक्रिया भी साझा की। Pg 17 की logical replication को streaming replica पर उपयोग करके parallel split का विचार बताया, और foreign tables के जरिए सीधे डेटा COPY करने का तरीका भी सोच रहे हैं। यह भी कहा कि pg_query.rs अब mutable तरीके से काम करता दिखता है, इसलिए हाल में वे इसे query rewriting और generation के लिए सक्रिय रूप से उपयोग कर रहे हैं। 100% Postgres parser पर आधारित होना इसका बड़ा फ़ायदा है, और जगह-जगह मौजूद "deparse" फीचर जटिल कामों को संभव बना सकता है.

• सवाल किया गया कि अगर Vitess for Postgres जैसी कोई चीज़ है, तो क्या Yugabyte वही भूमिका नहीं निभाता?

• कहा गया कि core features देखें तो यह छोटा लग सकता है, लेकिन PgDog के जरिए app code बदले बिना reads को read replica और writes को primary पर बाँटना बहुत बड़ा फ़ायदा है। कई apps सीधे R/W separation support नहीं करते, इसलिए proxy level पर इसे संभालने से पहले भी बड़ा performance gain मिला था। साथ ही परियोजना की प्रशंसा की गई.

  • बताया गया कि यह फीचर पहले से pgcat में भी उपलब्ध है, और pgcat लिंक साझा किया गया.

  • साझा किया गया कि Instacart में Makara का उपयोग करके R/W separation किया गया था, लेकिन Python, Go जैसी कई language environments में हर बार वही चीज़ दोबारा implement करना काफ़ी झंझट भरा था.

• परियोजना को प्रभावशाली बताया गया, लेकिन पूरी तरह automated sharding को लेकर थोड़ी झिझक जताई गई। कहा गया कि आम तौर पर sharding tenancy boundary पर की जाती है, और इस boundary को पार करने वाली चीज़ों में कुछ friction होना अच्छा है। cross-shard joins, in-shard joins से performance, memory और CPU के लिहाज़ से अलग होते हैं, इसलिए इसे और स्पष्ट रूप से सामने लाना चाहिए। फिर भी परियोजना पर संदेह नहीं है और इसके बहुत से उपयोग मामलों की संभावना बताई गई.

  • पूछा गया कि जानबूझकर friction क्यों चाहिए। जोड़ा गया कि cross-shard join performance issues अधिकतर अच्छी तरह समझे जा सकते हैं और real-time metrics से track भी किए जा सकते हैं। अंततः दोनों तरीकों की ज़रूरत होती है, और app code में join करना बहुत अच्छा विकल्प नहीं है.

• कहा गया कि वे PgDog पर नज़र रखे हुए हैं और यह बहुत प्रभावशाली है। launch पर बधाई दी और आगे भी इसके बढ़ने की उम्मीद जताई.

  • जवाब में कहा गया कि 15 साल की यात्रा अब शुरू हुई है.

• कहा गया कि network layer पर transparency और compatibility बनाए रखते हुए distributed queries संभालना इसकी सबसे बड़ी आकर्षक बात है। वर्तमान documentation में जो limitations हैं वे स्वाभाविक हैं, और इसमें trade-offs की ज़रूरत होगी। इसे कैसे हल किया जाएगा, यह जानने की उत्सुकता जताई गई और आगे चर्चा हो तो शामिल होने की इच्छा व्यक्त की गई.

  • Discord community में शामिल होने का निमंत्रण दिया गया और invite लिंक साझा किया गया.

• कहा गया कि PgDog जैसी solutions में सबसे बड़ी कठिनाई यह होती है कि sharded complex queries को आख़िरी 1% तक सही तरह संभाला जाए, या असामान्य queries को detect किया जाए, और isolation व consistency को पूरी तरह सुनिश्चित किया जाए.

• कहा गया कि docs देखते ही सबसे पहले Unique Index support देखा, लेकिन अभी यह उपलब्ध नहीं है क्योंकि इसके लिए query rewriting और अलग execution engine चाहिए। इस कमी पर अफ़सोस जताया गया, हालांकि संभावनाएँ दिखने की बात भी कही गई.

  • जवाब में बताया गया कि एक छोटे consolation के रूप में सभी shards पर unique primary key generation पहले से supported है, और संबंधित दस्तावेज़ लिंक साझा किया गया। cross-shard unique index को implement करना महँगा है क्योंकि हर query में उसे जाँचना पड़ेगा, इसलिए इस पर विचार खुले हैं.

• कहा गया कि यह कई वर्षों में देखा गया सबसे दिलचस्प Postgres project है। साथ ही यह राय दी गई कि दिए गए benchmarks शायद सिर्फ basic connection pooling को cover करते हैं, इसलिए query parsing या cross-shard joins चालू होने पर नतीजे कैसे होंगे, यह जानने की जिज्ञासा है.

  • जवाब में कहा गया कि query parser cache किया जाता है, इसलिए prepared queries या placeholders का उपयोग हो तो बस lock और hash lookup का अतिरिक्त काम होता है और overhead लगभग नहीं के बराबर है। cross-shard joins में अगर filter optimal न हो तो query processing cost बढ़ सकती है, और result set बड़ा हो तो disk पर paging की ज़रूरत पड़ सकती है। फिलहाल OLTP पर प्राथमिक ध्यान है और joins को जितना संभव हो pushdown करने की कोशिश है, लेकिन जल्द ही cross-shard join की माँग बढ़ने की भी उम्मीद है.

• इसे Postgres scalability के लिए बहुत ज़रूरी innovation बताया गया और launch पर बधाई दी गई.

• कहा गया कि project बेहद शानदार लग रहा है और release पर बधाई दी गई.

  • जवाब में ज़ोर देकर कहा गया कि यह कई वर्षों की मेहनत का परिणाम है.