Postgres ليس بطيئًا. المشكلة في التخزين: ملخص حديث POSETTE 2026

إعداد الاختبار المرجعي

في POSETTE 2026، قدم Sai Srirampur عرضًا بعنوان "Postgres Isn't Slow. Your Storage Is"، ناقش فيه كيفية تأثير أداء التخزين على PostgreSQL عند التوسع. حدد العرض خمسة أعراض شائعة: بطء الإدخال، زمن انتقال غير متسق للقراءة، تأخر autovacuum، بطء checkpoints، وتأخر النسخ المتماثل المنطقي. تشترك هذه المشاكل غالبًا في نفس الجذر وهو أداء التخزين عندما تتجاوز مجموعات البيانات الذاكرة المتاحة.

لعزل التخزين كمتغير، استخدم المعيار ثمانية مجموعات PostgreSQL متطابقة: أربعة على instance-store NVMe وأربعة على gp3 EBS الأساسي بـ 3000 IOPS. عملت كل مجموعة على مثيل m6id.4xlarge بـ 16 vCPU و 64 GiB RAM و 16 GiB shared_buffers. استخدم عبء العمل كومة pgbench_accounts بحجم 482 GiB التي تحتوي على 3.3 مليار صف، ونفذ عبء random-UPDATE عالي التزامن لمدة خمس دقائق مع 64 عميل و 16 worker thread.

ماذا أظهرت النتائج

أظهر المعيار لمجموعات NVMe وسطي 16030 TPS، بينما على EBS كان 1734 TPS، أي فرق 9.24 مرة. انخفض زمن انتقال وسطي للمعاملات من 36.9 ms إلى 4.0 ms. بالنسبة للعمليات التقنية، أكمل NVMe عملية VACUUM على bloat بحجم 10 GB في 366 ثانية، بينما على EBS استغرق 964 ثانية، كما أكمل 10 GB من النسخ المتماثل المنطقي المتأخر في 139 ثانية بدلاً من 238.

أظهر تحليل زمن الانتقال أن قراءة الصفحات على EBS استغرقت حوالي 19 ms، بينما على NVMe 0.3 ms، وأضاف WAL fsync 11 ms بدلاً من 1.5 ms، بينما ساهمت تكلفة lock و scheduler بـ 5 ms بدلاً من 0.2 ms. كان وقت CPU متشابهًا تقريبًا في الحالتين، حوالي 2 ms. ألقت لقطة pg_stat_activity الضوء على أن 29 من أصل 64 backend على EBS كانت تنتظر IO:DataFileRead، بينما على NVMe كانت تسعة فقط. في نافذة تحليل مدتها 240 ثانية، جمع مضيف NVMe 2253 CPU-ثانية، بينما جمع مضيف EBS 251 فقط، مما يشير إلى أن عمليات EBS قضت وقتًا أطول بكثير خارج CPU، في انتظار التخزين.

Postgres في الإنتاج المعتمد على NVMe

تلبي بنية الإنتاج المعروضة في العرض قيود مرونة instance-store NVMe بثلاثة متطلبات: نسخ قاعدة البيانات متماثلًا حتى يتمكن الخدمة من تحمل فقدان عقدة، تخزين النسخ الاحتياطية وبيانات الاستعادة على أجهزة منفصلة، والتخطيط للطاقة استنادًا إلى NVMe المتاح لكل نوع instance.

النمط الأول هو نسخ متماثل متزامن يعتمد على quorum مع مرشحين standby، تكوين مثل ANY 1 (standby1, standby2)، مما يسمح للمعاملة بالالتزام بعد أن يؤكد أي standby WAL. من أجل المرونة خارج عقد قاعدة البيانات، يمكن لأدوات مفتوحة المصدر مثل WAL-G إجراء physical base backups وأرشفة WAL مستمرة، مع RPO مستهدف بالثواني. يذكر العرض أمثلة علنية من Instacart و Datadog تصف تشغيل PostgreSQL على NVMe محلي للأعباء الحساسة للتأخير (latency-sensitive).

المصادر: clickhouse.com