قبل أن تبدأ
nyc_taxi.trips_small_inferred. أنشئه وحمّله إذا لم تكن قد فعلت ذلك بالفعل:
إعداد مجموعة البيانات النموذجية
إعداد مجموعة البيانات النموذجية
يبلغ حجم ملف Parquet المصدر نحو 5.8 GB. قد يستغرق تحميله عدة دقائق، حسب الشبكة والموارد المتاحة.
نظرة عامة على العملية
- شغّل ثلاثة استعلامات لأحمال عمل مستقلة على المخطط المستنتج لتحديد خط أساس.
- أنشئ جدولًا بأنواع أعمدة أدق، وحمّل البيانات نفسها، ثم أعد تشغيل الاستعلامات.
- أنشئ جدولًا آخر بالمخطط المُحسَّن نفسه ومفتاح ترتيب، ثم أعد تشغيل الاستعلامات مجددًا.
تحديد حمل العمل الأساسي
تساعد هذه الإعدادات على جعل عمليات التشغيل المتكررة قابلة للمقارنة أثناء الاختبار. أعد القيم السابقة لها بعد إتمام القياسات.
system.query_log.
التصفية حسب سرعة الرحلة المحسوبة
تجميع الرحلات ضمن نطاق زمني
التصفية حسب عدد الركاب
تقرأ الاستعلامات الثلاثة نحو 329 مليون صف لكل منها، وهو عدد قريب من إجمالي الصفوف في الجدول. ويوضح ذلك إمكانية تحسين جانبين مختلفين من عبء العمل: تقليل تكلفة معالجة الأعمدة المحددة، ثم تقليل عدد الصفوف المحددة عندما تسمح عوامل التصفية بذلك.
تحسين المخطط
تجنّب أعمدة Nullable غير الضرورية
Nullable قناعًا للقيم NULL بالإضافة إلى قيمه. استخدم Nullable عندما يكون التمييز بين قيمة NULL والقيمة الافتراضية للنوع مهمًا، ولكن تجنّبه للأعمدة التي يُضمن أن تحتوي على قيمة.
احسب قيم NULL في الأعمدة المستخدمة في المخطط النموذجي:
ratecode_id وmta_tax وpayment_type على قيم فارغة في مجموعة البيانات هذه. ويُبقي المخطط المُحسَّن النوع Nullable لهذه الأعمدة ويزيله من الأعمدة الأخرى.
استخدم LowCardinality للقيم المتكررة
LowCardinality ترميز القاموس، ويمكنه تقليل مساحة التخزين ووقت المعالجة للأعمدة التي تحتوي على قيم متكررة بكثرة. تحقّق من عدد القيم الفريدة قبل استخدامه:
LowCardinality، رغم أنه ينبغي قياس تأثير ذلك على حمل العمل. ويُعد نحو 10,000 قيمة مميزة نقطة بداية مفيدة لتحديد المرشحات، وليس حدًا ثابتًا.
اختر أنواع بيانات أكثر دقة
Int64 أو Float64 المستنتج:
UInt8، رغم أن passenger_count يصل إلى قيمته القصوى البالغة 255. يستخدم المثال أيضًا Float32 لـ trip_distance وDecimal32 للقيم النقدية. تقع جميع القيم في مجموعة البيانات هذه ضمن النطاقات المستهدفة، ويقبل المثال الدقة الأقل للأرقام ذات الفاصلة العائمة والدقة النقدية على مستوى السنت، لأن عبء العمل فيه يقارن النتائج التجميعية. احتفظ بأنواع المصدر الأوسع عندما تكون قيم المصدر الدقيقة مطلوبة. يستبدل المثال أعمدة DateTime64 المستنتجة بـ DateTime ضمن المنطقة الزمنية UTC نفسها، لأن استعلامات المثال لا تتطلب دقة أجزاء الثانية.
هذه الخيارات خاصة بمجموعة البيانات هذه. تأكد من متطلبات النطاق والدقة وقابلية القيم لأن تكون فارغة في بيانات الإنتاج قبل تطبيق التغييرات نفسها.
تطبيق تغييرات المخطط
nyc_taxi.trips_small_inferred بـ nyc_taxi.trips_small_no_pk، ثم أعد تشغيل الاستعلامات الثلاثة. سجّل المثال الأصلي النتائج التمثيلية التالية:
لا تزال الاستعلامات تقرأ العدد نفسه من الصفوف، لكن المخطط المُحسَّن يقلل كمية البيانات التي تمثلها هذه الصفوف. لذلك تتحسن مدة الاستعلام وذروة استهلاك الذاكرة دون تغيير البيانات المحددة.
قارن الحجم على القرص للجدولين:
تحسين مفتاح الترتيب
MergeTree، يحدد مفتاح الترتيب كيفية ترتيب الصفوف على القرص. ينشئ ClickHouse فهرسًا أساسيًا متناثرًا وفقًا لهذا الترتيب، بحيث يتمكن من تجاوز الحبيبات التي لا يمكنها تلبية عوامل تصفية الاستعلام. وعلى خلاف المفتاح الأساسي في كثير من قواعد البيانات المعاملاتية، لا يفرض هذا المفتاح تفرّد القيم.
ينبغي أن يعكس مفتاح الترتيب عوامل التصفية المستخدمة في الاستعلامات المهمة والمتكررة. ترتيب الأعمدة مهم: يكون المفتاح أكثر فعالية عندما يطبّق الاستعلام عامل تصفية على بادئة مفيدة منه. قد تكون الأعمدة منخفضة التعددية خيارات فعالة في بداية المفتاح إذا كانت تُصفّى كثيرًا، وغالبًا ما يكون مكوّن الوقت مفيدًا لأحمال العمل المستندة إلى الوقت. للحصول على إرشادات مفصلة حول الاختيار، راجع اختيار مفتاح أساسي.
في هذا المثال، استخدم (passenger_count, pickup_datetime, dropoff_datetime). يحتوي passenger_count على عدد قليل من القيم المميزة ويظهر في عامل تصفية عدد الركاب، بينما يظهر pickup_datetime في تجميع نطاق التاريخ. وعلى الرغم من أن pickup_datetime ليس العمود الأول، يظل بإمكان ClickHouse استخدام قيم من أعمدة المفتاح اللاحقة لاستبعاد البيانات عندما لا يكون العمود الأول مقيّدًا. تؤدي التصفية على بادئة مفيدة من مفتاح الترتيب عمومًا إلى تقليم أكثر فعالية.
طبّق تغيير مفتاح الترتيب
nyc_taxi.trips_small_pk، ثم أعد تنفيذ الاستعلامات الثلاثة.
مقارنة النتائج
يقلل تحسين المخطط مساحة التخزين ويجعل معالجة القيم المحددة أقل تكلفة. ويوفر مفتاح الترتيب أكبر تحسن إضافي لتجميع نطاق التاريخ، إذ يمكن لـ ClickHouse تجاوز الحبيبات الواقعة خارج نطاق التاريخ. كما يقرأ عامل تصفية عدد الركاب صفوفًا أقل لأنه يطبّق التصفية على أول عمود في المفتاح. أما عامل تصفية السرعة المحسوبة، فلا يزال يقرأ الجدول بأكمله لأن شرط التصفية فيه مشتق من
pickup_datetime وdropoff_datetime وtrip_distance، وليس من بادئة مفيدة لمفتاح الترتيب.
افحص تجميع نطاق التاريخ باستخدام EXPLAIN indexes = 1:
في ClickHouse 25.9 والإصدارات الأحدث، تضمن هذه الإعدادات أن يعرض
EXPLAIN الفهارس المستخدمة والأجزاء والحبيبات التي تُسقِطها.طبّق المنهج على حمل العمل لديك
- سجّل المدة الأساسية، والصفوف والبايتات المقروءة، وذروة الذاكرة.
- تحقّق مما إذا كانت الأعمدة المحددة تستخدم أنواعًا واسعة أو متساهلة أكثر من اللازم.
- طبّق تغييرات المخطط وقِس أثرها دون تغيير تخطيط البيانات.
- اختبر مفتاح ترتيب يستند إلى عوامل التصفية المستخدمة في الاستعلامات المتكررة المهمة.
- قارن البيانات المحددة باستخدام
EXPLAIN indexes = 1، ثم أعد تشغيل الاستعلامات الأساسية في ظروف مماثلة.