خمسة دروس لتصفح جداول الطلبات الضخمة في قاعدة بيانات موزعة

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

يستمد هذا التحليل من حالات إنتاجية حقيقية لمشاركة خمس رؤى تحسينية للاستعلامات المصفحة على جداول الطلبات الضخمة في PolarDB-X، قاعدة بيانات SQL الموزعة من Alibaba Cloud. الاستراتيجيات مبنية حول مخطط تقسيم ثنائي المستوى: تقسيم المستوى الأول حسب KEY بواسطة معرف المستخدم، وتقسيم المستوى الثاني حسب RANGE بواسطة حقل الوقت — وهي بنية شائعة في المنصات المالية والتجارة الإلكترونية وSaaS.

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

تشريح استعلام التصفح البطيء

جدول الطلبات النموذجي في PolarDB-X واسع — 60+ عمودًا — مع فهارس تغطية مصممة لتقليل عمليات البحث الجدولية. يضمن مخطط التقسيم أن جميع البيانات الخاصة بمستخدم معين تصل إلى نفس قسم المستوى الأول (بواسطة معرف المستخدم)، ثم إلى أقسام فرعية حسب التاريخ (بواسطة عمود الطابع الزمني pt).

لنأخذ استعلامًا يجلب الطلبات المعدلة حديثًا لمستأجر كبير:

SELECT * FROM t_order
WHERE uid = 12345678
  AND pt >= '2024-08-01 00:00:00.000'
  AND update_ts > '2024-11-13 14:20:00.000'
  AND update_ts < '2024-11-13 14:25:00.000'
  AND origin != 33
ORDER BY id DESC
LIMIT 0, 100;

الشرط pt >= '2024-08-01' يجبر الاستعلام على مسح أربعة أقسام فرعية: p202408 وp202409 وp202410 وp202411. لكن مرشح update_ts يقيد النتائج بالطلبات المعدلة في الدقائق القليلة الماضية، وهي دائمًا طلبات حديثة تقريبًا — مما يعني أن الصفوف المؤهلة الفعلية تقع جميعها في القسم p202411. الأقسام الثلاثة الأخرى يتم مسحها دون فائدة. على قسم مستأجر كبير، كل مسح مهدر يقرأ أساسًا جميع البيانات في ذلك القسم، ليصبح استعلامًا بطيئًا طويل الذيل يحدد زمن الاستجابة الإجمالي.

الرؤية 1: تقليص الأقسام بواسطة مسندات التصفية

عندما يرتبط عمود التصفية بمفتاح القسم — هنا، الطلبات المعدلة حديثًا تميل إلى أن يكون لها قيم pt حديثة — يمكن لقاعدة البيانات استغلال هذا الارتباط لتخطي الأقسام الفرعية غير الضرورية. يمكن لمحسن PolarDB-X تقليص الأقسام ديناميكيًا عن طريق التعرف على أن النطاق الفعال لـ pt الذي يشير إليه مرشح update_ts أضيق بكثير من النطاق الحرفي pt >= '2024-08-01'. في سيناريو المستخدم الحقيقي، خفض هذا التحسين الاستعلام من 5 ثوانٍ إلى 0.01 ثانية.

الرؤية 2: تقليص الأقسام بواسطة عمود الفرز

سيناريو أكثر شيوعًا هو عندما يحتوي SQL الخاص بالمستخدم فقط على uid كمرشح — دون أي مسندات زمنية على الإطلاق. بدون تقليص الأقسام، يجب على الاستعلام مسح جميع الأقسام الفرعية تحت قسم المستوى الأول المقابل. تحت منطق الدمج الأصلي، يجب إكمال جميع عبارات SQL الفيزيائية للأقسام قبل أن يتمكن الدمج والفرز من المتابعة، مما يعني أن أبطأ قسم (غالبًا ما يكون قسمًا أقدم بكمية هائلة من البيانات) يحدد زمن الاستجابة الإجمالي.

يعالج PolarDB-X هذا من خلال التقليص الديناميكي بناءً على عمود الفرز. لأن عمود الفرز (id أو update_ts) رتيب تقريبًا عبر الزمن — الأقسام الأحدث لها معرفات أعلى أو طوابع زمنية أحدث — يمكن للمحسن التوقف عن مسح الأقسام بمجرد العثور على عدد كافٍ من الصفوف. هذا خفض استعلامًا من 3 ثوانٍ إلى 0.05 ثانية في الإنتاج.

الرؤية 3: ترتيب الفهرس لشروط OR/IN

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

الحل هو تقسيم شروط OR/IN إلى استعلامات فرعية متعددة مرتبة، ثم دمجها:

SELECT * FROM (
    (SELECT * FROM t_swap WHERE asset_a = 'TOKEN26'
     ORDER BY id LIMIT 100)
    UNION
    (SELECT * FROM t_swap WHERE asset_b = 'TOKEN50'
     ORDER BY id LIMIT 100)
) t
ORDER BY id
LIMIT 100;

كل فرع يستخدم فهرسه الخاص للإنهاء المبكر. في سيناريو المستخدم، حول هذا استعلامًا من 10 ثوانٍ إلى 0.001 ثانية.

الرؤية 4: تقليل عمليات البحث الجدولية بالتأخير المادي

بالنسبة للجداول الواسعة (60+ عمودًا)، فإن SELECT * مع عمليات البحث الجدولية مكلف للغاية. تساعد فهارس التغطية، لكنها تستهلك مساحة تخزين كبيرة. عندما لا تكون فهارس التغطية ممكنة، يكون التأخير المادي هو الحل: أولاً استرداد المفاتيح الأساسية فقط من خلال فهرس تغطية (جلب فقط عدد LIMIT من الصفوف)، ثم إجراء بحث دقيق بالمفتاح الأساسي لتلك الصفوف القليلة.

SELECT t_order0.*
FROM (
    SELECT id, uid, pt
    FROM t_order 
    WHERE uid = 1
      AND channel_id = 0
      AND sub_id IN (0)
      AND id > 123456789
    ORDER BY update_ts DESC
    LIMIT 20
) AS t3
INNER JOIN t_order AS t_order0
  ON t3.id = t_order0.id
  AND t3.uid = t_order0.uid
  AND t3.pt = t_order0.pt
ORDER BY t_order0.update_ts DESC
LIMIT 20;

خفض هذا استعلامًا من 10 ثوانٍ إلى 0.6 ثانية. إلى جانب تحسينات مستوى SQL، يعمل PolarDB-X أيضًا على تحسين عمليات البحث الجدولية على مستوى محرك التخزين (تخمين رقم صفحة المفتاح الأساسي والعنونة الفيزيائية) لتقليل تضخيم I/O وتحسين معدلات ضرب الذاكرة المخبأة.

الرؤية 5: اختيار فهرس محدد

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

قائمة التحقق القياسية: فهرسة عمود الفرز (تجنب filesort)، وضع أعمدة WHERE المساواة قبل أعمدة ORDER BY في الفهارس المركبة، استخدام فهارس التغطية عند الإمكان، وضع الأعمدة عالية الانتقائية أولاً، تجنب الدوال على الأعمدة المفهرسة، والحفاظ على اتساق النوع. عندما يتطابق سلوك قاعدة البيانات مع تصميم الفهرس الموصى به، يتم ضمان الاستقرار. في الإنتاج، حافظ PolarDB-X على اختيار فهرس مستقر بينما أظهرت قاعدة بيانات موزعة منافسة سلوكًا غير مستقر — مما أدى إلى ذروة QPS تبلغ 4K (مع تعطل) مقابل 60K (قابلة للتوسع خطيًا) لـ PolarDB-X.

جدول ملخص للتحسينات في العالم الواقعي

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