عندما يجعل إصلاحُ الذرّية عمليةَ الاستيعاب أسرع بنسبة 12%

السياق: أكثر مسارات الكتابة نشاطًا في PmaControl

كل بضع ثوانٍ، يجمع كلُّ وكيل PmaControl مئاتِ المقاييس من خوادم MariaDB / MySQL لديكم: متغيرات الحالة، عدّادات InnoDB، حالة النسخ المتماثل، ملخّصات الاستعلامات. كل ذلك يتجمّع في Integrate::insert_value() التي تكتب هذه القياسات في جداول ts_value_general_* — وهو مسار الكتابة الأكثر انشغالًا في التطبيق.

وللبقاء دائمًا دون حدّ max_allowed_packet، تُجمَّع الصفوف في أجزاء (chunks): تُحسَب ميزانية SQL ديناميكيًا من الخادم (مع هامش أمان)، فتتحوّل دفعة من 200,000 قياس إلى نحو 32 استعلام INSERT INTO ... VALUES (...), (...), ... بحجم 256 كيبيبايت تقريبًا لكل منها.

حتى الآن، كانت هذه الاستعلامات الـ 32 تُنفَّذ في وضع autocommit: أي 32 عملية INSERT و32 عملية COMMIT ضمنية.

الخلل: كتابات جزئية صامتة

ماذا يحدث إذا فشل الجزء رقم 17 — جدول ممتلئ، أو deadlock، أو انقطاع اتصال؟

قبل الإصلاح: كانت الأجزاء من 1 إلى 16 تبقى مكتوبة، وتضيع الأجزاء من 17 إلى 32، وقد تستمر المعالجة اللاحقة (ربط الخادم/المتغير، نقطة تفتيش الاستيعاب) وكأن كل شيء نجح. كانت الدفعة المنطقية تتحوّل إلى كتابة جزئية صامتة — أسوأ سيناريو ممكن لبيانات المراقبة: رسوم بيانية فيها فجوات لا يُبلّغ عنها شيء.

ثلاث مشكلات منفصلة كانت تلتقي عند السبب الجذري نفسه:

• #1467 / #1471 — كتابات جزئية عند حدوث فشل في منتصف الدفعة؛
• #1468 / #1472 — صفٌّ واحد أكبر من الميزانية كان يُرسَل إلى الخادم رغم ذلك، ليفشل حتمًا عند max_allowed_packet؛
• #1469 — تراجعٌ صامت كان يمكن أن يعطّل الاكتشاف الديناميكي للميزانية.

الإصلاح: دفعة واحدة = معاملة واحدة

يقدّم الإصلاح (PR #2323) الدالة executeTimeSeriesInsertBatch(): جميع أجزاء نوع المقياس الواحد أصبحت الآن مغلّفة في معاملة واحدة:

START TRANSACTION;
INSERT INTO ts_value_general_int (...) VALUES (...), (...), ...;  -- الجزء 1
INSERT INTO ts_value_general_int (...) VALUES (...), (...), ...;  -- الجزء 2
-- ... 30 جزءًا آخر ...
COMMIT;

أيُّ فشل — نتيجة falsy، أو تحذير غير حميد، أو استثناء — يستدعي ROLLBACK ويرفع استثناءً منمّطًا يحمل بيانات تشخيصية آمنة (الجدول، الجزء، البايتات المقدَّرة، الميزانية). ويُحتفَظ بملف القياسات لإعادة التشغيل: إمّا أن تُحفَظ الدفعة كاملة، وإمّا لا شيء.

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

سؤال الـ 12%: كم الكلفة؟

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

أجرينا اختبارًا معياريًا قبل الدمج. البروتوكول:

• إعادة تشغيل مطابقة للحلقة الساخنة في insert_value() (التجزئة ← بناء SQL ← التنفيذ)، وليس اختبارًا مصطنعًا؛
• 200,000 صفّ حتميّ في ts_value_general_int (مفاتيح أساسية فريدة)، ميزانية 256 كيبيبايت ← 32 جزءًا؛
• MariaDB 11.8 وPHP 8.5.8 وجدول InnoDB، مع TRUNCATE بين الجولات، وجولة إحماء واحدة + 5 جولات مقاسة؛
• الحاوية LXC نفسها والبيانات نفسها، ولا يتغيّر بين القياسين سوى كود التطبيق.

النتائج:

الوسيط أسرع بنسبة 12.5%. إصلاح الذرّية لا يكلّف شيئًا: بل يوفّر الوقت. ارتفعت إنتاجية الاستيعاب من نحو 173,000 إلى 198,000 قياس في الثانية.

لماذا هو أسرع: الثمن الخفي لـ COMMIT

الجواب يكمن فيما يفعله COMMIT فعليًا داخل InnoDB.

عند كل إتمام، يجب على InnoDB أن يجعل المعاملة دائمة: كتابة صفحات سجلّ redo و — مع innodb_flush_log_at_trx_commit = 1، القيمة الافتراضية والوحيدة الآمنة حقًا — فرض fsync() على ملف السجلّ. هذا التفريغ هو أغلى عملية في دورة حياة المعاملة: فهو ينتظر وسيط التخزين فعليًا.

في وضع autocommit، كل INSERT هو معاملة مستقلة:

• قبل: 32 جزءًا = 32 COMMIT = 32 تفريغًا لسجلّ redo؛
• بعد: 32 جزءًا = 1 COMMIT = تفريغ واحد لسجلّ redo.

المزامنات الـ 31 الموفَّرة تفوق بكثير كلفةَ سجلّ undo الأطول قليلًا. إنها الآلية نفسها التي تجعل استيراد SQL أسرع كثيرًا داخل معاملة، أو التي تتيح لـ group commit في MariaDB توزيع كلفة التفريغ بين المعاملات المتزامنة — مطبَّقة هنا داخل دفعة منطقية واحدة.

يعتمد المكسب على العتاد: على وسيط تخزين بطيء الـ fsync() (أقراص ميكانيكية، أو وسائط افتراضية بلا ذاكرة كتابة مؤقتة آمنة) يتّسع الفارق أكثر. وعلى NVMe سريع يضيق. لكن الإشارة لا تنقلب أبدًا: المعاملة الواحدة دائمًا أسرع أو مساوية على الأقل.

الخلاصات

• الذرّية ليست ترفًا يُدفَع ثمنه؛ بل كثيرًا ما تكون تحسينًا. تجميع الكتابات المترابطة في معاملة واحدة يلغي تفريغات سجلّ redo — فالسلامة والأداء يسيران في الاتجاه نفسه.
• اختبروا مسار الكود الحقيقي. إعادة تشغيل الحلقة الساخنة الفعلية على قاعدة بيانات حقيقية هي ما حوّل «نقبل الكلفة» إلى «لا كلفة أصلًا».
• يجب أن يكون الفشل صاخبًا وكاملًا. دفعة مقاييس مكتوبة نصفيًا أسوأ من دفعة يُعاد تشغيلها: منذ هذا الإصلاح، يضمن PmaControl مبدأ الكل أو لا شيء في استيعاب السلاسل الزمنية.

هذا الإصلاح متاح في فرع master من PmaControl منذ 25 يوليو 2026.