الذكاء الاصطناعي
#PostgreSQL
#OpenAI
سر توسع ChatGPT: قاعدة بيانات PostgreSQL واحدة فقط
بينما تتجه العديد من المؤسسات نحو قواعد البيانات المتجهة (Vector Databases) المعقدة، تثبت OpenAI أن الحلول التقليدية قد تكون الأكثر فعالية عند استخدامها بذكاء. في مفاجأة تقنية، كشفت الشركة المطورة لـ ChatGPT عن اعتمادها الأساسي على قاعدة بيانات PostgreSQL مفتوحة المصدر لإدارة عملياتها الضخمة.
كما يتضح من الصورة المرفقة التي تم إنشاؤها لتوضيح المفهوم (OpenAI ChatGPT using PostgreSQL)، تدير OpenAI منصة ChatGPT وواجهة برمجة التطبيقات (API) الخاصة بها لخدمة 800 مليون مستخدم بالاعتماد على مثيل رئيسي واحد (Single-Primary) من PostgreSQL، وليس قاعدة بيانات موزعة أو عنقودية.
هندسة البنية التحتية العملاقة
تستخدم الشركة خادماً واحداً مرناً من نوع Azure PostgreSQL Flexible Server لمعالجة جميع عمليات الكتابة، بينما تتوزع حوالي 50 نسخة للقراءة (Read Replicas) عبر مناطق متعددة للتعامل مع عمليات القراءة. يعالج هذا النظام ملايين الاستعلامات في الثانية مع الحفاظ على زمن استجابة منخفض للغاية (من خانتين بالمللي ثانية) وتوافر بنسبة 99.999%.
وفي تصريح تقني، قال بوهان تشانغ، مهندس في OpenAI: "لسنوات، كانت PostgreSQL واحدة من أهم أنظمة البيانات التي تعمل خلف الكواليس لتشغيل المنتجات الأساسية مثل ChatGPT. خلال العام الماضي، نما حمل PostgreSQL لدينا بأكثر من 10 أضعاف، وما زال يرتفع بسرعة".
استراتيجية التحسين بدلاً من إعادة الهيكلة
بدلاً من الانجراف وراء "ذعر التوسع" واختيار بنى تحتية معقدة، ركزت OpenAI على تحسينات مستهدفة وعميقة:
- تجميع الاتصالات (Connection Pooling): نجحت التقنية في تقليل وقت الاتصال من 50 مللي ثانية إلى 5 مللي ثانية فقط.
- قفل ذاكرة التخزين المؤقت (Cache Locking): لمنع مشكلة "القطيع الهادر" (Thundering Herd)، حيث تؤدي عمليات فقدان الكاش إلى إغراق قاعدة البيانات بالطلبات.
التحديات والحلول الهجينة
رغم كفاءتها، تفرض PostgreSQL تحديات تتعلق بالتحكم في التزامن متعدد الإصدارات (MVCC) تحت أحمال الكتابة الثقيلة. ولمواجهة ذلك، لم تلجأ OpenAI إلى تقسيم قاعدة البيانات (Sharding) الذي يضيف تعقيداً كبيراً في الكود وإدارة المعاملات، بل اعتمدت استراتيجية هجينة:
- لا يتم إنشاء جداول جديدة في PostgreSQL.
- أعباء العمل الجديدة تذهب افتراضياً إلى أنظمة مثل Azure Cosmos DB.
- يتم ترحيل أعباء العمل الحالية كثيفة الكتابة إلى خارج PostgreSQL.
- يتم الاحتفاظ بباقي العمليات داخل PostgreSQL مع تحسينات صارمة.
دروس للمطورين والشركات
كشفت تجربة OpenAI عن ممارسات حيوية لأي فريق تقني:
1. مراقبة استعلامات ORM
أطر العمل مثل Django وSQLAlchemy وHibernate تسهل البرمجة، لكنها قد تكون كارثية في الأداء. اكتشفت OpenAI استعلاماً مولداً تلقائياً يربط 12 جدولاً (Join)، مما تسبب في حوادث خطيرة عند ارتفاع حركة المرور. المراجعة الدقيقة لهذه الاستعلامات أمر إلزامي.
2. الانضباط التشغيلي الصارم
تفرض الشركة قيوداً صارمة، حيث يُسمح فقط بتغييرات المخطط (Schema) الخفيفة مع مهلة زمنية لا تتجاوز 5 ثوانٍ. كما يتم إنهاء الاستعلامات طويلة الأمد تلقائياً لمنع تعطيل عمليات الصيانة، وتتم عمليات ملء البيانات الخلفية (Backfilling) ببطء شديد قد يستغرق أسبوعاً لضمان عدم التأثير على الأداء.
تثبت هذه التجربة أن إعادة الهيكلة الشاملة ليست دائماً الحل لتحديات التوسع، بل يكمن السر في تحديد الاختناقات الفعلية وتحسين البنية التحتية المثبتة.
الأسئلة الشائعة
تدعم البنية التحتية لـ OpenAI حوالي 800 مليون مستخدم لمنصة ChatGPT وواجهة برمجة التطبيقات الخاصة بها.
تجنبت OpenAI التعقيد الناتج عن قواعد البيانات الموزعة أو المقسمة (Sharding)، وفضلت تحسين مثيل PostgreSQL رئيسي واحد مع استخدام استراتيجية هجينة لترحيل الأحمال الثقيلة.
ركزت الشركة على تجميع الاتصالات (Connection Pooling) لتقليل زمن الاتصال، واستخدام قفل ذاكرة التخزين المؤقت لمنع التحميل الزائد على قاعدة البيانات.
التعليقات 0
سجل دخولك لإضافة تعليق
لا توجد تعليقات بعد. كن أول من يعلق!