كيف يخفض ضغط البادئة الثانوية في PolarDB-X تضخم الفهارس بنسبة تصل إلى 70%

بالنسبة لمشغلي قواعد البيانات، تعتبر الفهارس الثانوية سلاحًا ذو حدين. فهي تسرع الاستعلامات ولكنها يمكن أن تستهلك بسهولة مساحة تخزين أكثر من الجدول الأساسي. في أنظمة SaaS متعددة المستأجرين، ومنصات التجارة الإلكترونية، ومخازن التتبع الموزعة، غالبًا ما تمثل الفهارس أكثر من نصف إجمالي مساحة تخزين المثيل. يؤدي هذا التضخم إلى ارتفاع التكاليف، ويقلل من كفاءة تجمع المخازن المؤقتة، ويزيد من ضغط IOPS، ويزيد من التنافس على B+ tree.

نشر فريق Alibaba Cloud's PolarDB-X وصفًا تقنيًا مفصلاً لمخطط ضغط جديد يسمى ضغط البادئة الثانوية (Secondary Prefix Compression - SPC)، تم تنفيذه في عقدة البيانات (DN) لمحرك التخزين. بدلاً من تطبيق الضغط العام على مستوى الكتل، كما تفعل ميزة ضغط الجدول المدمجة وضغط الصفحة الشفاف في InnoDB، يستغل SPC التكرار البنيوي في صفحات B+ tree الطرفية للفهارس الثانوية. والنتيجة هي قاموس بادئة خفيف الوزن محلي بالصفحة يقلص مساحة الفهرس بنسبة 30% إلى 70% مع الحفاظ على الحمل على وحدة المعالجة المركزية تحت السيطرة.

تشريح تضخم الفهرس

في InnoDB، يخزن كل فهرس ثانوي مجموعة (tuple) من المفتاح الثانوي (SK) والمفتاح الأساسي (PK). نظرًا لأن الفهارس مرتبة حسب المفتاح الثانوي، فإن السجلات المتجاورة داخل صفحة طرفية تميل إلى مشاركة بادئات مشتركة طويلة. تظهر حقول مثل معرفات الطلبات، و SKUs، وعناوين URL، ومسارات الملفات، ومعرفات التتبع تشابهًا كبيرًا في البادئات في أعباء العمل الإنتاجية. ولكن تحت تنسيق السجل COMPACT القياسي لـ InnoDB، يخزن كل سجل مفتاحه الثانوي الكامل بشكل مستقل، حتى السجلات المتتالية التي لها نفس المفتاح الثانوي، حيث يختلف فقط المفتاح الأساسي التالي.

هذا صحيح وظيفيًا ولكنه مسرف مكانيًا. يؤدي التكرار إلى خفض استخدام مساحة الصفحة الطرفية، مما يضعف تغطية البيانات الساخنة في تجمع المخازن المؤقتة، ويزيد من تكرار الوصول إلى الصفحة، ويرفع معدل انقسامات B+ tree والتنافس على SX-latch. يمكن لضواغط الكتل العامة مثل zlib أو lz4 معالجة الأعراض، لكن تكلفة فك الضغط عند كل قراءة، وفي حالة ضغط الجدول، النسخ المزدوج للصفحة في الذاكرة، تجعلها غير مناسبة لأعباء عمل OLTP التي تتطلب وصولاً بزمن استجابة منخفض.

SPC: قواميس البادئة لكل صفحة

يسلك SPC مسارًا مختلفًا. في قلب المخطط يوجد قاموس للبادئات الشائعة لكل صفحة، يتم الاحتفاظ به كمنطقة بيانات وصفية صغيرة داخل كل صفحة فهرس بحجم 16 كيلوبايت. يخزن كل سجل مرجع قاموس فقط، وطولًا يشير إلى عدد بايتات تلك البادئة التي يشاركها، واللاحقة المتبقية الخاصة به. تظل القيمة المنطقية وترتيب الفرز للسجل دون تغيير، ولكن يتم تخزين البادئات المتكررة مرة واحدة فقط لكل صفحة.

يقارن الجدول أدناه SPC مع خيارات ضغط MySQL InnoDB الحالية عبر الأبعاد الرئيسية:

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

الترميز المشغل بالانقسام وتجريد Slice

أحد أكثر قرارات التصميم العملية لـ SPC هو متى يتم الترميز. اعتمد الفريق استراتيجية مشغّلة بالانقسام: يتم إدراج السجلات في شكلها غير المضغوط. فقط عندما تكون الصفحة على وشك النفاد من المساحة وتؤدي إلى انقسام B+ tree، يقوم SPC بترميز الصفحة بأكملها. وهذا يعني أن الصفحات الباردة أو المملوءة بشكل متناثر لا تتحمل أبدًا الحمل الزائد للترميز، ويتم توزيع التكلفة على مئات أو آلاف عمليات DML التي تملأ الصفحة. علاوة على ذلك، غالبًا ما تسمح المساحة التي يوفرها الضغط بإكمال عملية إدراج كانت ستسبب انقسامًا في مكانها؛ حيث يعمل الضغط نفسه كتخفيف لتخفيف الانقسام.

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

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

تضمن طبقة Slice أن SPC غير شفاف دلاليًا لبقية InnoDB، حيث تستمر جميع مسارات الكود الأصلية (MVCC، undo، purge، locking، change buffer، replication، backup/restore) في العمل دون تغيير. من الخارج، SPC هو مجرد تحسين تخزين فيزيائي داخل الصفحة.

نتائج المعايير: مكاسب في الإنتاجية تصل إلى 47% تحت ضغط الإدخال/الإخراج

أجرى فريق PolarDB-X سلسلة من معايير sysbench باستخدام مخطط جدول مصمم لمحاكاة خصائص تكرار البادئة النموذجية: 3 أعمدة INT ذات انتظام منخفض، و 6 أعمدة VARCHAR(64) ذات بادئة مشتركة بطول 40 بايت، و 12 فهرسًا ثانويًا. مع إيقاف تشغيل SPC، احتل جدول واحد من مليون صف 1.8 جيجابايت، منها 1.16 جيجابايت تستهلكها الفهارس الثانوية. مع تشغيل SPC، تقلص الجدول إلى 1.1 جيجابايت، مع الفهارس الثانوية عند 0.52 جيجابايت، أي بنسبة ضغط 55% على الفهارس الثانوية و 38% بشكل عام.

جاءت النتائج الأكثر لفتًا للانتباه في الظروف المقيدة بالإدخال/الإخراج مع تجمع مخازن مؤقتة بحجم 4 جيجابايت (يغطي حوالي 30% من مجموعة البيانات بدون SPC):

مع تجمع مخازن مؤقتة بحجم 8 جيجابايت، ومضاعفة التغطية إلى ما يقرب من 50%، قفزت التحسينات في أعباء العمل المقيدة بقراءة الإدخال/الإخراج إلى +46.8% لـ read_only و +47.5% لـ read_write. ظل عبء العمل write_only ثابتًا تقريبًا (+1.6%) لأن مسار القراءة الخاص به يحدد موقع الصفوف بواسطة المفتاح الأساسي ولا يجتاز أبدًا صفحات الفهرس الثانوي، بينما يضمن الترميز المشغل بالانقسام أن DML الروتيني لا يتحمل حملًا زائدًا للترميز.

مع ضبط تجمع المخازن المؤقتة على 32 جيجابايت، وهو حجم كبير بما يكفي لمجموعة البيانات بأكملها للإقامة في الذاكرة، اختفت ميزة الإدخال/الإخراج. وقعت الاختلافات عبر أعباء العمل الثلاثة ضمن ±2.4%، مما يؤكد أن الحمل الزائد لفك ضغط SPC على مسار وحدة المعالجة المركزية البحت هو ضئيل، وتأثير كتابته لا يكاد يذكر.

كيف يقارن مع قواعد البيانات الأخرى

بين أنظمة قواعد البيانات الرئيسية، فإن ضغط الصفحة في Microsoft SQL Server هو الأقرب من حيث الروح إلى SPC: فهو يطبق خط أنابيب من ثلاث طبقات من ضغط الصف، وضغط البادئة، وضغط القاموس، يتم تشغيله عندما تمتلئ الصفحة. يعمل إلغاء تكرار B-tree في PostgreSQL على دمج المفاتيح المكررة ولكنه لا يعالج المشاركة الجزئية للبادئة. يستخدم ضغط الفهرس المتقدم في Oracle ضغطًا تكيفيًا لكل كتلة، بينما يعمل ضغط البادئة الأساسي الخاص به (COMPRESS n) على مستوى العمود. الدقة على مستوى البايت في SPC تمنحها دقة أدق من نهج Oracle على مستوى العمود، واحتواءها على الفهارس الثانوية، حيث يكون التكرار أعلى، يجعلها تحسينًا موجهًا بدلاً من ضاغط واحد يناسب الجميع.

الخلاصة

SPC ليس انحرافًا جذريًا عن تقنيات ضغط قواعد البيانات الحالية، ولكنه تحسين عملي ومنفذ بشكل جيد يعالج نقطة ألم محددة: تضخم الفهارس الثانوية في أعباء عمل OLTP. من خلال تقييد الضغط على قواميس البادئة لكل صفحة والتي يتم تشغيلها فقط في وقت انقسام الصفحة، تمكن فريق PolarDB-X من تقليل تخزين الفهرس بنسبة 30% إلى 70% مع الحفاظ على تكاليف وحدة المعالجة المركزية والتعقيد منخفضة بما يكفي للنشر في الإنتاج. بالنسبة لمشغلي السحابة الذين يديرون بالفعل أعباء عمل متوافقة مع MySQL على PolarDB-X من Alibaba Cloud، يقدم SPC أداة ذات معنى لخفض فواتير التخزين وتحسين أداء الاستعلام المقيد بالإدخال/الإخراج، دون تغييرات في التطبيق.

بالنسبة لمجتمع هندسة قواعد البيانات الأوسع، فإن الدرس هو أن التكرار البنيوي في صفحات B+ tree المرتبة هو وريد غني يستحق الاستغلال، وأن نهجًا خفيف الوزن ومحدود النطاق يمكنه التفوق على الضواغط العامة الثقيلة في النطاق الأمثل لـ OLTP. التفاصيل الفنية الكاملة متاحة في منشور مدونة فريق PolarDB-X.