Connection limit capacity plan नहीं है। सभी pools का budget बनाएँ, stale reads की सीमा तय करें और disposable cache को business obligations से अलग रखें।
लेखक
Anichur Rahaman
सुबह 9:02 के एक teaching scenario में report, document-index rebuild और background jobs साथ चल रहे हैं; checkout धीमा है। Connection dashboard व्यस्त दिखता है। बड़ा database मदद कर सकता है, लेकिन पहले पता करें कि request connection, row lock, disk या उपयोगी CPU work का इंतज़ार कर रही है।
Engineering for High Volume के part 3 का सिद्धांत: authoritative order path का स्पष्ट resource और consistency budget हो। Cache, replica और semantic index मदद कर सकते हैं; unavailable stock बेचने या private record खोलने का अधिकार नहीं बनते। यहाँ customer benchmark या व्यक्तिगत load-test result का दावा नहीं है।
Offered/completed business transactions, latency tails, pool wait, active/idle/idle-in-transaction sessions, long transactions, blocking locks, CPU, I/O, WAL और maintenance pressure साथ मापें। PostgreSQL connection limits सीमित slots और resources से जुड़े हैं; slots खत्म होना ख़ुद incident हो सकता है। चार vCPU का अर्थ केवल चार queries progress में होना नहीं: I/O waits और parallel execution भी होते हैं।
ज्ञात interval में cumulative query cost और call counts के लिए pg_stat_statements देखें। Representative plans में EXPLAIN उपयोगी है; ANALYZE statement सच में चलाता है। Production पर modifying या expensive plan असावधानी से न चलाएँ। Rollback हर external या nontransactional side effect नहीं मिटाता।
एक list और 50 rows की हर relation के लिए अतिरिक्त query हो तो इस सरल N+1 pattern में 51 queries हैं। सही eager loading, indexes और छोटे transactions मदद कर सकते हैं; indexes write/storage खर्च भी बढ़ाते हैं। Plans और वास्तविक data skew जाँचें। Emergency resizing उचित mitigation हो सकती है; नई load test से पहले कभी resize नहीं का absolute rule गलत है। मापा bottleneck सुधारकर retest करें।
उदाहरण में तीन web nodes पर 40 database clients प्रति node, 16 workers और 4 operational clients, हर एक connection खोले तो 140 potential clients हैं। यह simultaneous useful queries या TPS नहीं। Pooling backend lease साझा करता है; SQL, locks और storage मुफ़्त नहीं होते।
Database limit 150 में 10 emergency और 20 direct/maintenance slots का budget मानें। Application के लिए 120 बचते हैं। ये teaching allocations हैं, recommended PostgreSQL settings नहीं। PgBouncer configuration reference ordinary pool को user/database pair से जोड़ता है। Deploy/failover overlap सहित सभी poolers, pairs, reserves और direct routes जोड़ें।
दो pooler processes × तीन active user/database pairs ×20 ordinary backends =120 । छह pools में पाँच-पाँच reserve जोड़ें तो application demand 150; दूसरे 30 allocations के साथ 180, जबकि limit 150 है। Local pool cap global cap नहीं। एक pooler के database/user caps सभी instances में साझा नहीं होते।
| उदाहरण allocation | Connections |
|---|---|
| Database ceiling | 150 |
| Emergency allocation | 10 |
| Direct/maintenance allocation | 20 |
| Application ordinary pools: 2×3×20 | 120 |
| Additional pool reserve: 2×3×5 | 30 |
| Reserves सहित कुल: 120+30+20+10 | 180 |
अलग steady-state उदाहरण: 300 transactions/s × mean backend lease 0.04 s = औसतन 12 leased connections । यह max-pool recommendation या 4,000 TPS promise नहीं। Lease में transaction पकड़े रहने का समय शामिल है; long tails और idle transactions बदल सकते हैं। Wait, request deadline और admission सीमित करें ताकि pool केवल unbounded queue की जगह न बदले।
PgBouncer feature map session, transaction और statement pooling अलग करता है। Session client session तक backend रखता है; transaction mode transaction समाप्त होने पर छोड़ता है; statement mode multi-statement transactions नहीं देता। ज़रूरी behaviour देखें, transaction हमेशा तेज़तम का नियम नहीं।
Mode बदलने से पहले listeners, session advisory locks, temporary objects, settings और drivers test करें। उचित version और nonzero max_prepared_statements में protocol-level prepared plans support हो सकते हैं; SQL PREPARE/DEALLOCATE अलग है। Compatibility table में NOTIFY और LISTEN एक नहीं हैं।
Tenant identity या authorisation को ऐसे session setting में न छोड़ें जो अगले client तक leak हो। Scoped queries और database privileges लागू हों। Transaction-scoped context जानबूझकर सही establish और clear करें। Listener/admin tools के लिए restricted direct/session route हो सकता है, अपने capacity/security budget के साथ; हर migration का unrestricted bypass नहीं।
Business definition स्वीकार करे तभी lag-tolerant काम भेजें। Hot-standby documentation read-only queries और recovery conflicts बताता है; लंबी report cancel हो सकती है या replay behaviour प्रभावित कर सकती है। Read replica हमेशा ताज़ा, स्वतंत्र या unlimited analytics का साधन नहीं।
इस design में authoritative stock reservation, payment state और access decisions primary पर रखें। Read-after-write में primary routing या सिद्ध consistency mechanism चाहिए। Measured freshness limit और lag बढ़ने पर behaviour तय करें। हर failed report primary पर भेजना checkout overload कर सकता है।
PostgreSQL replication documentation के अनुसार asynchronous failover acknowledged changes खो सकता है। Synchronous choices latency/availability trade-offs लाते हैं; चुनी acknowledgement policy test करें। Replica backup या पूरा HA system नहीं। Promotion, पुराने primary की fencing, routing और recovery के अभ्यास तथा owner और RPO/RTO चाहिए।
Prefixes/logical database numbers keys व्यवस्थित करते हैं; एक Redis/Valkey instance में अलग memory limit, eviction, persistence या fault domain नहीं बनाते। FLUSHALL logical databases पार करता है; गलत prefix deletion दूसरी data भी मिटा सकता है। अलग policies के लिए नियंत्रित अलग instances/services और shared-host failure/resource contention का आकलन करें।
Redis eviction documentation में noeviction memory limit पर बढ़ते writes reject करता है, queue correctness guarantee नहीं। Rejected enqueue visible और recoverable obligation रहे। Valkey persistence documentation recovery choices बताता है, tested durability/restore का विकल्प नहीं।
Rebuildable cache के access pattern पर eviction चुनें; LRU के लिए हर key पर TTL अनिवार्य नहीं। Invalidation, tenant/currency/permission scope और bounded cold-miss concurrency ज़रूरी हैं। Sessions, revocation state और queue payloads की loss/expiry policy हो; session eviction केवल logout नहीं है। Critical accepted records और publication intent durable रहें। Transient failure पर backoff, age/attempt limits और ज़िम्मेदार exception path दें।
| Role | क्या स्पष्ट हो |
|---|---|
| Rebuildable cache | Scope, invalidation और bounded cold-start load |
| Session / access state | Expiry, revocation और loss पर safe recovery |
| Queue / accepted obligation | Rejected publication, durability और bounded recovery |
| Semantic index | Freshness, deletion, recall और current source permissions |
Actual product/version देखें: Redis 8 licensing में AGPLv3, RSALv2 और SSPLv1 विकल्प हैं; Valkey history BSD lineage बताता है। हर command, module और managed service interchangeable नहीं। यह compatibility reminder है, licensing advice नहीं।
उसी PostgreSQL instance का दूसरा database भी CPU, memory, I/O और failure boundary साझा करता है। Measured budgets वाला अलग instance/service मज़बूत boundary देता है, साथ में operations/synchronisation खर्च। सबूत पर चुनें, “अलग database से AI checkout कभी धीमा नहीं करेगा” के वादे पर नहीं।
उपयुक्त जगह document embeddings asynchronously बनाएँ, authoritative source, revision/hash और model/dimension metadata रखें। Delayed पुराना job नया revision overwrite न करे। After-commit dispatch record-to-enqueue gap नहीं मिटाता; critical publication को atomic design या recoverable outbox चाहिए। Deletes, revoked access, re-embedding और failures संभालें; incompatible embedding spaces न मिलाएँ।
pgvector documentation exact search को HNSW/IVFFlat approximate indexes से अलग करता है। Actual workload में recall, build memory और query cost test करें। Filtering results घटा सकता है; compatible bounded iterative scans मदद कर सकते हैं, enough results या perfect recall guarantee नहीं।
एक teaching query में कम-से-कम दस eligible documents मानें। Exact filtered top 10 में से आठ documents approximate search के दस eligible results में हों तो Recall@10 =8/10 =80%। यह एक उदाहरण है, measured result नहीं। कई tenant/filter shapes, deletion, empty results और latency test करें। दस results बनाने के लिए authorisation filter कभी न हटाएँ।
Retrieval में entity/object permission और snippets दिखाने या result खोलने से पहले current source access दोबारा जाँचें। Index stock, deletion या permission changes से पीछे हो सकता है। Hidden titles, embeddings, cached results या counts leak न हों। Checkout semantic suggestion से अलग authoritative current price/stock जाँचे।
Replaceable web nodes में images, invoices और exports को durable shared access चाहिए। Object storage एक विकल्प है; सही संचालित shared filesystem दूसरा। Placement latency, residency, recovery और cost से तय हो, हमेशा same region के नियम से नहीं। CDN/public media और protected documents की access policies अलग हैं। Streaming buffering घटा सकती है, लेकिन SDK/transformations buffer कर सकते हैं; actual peaks मापें।
Cold caches, pooler loss, deploy overlap, database failover, blocked writes, rejected enqueue और simultaneous vector rebuild के साथ planned mix test करें। सही order outcomes, privacy और recovery backlog जाँचें। Maintenance/failure capacity रखें। हरा connection graph तभी उपयोगी है जब checkout सही हो और हर delayed obligation का recoverable record रहे।
समीक्षा 5 November 2026 । Anichur Rahaman, StoreConsole के निर्माता। Capacity और recall संख्याएँ teaching examples हैं, installed configuration या measured performance नहीं।
लेखक का परिचय
Anichur Rahaman
पढ़ना जारी रखें
