آپ کو کنکشن پولنگ (PgBouncer) کی ضرورت کیوں ہے؟

Question

Accepted Answer

**کنکشن پولنگ** بہت سے کلائنٹ درخواستوں میں ڈیٹابیس کنکشنز کے ایک چھوٹے سیٹ کو دوبارہ استعمال کرتی ہے، بجائے اس کے کہ ہر درخواست کے لیے ایک نیا کنکشن کھولا جائے۔ PostgreSQL کنکشنز **مہنگے** ہیں (ہر ایک الگ عمل ہے جو نمایاں میموری استعمال کرتا ہے)، لہذا پولنگ کارکردگی اور بوجھ کے تحت توسیع پذیری کے لیے ضروری ہے۔ **PgBouncer** معیاری pooler ہے۔

## مسئلہ: PostgreSQL کنکشنز مہنگے ہیں

```text
Each PostgreSQL connection = a separate OS PROCESS, using ~5-10MB of memory.
  ✗ Opening a connection has overhead (process creation, auth, setup)
  ✗ Many connections (e.g. 1000s from a busy app) → huge memory use, contention
  ✗ Postgres has a max_connections limit (often ~100); exceeding it = errors
→ Opening/closing a connection per request, or holding thousands open, doesn't scale.
```

## حل: ایک کنکشن پول

```text
A POOL maintains a small set of REUSABLE connections to Postgres.
Application requests BORROW a connection from the pool, use it, and RETURN it.
  ✓ Connections are reused (no per-request open/close overhead)
  ✓ Many app requests share a few DB connections (e.g. 10000 clients → 20 connections)
  ✓ Stays within max_connections, controls resource use → scales
```

## PgBouncer — معیاری بیرونی pooler

```text
PgBouncer sits BETWEEN the application and PostgreSQL — lightweight, efficient.
Pooling modes:
  Session   → a connection is assigned for the client's whole session
  Transaction → a connection is held only for the duration of a TRANSACTION (most
               efficient — connections returned between transactions; common choice)
  Statement → per-statement (most aggressive; limited)
→ Transaction pooling maximizes connection reuse for typical web apps.
```

## پولنگ کہاں واقع ہے

```text
Application-level → many ORM/driver libraries have built-in pools (per app instance)
External pooler (PgBouncer) → a shared pool in front of Postgres (best for many app
  instances / serverless, where per-instance pools would still overwhelm the DB)
→ Serverless especially needs an external pooler (many short-lived instances).
```

## یہ کیوں اہم ہے

کنکشن پولنگ PostgreSQL کو **بڑے پیمانے پر** چلانے کے لیے ضروری علم ہے، کیونکہ PostgreSQL کنکشنز منفرد طور پر مہنگے ہیں (ہر ایک الگ OS عمل ہے جو نمایاں میموری استعمال کرتا ہے)، لہذا یہ سمجھنا کہ پولنگ کی ضرورت کیوں ہے اور یہ کیسے کام کرتی ہے، عملی درجے کے لیے اہم علم ہے کارکردہ اور توسیع پذیر ڈیپلوائے کرنے کے لیے۔

بنیادی مسئلہ یہ ہے کہ سادہ طریقہ — ہر درخواست کے لیے کنکشن کھولنا، یا ایک مصروف ایپلیکیشن سے ہزاروں کنکشنز کھول کر رکھنا — Postgres کے ساتھ توسیع نہیں پاتا: کنکشنز مہنگے ہیں (فی عمل میموری، بنانے کی سربوہی)، اور Postgres کے پاس `max_connections` حد ہے (اکثر ~100) جو آسانی سے تجاوز ہو جاتی ہے، جس سے خرابیاں اور وسائل کی کمی واقع ہوتی ہے۔ **کنکشن پولنگ** اس کو حل کرتی ہے دوبارہ استعمال کنے کے قابل کنکشنز کا ایک چھوٹا سیٹ برقرار رکھ کر جو بہت سی ایپلیکیشن درخواستیں شیئر کرتی ہیں (انہیں لے کر اور واپس کر کے) — تو ہزاروں کلائنٹس کی خدمت کچھ درجن ڈیٹابیس کنکشنز سے کی جا سکتی ہے، ہر درخواست کی سربوہی کو ختم کر کے اور حدود کے اندر رہ کر۔

**PgBouncer** کو سمجھنا (معیاری بیرونی pooler) اور اس کے **پولنگ موڈز** — خاص طور پر **transaction pooling** (لین دین کی مدت کے لیے صرف کنکشن رکھنا، دوبارہ استعمال کو زیادہ سے زیادہ کرنا، ویب ایپس کے لیے عام انتخاب) — اہم عملی علم ہے۔

**پولنگ کہاں واقع ہے** (فی مثال ایپلیکیشن سطح کے پول، بمقابلہ بہت سی مثالوں کے لیے بیرونی pooler جیسے PgBouncer یا serverless) معلوم کرنا ایک اہم معماری نکتہ ہے — **خاص طور پر serverless کو بیرونی pooler کی ضرورت ہے** کیونکہ بہت سی مختصر المیعاد مثالیں ورنہ Postgres کو کنکشنز سے مغلوب کر دیں گی (ایک عام، حقیقی مسئلہ)۔

چونکہ کنکشن انتظام براہ راست توسیع پذیری اور بوجھ کے تحت استحکام کو متاثر کرتا ہے (اور Postgres کا عمل فی کنکشن ماڈل یہ شدید بناتا ہے)، اور چونکہ پولنگ (خاص طور پر PgBouncer transaction pooling کے ساتھ) معیاری، ضروری حل ہے، کنکشن پولنگ کو سمجھنا — Postgres کو اس کی ضرورت کیوں ہے، یہ کیسے کام کرتا ہے، PgBouncer اور اس کے موڈز، اور serverless کے خیال — PostgreSQL کو بڑے پیمانے پر چلانے کے لیے اہم عملی درجے کا علم ہے، یہ پروڈکشن سسٹمز کے لیے اکثر نقطہ فیصل ہے جو ان لوگوں میں فرق پیدا کرتا ہے جو Postgres کو توسیع دے سکتے ہیں ان سے جو کنکشن حد کی ناکامیوں سے ٹکراتے ہیں۔