مطوّر يبني Terox بمساعدة الذكاء الاصطناعي خلال يومين لاستعلام 128 شظية PostgreSQL دفعة واحدة

إذا كانت لديك مئة شظية PostgreSQL، فإن سؤالًا بسيطًا مثل «في أيّ منها يوجد السجل؟» يتحوّل إلى رحلة شاقة: العثور على المضيف، وتذكّر المنفذ وقاعدة البيانات، وفتح psql، وتنفيذ الاستعلام، ثم الانتقال إلى الشظية التالية. سئم مطوّر خلفيات، سبق له العمل مديرًا لقواعد البيانات، تحمّل هذا الوضع. فاستعان بالذكاء الاصطناعي وبنى خلال يومين Terox، وهي أداة تفاعلية لسطر الأوامر مخصّصة للعناقيد الموزّعة على شظايا.

ما المشكلة التي تحلّها؟

في psql وpgAdmin، وحدة العمل هي الاتصال. أما في النظام الموزّع على شظايا، فوحدة العمل هي مجموعة الاتصالات بأكملها. تصلح حلقة bash تستدعي psql لمهمة عابرة، لكنها تتداعى بوصفها أداة يومية: لا حدّ للتوازي، ولا إلغاء للاستعلامات، ولا حفظ لأخطاء كل شظية على حدة، ولا حماية من الوصول إلى بيئة الإنتاج عن طريق الخطأ.

يقدّم Terox كيانات على مستوى أعلى: خدمة → مخزن → شظية واحدة أو عدة شظايا أو جميع الشظايا. وتُعرّف المضيفات وقواعد البيانات باستخدام قوالب؛ فمثلًا يُوسّع pgbouncer-shop-rs{p1:03}.example.net إلى 128 عنوانًا. ويُنفّذ الاستعلام الذي يستهدف all على جميع الشظايا، ثم تُدمج النتائج في جدول واحد يتضمن عمود shard، فيما تُعرض الأخطاء منفصلة.

كيف يعمل؟ مثال عملي

يمرّ الأمر \find items item_id = 424242 على الشظايا، ويبيّن أن السجل موجود في shard_37، ثم ينقل سياق العمل إليها تلقائيًا. لا حاجة إلى نسخ اسم المضيف أو التخمين.

التنفيذ الداخلي مدروس. يمنع المعامل fanout_concurrency العميل من إرسال الطلبات إلى الشظايا الـ128 كلها في اللحظة نفسها. ويُنشأ مجمّع اتصالات كل شظية عند الحاجة، ولكل شظية مهلة نهائية مستقلة، ويلغي Ctrl+C الاستعلامات الجارية. وتتم القراءة داخل معاملة PostgreSQL فعلية من نوع READ ONLY، بدلًا من الاعتماد على تحليل نص SQL. ويجب تفعيل الكتابة صراحةً باستخدام \write on، وتُعطّل مجددًا عند تغيير السياق.

وتوجد أيضًا أوامر تشخيص مستقلة (\activity، \blockers، \longtx، \sizes، \diff، \doctor)، إلى جانب أداة فحص ترصد DELETE بلا WHERE أو NOT IN مع قيم يمكن أن تكون NULL.

ترحيلات للحالات الاستثنائية

يشدّد المطوّر على أن الترحيلات المعتادة تُنفّذ مع النشر. أما Terox فمخصّص للاستثناءات في الجداول الكبيرة التي تتعرّض لأحمال مرتفعة. ومن دون الخيار --allowed، يعمل الأمر \migrate بوضع التشغيل التجريبي. وتتوفر آلية طرح كناري، وتنفيذ على دفعات، وخيار --resume، فيما يمنع المجموع الاختباري مواصلة الطرح بملف جرى تعديله.

لا توجد معاملة موحّدة تشمل الخوادم الـ128، لذا قد تكون بعض الشظايا قد ثبّتت التغييرات بالفعل. ويُظهر التقرير بوضوح التطبيق الجزئي، ويجب أن تكون الترحيلات قابلة لإعادة التنفيذ من دون تغيير النتيجة. وبالنسبة إلى CREATE INDEX CONCURRENTLY وVACUUM، اللذين لا يمكن وضعهما داخل معاملة مع SET LOCAL، يحذّر Terox من التنفيذ غير المحمي ويطلب تأكيدًا منفصلًا في بيئة الإنتاج.

ماذا تكشف التجربة عن البرمجة بالتوجيه للذكاء الاصطناعي؟

كانت دورة العمل كالتالي: وصف المشكلة، وتحديد أبسط نموذج للسلوك، والحصول على تنفيذ من الذكاء الاصطناعي، والتحقق منه يدويًا وبالاختبارات، ثم تحويل كل حالة حدّية إلى اختبار جديد. هكذا أُضيف إغلاق مجمّعات الاتصالات عند الخروج، وسجلّ أوامر خالٍ من كلمات المرور، واختبارات لحالات التسابق.

الخلاصة الأهم لدى المطوّر: ينفّذ الذكاء الاصطناعي الفكرة الخاطئة بالسرعة والإتقان نفسيهما، بل يوزّعها على اثني عشر ملفًا دفعة واحدة. لذلك يجب تحديد الثوابت أولًا: ألا تبقى اتصالات مفتوحة بعد الخروج، وأن يفرض PostgreSQL وضع القراءة فقط، وأن يعطّل تغيير السياق الكتابة، وألا يبدو الإخفاق الجزئي نجاحًا. عندها يصبح الحوار مع الذكاء الاصطناعي عملًا هندسيًا.

القيود

يعتمد التحليل الساكن في Terox على قواعد استدلالية. وتظل حدود الأمان محكومة بصلاحيات الأدوار، ومعاملات READ ONLY، وTLS، والمهل الزمنية. ولا تغني الأداة عن المراقبة والنسخ الاحتياطية وفهم خطط تنفيذ الاستعلامات، ولا تصلح بنية توزيع البيانات على الشظايا.

الدرس العملي: إذا كنت تتنقّل بانتظام بين عشرات قواعد البيانات، فحوّل حلقة التكرار التي تستخدمها إلى أداة تتذكّر القواعد نيابةً عنك. وعند العمل مع الذكاء الاصطناعي، ابدأ بالثوابت قبل الشيفرة.