كيف تحسّن أداء PostgreSQL في تطبيقات SaaS متعددة المستأجرين

مشاكل أداء استعلامات PostgreSQL في منتجات SaaS متعددة المستأجرين تتبع أنماطاً متوقعة. نفس المشاكل الخمس تظهر عند التوسع في معظم المنتجات: الفهارس المركبة المفقودة، وإدارة الاتصالات الضعيفة، والمسح التسلسلي على الجداول الكبيرة، وسلاسل استعلامات N+1، والاستعلامات البطيئة غير المراقبة. إليك كيفية تشخيص وإصلاح كل منها في بيئة إنتاج.

لماذا تظهر مشاكل أداء PostgreSQL في وقت لاحق من دورة حياة SaaS؟

منتج SaaS عند 10 مستأجرين مع 1,000 صف لكل جدول لا يعاني من مشاكل أداء قاعدة بيانات محسوسة. عند 100 مستأجر مع 100,000 صف، تبدأ الاستعلامات البطيئة تظهر في السجلات. عند 1,000 مستأجر، بعض الاستعلامات التي كانت ممتازة في التطوير تصبح انقطاعات إنتاجية.

السبب هو أن خطط الاستعلام تتغير مع نمو أحجام الجداول. مُحطط استعلامات PostgreSQL يتخذ قراراته بناءً على إحصاءات الجداول. مسح تسلسلي يكلف 2 ميلي ثانية على جدول بـ 10,000 صف يكلف 200 ميلي ثانية على جدول بـ 1,000,000 صف.

مشكلة الفهارس المركبة

في قاعدة بيانات SaaS متعددة المستأجرين، كل استعلام ذي معنى تقريباً يفلتر على tenant_id بالإضافة إلى عمود أو عمودين إضافيين.

استعلام مثل:

SELECT * FROM orders
WHERE tenant_id = $1 AND status = 'pending'
ORDER BY created_at DESC;

هذا الاستعلام يحتاج فهرساً مركباً على (tenant_id, status, created_at). فهرس على tenant_id وحده غير كافٍ. الفهرس المركب يجب أن يبدأ بالعمود الأكثر انتقائية الذي يظهر في شرط المساواة.

شغّل EXPLAIN (ANALYZE, BUFFERS) على استعلاماتك الأبطأ لرؤية خطة التنفيذ الفعلية. أي خطة تُظهر Seq Scan على جدول كبير هي مرشح للفهرسة.

استنزاف الاتصالات وإعداد PgBouncer

PostgreSQL يخصص ذاكرة لكل اتصال. نسخة PostgreSQL بـ max_connections = 100 تبدأ رفض الاتصالات الجديدة عند استخدام 100 اتصال، بغض النظر عما إذا كانت تلك الاتصالات تعمل فعلياً.

PgBouncer في وضع تجميع المعاملات هو الحل المعياري. يحافظ على مجموعة صغيرة من اتصالات PostgreSQL الفعلية ويُعدد العديد من اتصالات التطبيق عبرها.

راقب طابور انتظار PgBouncer. إذا كانت التطبيقات تنتظر الاتصالات، إما زيادة pool_size أو تقليل مدة الاستعلام حتى تعود الاتصالات للمجموعة بشكل أسرع.

تحديد الاستعلامات البطيئة بـ pg_stat_statements

pg_stat_statements هو امتداد PostgreSQL يتتبع إحصاءات التنفيذ لكل استعلام مختلف. إنه أول أداة يجب تمكينها على أي قاعدة بيانات SaaS إنتاجية.

للعثور على الاستعلامات الأعلى تكلفة بإجمالي وقت التنفيذ:

SELECT query, calls, mean_exec_time, total_exec_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

الاستعلام ذو mean_exec_time العالي مع calls العالي هو المزيج الخطر.

سلاسل استعلامات N+1 في طبقات الاستعلامات

سلاسل N+1 تحدث عندما يُعيد استعلام N صفاً ثم يقوم التطبيق بإجراء استعلام إضافي واحد لكل صف لجلب البيانات المرتبطة. النتيجة هي N+1 رحلة ذهاباً وإياباً لقاعدة البيانات لما يجب أن يكون استعلاماً واحداً مع JOIN.

في سجلات pg_stat_statements، تظهر سلسلة N+1 كاستعلام واحد بعدد calls مرتفع جداً مقارنة بالاستعلام الذي يستدعيه.

VACUUM والتضخم في الجداول

PostgreSQL يستخدم تحكم التزامن متعدد الإصدارات (MVCC). عند تحديث أو حذف صف، لا تُزال النسخة القديمة فوراً. نسخ الصفوف الميتة تتراكم في الجدول ويجب تنظيفها بواسطة VACUUM.

راقب تضخم الجداول وتأكد من ضبط إعدادات AUTOVACUUM للجداول ذات معدلات التحديث العالية مثل الطلبات والجلسات وسجلات الأحداث.

دروس من الإنتاج

مكّن pg_stat_statements من اليوم الأول. انتظار ظهور مشاكل الأداء يعني التشخيص بدون رؤية.

الفهارس المركبة على (tenant_id, عمود_الفلتر, عمود_الترتيب) ضرورية في الجداول متعددة المستأجرين. PgBouncer في وضع المعاملات ليس اختيارياً عند التوسع.