تتميز المنصات بدون خادم بقدرتها العالية على إنشاء التوازي بسرعة. PostgreSQL غير مصممة للتعامل مع آلاف من العملاء قصيري الأمد الذين يفتحون اتصالات مباشرة في نفس الوقت. هذه الفجوة تعتبر واحدة من أكثر طرق الفشل شيوعًا في حزم التطبيقات الحديثة: تتوسع طبقة التطبيق، وتقضي قاعدة البيانات وقتها في إدارة تذبذب الاتصالات.
لهذا السبب، فإن PgBouncer مهم.
لماذا يساعد PgBouncer
يقع PgBouncer بين تطبيقك وPostgres ويعيد استخدام عدد أقل من الاتصالات الحقيقية بقاعدة البيانات عبر عدد أكبر من عملاء التطبيق. في الممارسة العملية، عادةً ما يحسن ذلك:
- استقرار الاتصال تحت أوقات الذروة
- الضغط على الذاكرة في قاعدة البيانات
- القدرة على التحمل أثناء عمليات النشر وذروات الحركة
يبدو إعداد شائع بهذا الشكل:
[databases]
app = host=postgres.internal port=5432 dbname=appdb
[pgbouncer]
pool_mode = transaction
default_pool_size = 50
max_client_conn = 1000
النقطة ليست السماح لـ 1,000 طلب بتشغيل 1,000 جلسة حقيقية في Postgres. النقطة هي تسهيل طبقة الحوسبة إلى شيء يمكن أن تتحمله قاعدة البيانات.
المقايضة المهمة
يقوم PgBouncer بتغيير دلالات الاتصال، خاصة في وضع التجميع transaction. الميزات التي تفترض حالة الجلسة يمكن أن تتعطل أو تتصرف بشكل مختلف:
- عبارات التجهيز على مستوى الجلسة
- الجداول المؤقتة عبر المعاملات
- حالة
SET التي تفترض ثبات الاتصال
هذا يعني أنك بحاجة إلى اختيار وضع التجميع بدقة والتحقق من افتراضات ORM أو طبقة الاستعلام الخاصة بك.
قاعدة تشغيل أفضل
إذا كانت طبقة الحوسبة غير مستقرة، يعتبر إدارة الاتصالات هندسة، وليس مجرد تفصيل دقيق على مستوى منخفض. غالبًا ما يكون الجمع بين الحوسبة بدون خادم والاتصالات المباشرة مع Postgres جيدًا في التطوير ومؤلمًا في الإنتاج. تم تصميم PgBouncer لاستيعاب هذه الفجوة قبل أن تصبح قاعدة البيانات عنق الزجاجة.
القراءة الإضافية