تُعد هذه القصة التي ترويها OpenAI حول استخدام PostgreSQL بمثابة “درس مستفاد” لكل مهندسي البيانات في العالم؛ فهي تثبت أن الأنظمة التقليدية (Relational DBs) لا تزال قادرة على مناطحة أحمال العمل الأسطورية إذا ما توفرت لها الهندسة الدقيقة.
1. المعمارية الهيكلية: كيف صمد خادم واحد؟
اعتمدت OpenAI على نموذج “الخادم الأساسي الوحيد” للكتابة، مع التوسع الأفقي الضخم للقراءة:
المحرك الأساسي: خادم واحد من نوع Azure PostgreSQL Flexible Server.
جيش النسخ: نحو 50 نسخة قراءة (Read Replicas) موزعة عالمياً.
النسخ المتسلسل (Cascading Replication): لمواجهة عبء بث سجلات من الخادم الأساسي إلى 50 نسخة، يتم الآن اختبار نسخ وسيطة تنقل البيانات للنسخ التي تليها، مما يسمح بالتوسع لأكثر من 100 نسخة دون إنهاك المركز.
2. التغلب على “عقدة” الكتابة و MVCC
أكبر تحدٍ واجهوه هو آلية MVCC (التحكم في التزامن متعدد النسخ) في PostgreSQL، والتي تؤدي لتضخم البيانات () عند الكتابة المكثفة.
الحل: ترحيل الأحمال كثيفة الكتابة والقابلة للتجزئة () إلى أنظمة مثل Azure Cosmos DB.
السياسة الصارمة: منع إضافة جداول جديدة إلى PostgreSQL، وجعل الأنظمة المجزأة هي الخيار الافتراضي للمشاريع الجديدة.
3. ترسانة التحسينات البرمجية (Optimization Stack)
4. إدارة التخزين المؤقت (The Thundering Herd)
عندما تفشل الذاكرة المؤقتة ( )، تندفع ملايين الطلبات للقاعدة دفعة واحدة.
الابتكار: تطبيق آلية “قفل التخزين المؤقت” (Cache Leases)؛ حيث يقوم طلب واحد فقط بجلب البيانات من PostgreSQL وتحديث الكاش، بينما تنتظر بقية الطلبات، مما يمنع انهيار القاعدة تحت ضغط مفاجئ.
5. دروس من “الحادثة التقنية الوحيدة”
خلال إطلاق ChatGPT ImageGen، تضاعفت أحمال الكتابة 10 مرات في أسبوع واحد.
الدرس: ضرورة تحسين طبقة الـ ORM لدعم “تحديد المعدل” ( ) وحظر أنماط الاستعلامات غير الفعالة برمجياً قبل وصولها للقاعدة.
