بلغ P99 في MySQL 48 ثانية في جلسات الذكاء الاصطناعي. PolarDB-X خفّضته إلى 1.5

غيّرت المساعدات الذكية شكل صف قاعدة البيانات. جلسة وكيل البرمجة تحزم محادثات متعددة اللفات، ومقتطفات أكواد، ونتائج استدعاءات الأدوات في مئات من اللفات المتراكبة؛ وعلى chatbot أن يتذكر السياق على مدى أيام. رسالة واحدة تنمو اليوم من كيلوبايت إلى ميغابايت، وحجم الجلسات من ملايين إلى مئات الملايين. يصف فريق PolarDB-X في Alibaba Cloud هذا بأنه مشكلة التخزين التي ما زالت MySQL بلا إجابة معيارية لها.

يستحضر المنشور نافذة سياق عصر GPT-3 التي بلغت 4K توكن، ونافذة GPT-4 التي بلغت 128K، وClaude Opus 4 عند مليون توكن. لقطة الجلسة تبلغ بضعة ميغابايت هذا العام، كما يكتب الفريق، وربما عشرة ميغابايت في العام المقبل.

كانت MySQL النظام البيئي الوحيد بلا مسار معياري

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

المساران السائدان في MySQL يستبدلان مشكلة بأخرى. تخزين المحتوى في عمود InnoDB LONGTEXT بسيط وذو طابع معاملاتي، لكن العمود الكبير يتقاسم مسار البيانات مع الحقول العادية: ينتفخ سجل binlog، وتتعرض النسخ المتماثلة لضغط، ويُضغط تجمع المخازن المؤقتة (buffer pool) مع نمو النطاق. الاحتفاظ بالبيانات الوصفية فقط في MySQL وبالحمولات على OSS يخفض التكلفة لكنه يدفع تناسق المعاملات وإدارة دورة الحياة وعمليات النظامين إلى طبقة التطبيق.

إجابة PolarDB-X هي كلمة مفتاحية. إضافة EXTERNALIZE إلى عمود LONGTEXT تترك INSERT وSELECT وDELETE دون تغيير، ويؤكد المنشور أن أدوات ORM مثل MyBatis وJPA، بالإضافة إلى أطر العمل مثل LangChain وLlamaIndex، لا تحتاج إلى أي تكييف. يقوم المحرك بالتوجيه حسب حجم العمود في طبقة الحوسبة. الأعمدة التي تبلغ حوالي 100 كيلوبايت تذهب مباشرة إلى OSS، ولا يدخل سجل binlog سوى عنوان blob، فتختفي انقسامات صفحات LOB واختناقات النسخ المتماثل؛ وكتابة OSS الفاشلة ما زالت تُتراجع، ويقوم تجميع القمامة (GC) في الخلفية بتنظيف البيانات اليتيمة. الأعمدة التي تبلغ حوالي 1 كيلوبايت تهبط إلى جدول مرحلي محلي في InnoDB، فيكون زمن كتابتها مطابقًا للإدراج العادي، وتنقلها عملية تفريغ خلفية إلى OSS على دفعات. الحذف ينتقل أيضًا إلى المحرك: يتبع GC آلية التطهير في InnoDB ومنظر الحد الأدنى العام للمعاملات النشطة، ليحل محل نصوص المصالحة المكتوبة يدويًا.

فجوة المعايير: من 48.7 ثانية إلى 1.5

بقياسها ضمن مخططات مطابقة عند 256 عميلًا متزامنًا، تبدو الكتابات على هذا النحو:

عند 2 ميغابايت، يصل زمن الاستجابة الخلفي P99 في InnoDB إلى 48.7 ثانية بينما تبقى الأعمدة الخارجية عند 1.5 ثانية. خلاصة المنشور: عمود بحجم 1 كيلوبايت يُكتب بالسرعة نفسها التي يكتب بها InnoDB مباشرةً، وعمود بحجم 100 كيلوبايت يجعله يتخلف عنه بمرتبة من الحجم تحت التزامن العالي، لذا ينبغي أن تكون الأعمدة الخارجية هي الافتراضي.

هذه أرقام قاسها البائع، وهذا تحفظ جدير بالاعتبار، والمدونة نفسها تذكر حدّين صريحين. القراءات الباردة تدفع ثمنًا إضافيًا: فعدم إصابة ذاكرة التخزين المؤقت (cache miss) يعني جلبًا من OSS خلال أكثر من 20 مللي ثانية. لا يمكن فهرسة الأعمدة الخارجية، فلا فهارس ثانوية ولا مسح نطاقي ولا استعلامات LIKE. هذا يناسب المحتوى الذي يُجلب كاملًا بالمفتاح الأساسي، بينما تبقى الحقول القابلة للبحث مثل session_id مفهرسة. فهرسة النص الكامل للأعمدة النصية الخارجية موجودة على خارطة الطريق، وفق المنشور.

مصمم لنمط القراءة بعد الكتابة

تغلب على جلسات الذكاء الاصطناعي قراءات تأتي فور الكتابات، عندما يعيد التطبيق تجميع السياق للفة التالية. تخدم ذاكرة التخزين المؤقت رباعية المستويات هذا النمط: الذاكرة المحلية، وSSD المحلي، وذاكرة تخزين عقدة أخرى عبر RPC، وOSS بوصفه الملاذ الأخير. تُوصف القراءات الساخنة بأنها لا يمكن تمييزها عن استعلام عمود عادي. بل يمكن لرد مساعد واحد أن ينقسم إلى أعمدة خارجية منفصلة للمحتوى والمرفقات وtool_calls والاستدلال، ولكل منها مدخل ذاكرة تخزين خاص به، فسلسلة التفكير التي تُصدرها نماذج مثل DeepSeek-R1 أو Qwen QwQ بالكامل تعيش على OSS شبه دائمًا.

قواعد المعرفة في RAG وسجلات التدقيق وملفات الوسائط تناسب النمط نفسه. دفعت Alibaba Cloud في هذا الاتجاه من قبل: وثّق مهندسوها سابقًا وصول pgvector إلى نطاق مليار متجه على PolarDB لـ PostgreSQL مع استجابات بالمللي ثانية.

يبقى التحقق المستقل هو السؤال المفتوح. وفجوة نظام MySQL البيئي كانت حقيقية بما يكفي لدرجة أن الفرق بنت منطق تعويض خاصًا بها لسنوات. ما تقدمه PolarDB-X هو كلمة مفتاحية تجعل المحرك يتولى التعقيد الذي اعتاد التطبيق حمله. أما ما إذا كان ذلك يصمد على نطاق شخص آخر، فهو سؤال لن يجيب عنه إلا حركة الإنتاج الفعلية.