لماذا تحتاج إلى connection pooling (PgBouncer)؟

Question

Accepted Answer

**Connection pooling** يعيد استخدام مجموعة صغيرة من اتصالات قاعدة البيانات عبر العديد من طلبات العملاء، بدلاً من فتح اتصال جديد لكل طلب. اتصالات PostgreSQL **مكلفة** (كل واحد منها عملية منفصلة تستخدم ذاكرة كبيرة)، لذلك يعتبر pooling ضروريًا للأداء والقابلية للتوسع تحت الحمل. **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.
```

## حيث يحدث pooling

```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).
```

## لماذا يعتبر هذا مهمًا

Connection pooling هو معرفة ضرورية لتشغيل PostgreSQL **على نطاق كبير**، لأن اتصالات PostgreSQL فريدة من حيث كونها مكلفة (كل واحد منها عملية نظام تشغيل منفصلة تستخدم ذاكرة كبيرة)، لذلك فهم السبب وراء الحاجة إلى pooling وكيفية عمله يعتبر معرفة حيوية على مستوى عالي للنشر الفعّال وقابل للتوسع.

المشكلة الأساسية هي أن الطريقة البسيطة — فتح اتصال لكل طلب، أو الاحتفاظ بآلاف الاتصالات مفتوحة من تطبيق مشغول — لا تتسع مع Postgres: الاتصالات مكلفة (الذاكرة لكل عملية، تكلفة الإنشاء)، و Postgres له حد `max_connections` (غالبًا ~100) يتم تجاوزه بسهولة، مما يسبب أخطاء واستنزاف الموارد. **Connection pooling** يحل هذه المشكلة بالحفاظ على مجموعة صغيرة من الاتصالات القابلة لإعادة الاستخدام التي يشاركها العديد من طلبات التطبيق (استعارتها وإرجاعها) — بحيث يمكن خدمة آلاف العملاء بعشرات فقط من اتصالات قاعدة البيانات، مما يلغي تكلفة كل طلب ويبقي ضمن الحدود.

فهم **PgBouncer** (pooler خارجي قياسي) و**pooling modes** الخاصة به — خاصة **transaction pooling** (الاحتفاظ بالاتصال فقط لمدة تنفيذ المعاملة، تعظيم إعادة الاستخدام، الخيار الشائع لتطبيقات الويب) — هو معرفة عملية مهمة.

معرفة **حيث يحدث pooling** (مجموعات على مستوى التطبيق لكل instance، مقابل pooler خارجي مثل PgBouncer لعديد من instances أو serverless) هي نقطة معمارية رئيسية — **serverless خاصة يحتاج إلى pooler خارجي** لأن العديد من instances قصيرة الأجل قد تغمر Postgres بالاتصالات (مشكلة شائعة وحقيقية).

نظرًا لأن إدارة الاتصالات تؤثر بشكل مباشر على القابلية للتوسع والاستقرار تحت الحمل (وطراز process-per-connection الخاص بـ Postgres يجعل هذا حادًا)، وحيث أن pooling (خاصة PgBouncer مع transaction pooling) هو الحل القياسي والضروري، فإن فهم connection pooling — لماذا يحتاج Postgres إليه، وكيفية عمله، و PgBouncer و modes الخاصة به، والاعتبار الخاص بـ serverless — هو معرفة حيوية على مستوى عالي لتشغيل PostgreSQL على نطاق كبير، وهو موضوع حرج بشكل متكرر لأنظمة الإنتاج يميز بين من يستطيع توسيع Postgres ومن يصطدم بأخطاء حد الاتصالات.