هندسة قواعد البيانات
مؤشر باندا من علي بابا يمنح المفاتيح الفريدة في InnoDB سجل إصدارات لم يكن لديها من قبل
يدفع مؤشر باندا آلية إصدارات الفهرس العنقودي إلى سجلات المفاتيح الفريدة، مضيفًا أعمدة معاملات وسلسلة تراجع مستقلة. والنتيجة هي قفل سجل واحد بدلاً من عدة أقفال فجوات، وقراءات تعتمد على الفهرس فقط دون لمس الفهرس العنقودي. ما تزال المعايير المستقلة مفقودة.
Emmanuel Fabrice Omgbwa Yasse بمساعدة الذكاء الاصطناعي
2026-08-06 · قراءة 4 دقائق

المفاتيح الفريدة هي عنق الزجاجة الصامت في قواعد البيانات عبر الإنترنت. تعتمد معرّفات الطلبات وأرقام الهواتف والأرقام التسلسلية للمعاملات على فهارس المفاتيح الفريدة (UK) لتبقى غير مكررة، وتحت التزامن العالي يبدأ ثمن هذا الإنفاذ بالارتفاع. في InnoDB، المحرك الذي يقف خلف MySQL وPolarDB-X المتوافق مع MySQL من علي بابا، المشكلة بنيوية: الفهارس الثانوية لا تحمل أي معلومات عن الإصدارات، لذلك يعوّض المحرك بأقفال الفجوات والبحث في الجداول.
نشر فريق PolarDB-X من علي بابا حلًا. مؤشر باندا، وهو فهرس UK من الجيل الجديد لعقد بيانات المحرك، يمنح المفاتيح الفريدة قدرة أصلية على تعدد الإصدارات مع أعمدة معاملات وسلسلة تراجع مستقلة في كل سجل. يصف المنشور التقني لفريق ApsaraDB مسار إدراج أبسط وفحوصات حقيقية تعتمد على الفهرس فقط.
عنق زجاجة المفاتيح الفريدة في InnoDB
PolarDB-X هي قاعدة بيانات موزعة على بنية موحّدة تجمع بين المركزية والتوزيع، متوافقة تمامًا مع MySQL، مع مخزن صفوف يعالج المعاملات OLTP في كل عقدة بيانات. يدير الفهرس العنقودي في InnoDB التاريخ بالطريقة القياسية: يحمل كل سجل TRX_ID وROLL_PTR يشيران إلى سلسلة تراجع، وتتم التحديثات في مكانها، وتحتفظ شجرة B+ بأحدث إصدار فقط. لا تحصل الفهارس الثانوية على أي من ذلك. سجلات UK لا تحمل TRX_ID ولا ROLL_PTR ولا أي معلومات عن الإصدارات.
لذلك يستخدم تحديث المفتاح الفريد أسلوب "وضع علامة حذف ثم إدراج": يعلّم المحرك السجل القديم كمحذوف، ثم يُدرج سجلًا جديدًا. وإلى أن يعمل خيط التطهير، تتعايش عدة سجلات فيزيائية بنفس المفتاح على الفهرس. وهذا يكسر إنفاذ التفرد بطريقتين.
المشكلة الأولى هي الأقفال. لا يستطيع كشف تعارضات الإدراج تحديد أي من السجلات المتعددة التي تشترك في مفتاح واحد هو النشط، لذلك يفحصها جميعًا ويضع أقفال فجوات عبر الفترة. تنتهي المعاملات غير المتعارضة منطقيًا بانتظار بعضها البعض، وأحيانًا تصل إلى طريق مسدود (deadlock). ويشير مهندسو ApsaraDB إلى أن المشكلة حادة بشكل خاص في أنظمة التداول وخصومات الأرصدة والمبيعات الخاطفة.
المشكلة الثانية هي الرؤية. دون معلومات عن الإصدارات في سجلات UK، لا يستطيع قارئ MVCC الحكم على الرؤية بمفرده، حتى عندما يغطي الفهرس كل عمود في الاستعلام. يجب أن يعود إلى الفهرس العنقودي ويمشي عبر سلسلة التراجع، وكذلك الحال بالنسبة لكشف الأقفال الضمني والتطهير. تضيف أعباء العمل كثيفة الكتابة عقوبة ثالثة: يتخلف التطهير عن الحذف، وتوسّع السجلات المتبقية المعلّمة كمحذوفة نطاق فحص التعارض التالي.
داخل مؤشر باندا: أربعة أعمدة نظام وسلسلة تراجع مستقلة
يدفع مؤشر باندا آلية إصدارات الفهرس العنقودي إلى فهرس UK. يكتسب كل سجل أربعة أعمدة نظام: TRX_ID، وهو معرّف المعاملة لأحدث تعديل؛ وROLL_PTR، وهو مؤشر إلى سجل تراجع مستقل؛ وSCN، وهو رقم تسلسل الالتزام من نظام معاملات Lizard؛ وUBA، وهو عنوان كتلة تراجع. دلالاتها تطابق سجلات الفهرس العنقودي، لذلك يعيد المحرك استخدام إطار الرؤية الحالي لـLizard، Vision.
يشير ROLL_PTR إلى سلسلة تراجع يملكها فهرس UK وحده. تتم التحديثات في مكانها: لا "وضع علامة حذف ثم إدراج"، سجل فيزيائي واحد لكل مفتاح فريد، والإصدارات التاريخية مخزنة في مساحة جداول تراجع منفصلة، يمكن الوصول إليها عبر ROLL_PTR دون بحث في الجداول. تتبع عمليات DML الأمامية والتراجع والتطهير منطقًا مخصصًا لكل منها، وهو ما يفصل دورة حياة إصدارات فهرس UK عن دورة حياة الفهرس العنقودي.
قفل سجل واحد بدلاً من صف من أقفال الفجوات
تنتج التحديثات في المكان تأثيرًا جانبيًا مفيدًا: يوجد على الأكثر سجل فيزيائي واحد لكل مفتاح فريد. ينكمش كشف تعارضات الإدراج إلى فحص واحد. إذا لم يوجد سجل، ينجح الإدراج فورًا. إذا وُجد واحد، يضع المحرك قفل سجل واحد عليه ويفحص ما إذا كان معلّمًا كمحذوف. لا أقفال فجوات، وبصمة أقفال أصغر بكثير.
يتضمن المنشور مثالًا محلولًا. تحذف معاملة صفًا حيث c1 = 1 وتُدرج صفًا جديدًا بنفس القيمة؛ ثم تُدرج معاملة ثانية c1 = 2، وهو ما لا يتعارض. في سلوك InnoDB القياسي، تنتهي مهلة الإدراج الثاني، مع أربعة أقفال على الفهرس، ثلاثة منها أقفال فجوات. في ظل مؤشر باندا، ينجح فورًا بقفل سجل واحد من نوع X,REC_NOT_GAP.
| فهرس InnoDB UK القياسي | مؤشر باندا | |
|---|---|---|
| السجلات الفيزيائية لكل مفتاح فريد | تتراكم الإصدارات المعلّمة كمحذوفة حتى التطهير | واحد، يُحدَّث في مكانه |
| فحص تعارض الإدراج | يفحص كل السجلات المشتركة في المفتاح، ويقفل الفترة بأقفال فجوات | قفل سجل واحد، دون أقفال فجوات |
| فحص الرؤية | بحث في الجدول عبر الفهرس العنقودي وسلسلة التراجع | محلي، عبر TRX_ID وSCN وUBA |
| نتيجة مثال c1 = 2 | تنتهي مهلة الإدراج، مع أربعة أقفال محتفظ بها | ينجح الإدراج، بقفل واحد للمفتاح الجديد |
تحصل الرؤية على التبسيط نفسه: تكتمل القراءات المتسقة داخل شجرة B+ للفهرس، وتحصل استعلامات الفهارس المُغطية على فحوصات حقيقية تعتمد على الفهرس فقط، ولم يعد كشف الأقفال الضمني يصل إلى الفهرس العنقودي.
مكسب التزامن العالي، وما زال مفقودًا
يحاذي هذا التغيير إدارة إصدارات UK مع الفهرس العنقودي، وهو أمر يعالجه InnoDB جيدًا بالفعل. نشرت علي بابا نتائج لأعمال قريبة في فهارس قواعد البيانات: خفّض ضغط البادئة الثانوي في PolarDB-X مساحة الفهرس بنسبة 30 إلى 70 في المئة، مع مكاسب في إنتاجية sysbench تصل إلى 47 في المئة تحت ضغط الإدخال/الإخراج، وأبلغت هندسة فهرس المتجهات المنفصلة في PolarDB عن بناء واستعلامات أسرع بمعدل 1.5 إلى 2 مرة، مع انخفاض تنازع الإدخال/الإخراج بنسبة 90 في المئة.
لا يوجد لمؤشر باندا نفسه أرقام منشورة بعد. لا يتضمن المنشور معايير أداء، وتغطي أدلة جدول الأقفال سيناريو واحدًا مبنيًا يدويًا. تضيف أربعة أعمدة نظام إضافية وسلسلة تراجع ثانية أعباء تخزين وتطهير خاصة بها، وما إذا كانت هذه الأعباء ستبقى ثابتة في ظل عمليات الكتابة الكثيفة على UK هو أمر لا يمكن أن تجيب عنه سوى القياسات. الخلاصة الصادقة: الآلية تبدو صحيحة، وقاعدة الأدلة تعود إلى علي بابا نفسها.
- المصدر : Alibaba's Panda Index gives InnoDB unique keys a version history they never had — 2024-04-10
أهم أخبار التقنية في 3 دقائق كل صباح
بريد إلكتروني واحد، كل يوم عمل، بما يهم فعلاً في الذكاء الاصطناعي والتقنية.