تخزّن جداول ClickHouse التي تستخدم محرك MergeTree البيانات على القرص على هيئة أجزاء غير قابلة للتغيير، ويُنشأ جزء جديد منها في كل مرة يتم فيها insert للبيانات.
تنشئ كل عملية insert جزءًا جديدًا يحتوي على ملفات أعمدة مرتّبة ومضغوطة، إلى جانب بيانات وصفية مثل الفهارس وقيم التحقق. للحصول على وصف مفصل لبنية الأجزاء وكيفية تكوّنها، نوصي بهذا الدليل.
ومع مرور الوقت، تدمج العمليات التي تعمل في الخلفية الأجزاء الأصغر في أجزاء أكبر لتقليل التجزئة وتحسين أداء الاستعلامات.
ورغم أنه قد يكون من المغري تشغيل هذا الدمج يدويًا باستخدام:
OPTIMIZE TABLE <table> FINAL;
OPTIMIZE FINAL في معظم الحالات لأنها تبدأ
عمليات كثيفة الاستهلاك للموارد قد تؤثر في أداء الـ cluster.
OPTIMIZE FINAL مقابل FINALOPTIMIZE FINAL ليس هو نفسه FINAL، والذي يكون استخدامه ضروريًا أحيانًا
للحصول على نتائج من دون تكرار، كما هو الحال مع ReplacingMergeTree. وبشكل عام،
لا بأس باستخدام FINAL إذا كانت استعلاماتك تُجري التصفية على الأعمدة نفسها
الموجودة في المفتاح الأساسي.
OPTIMIZE FINAL إلى إجبار ClickHouse على دمج جميع الأجزاء النشطة في جزء واحد، حتى لو كانت عمليات دمج كبيرة قد أُجريت بالفعل. ويتضمن ذلك:
- فك ضغط جميع الأجزاء
- دمج البيانات
- إعادة ضغطها
- كتابة الجزء النهائي إلى القرص أو إلى التخزين الكائني
هذه الخطوات كثيفة الاستهلاك لوحدة المعالجة المركزية (CPU) وعمليات الإدخال/الإخراج، وقد تُشكل عبئًا كبيرًا على نظامك، خاصةً عند التعامل مع مجموعات بيانات كبيرة.
في الوضع العادي، يتجنب ClickHouse دمج الأجزاء التي يزيد حجمها على ~150 GB (يمكن ضبط ذلك عبر max_bytes_to_merge_at_max_space_in_pool). لكن OPTIMIZE FINAL يتجاوز وسيلة الحماية هذه، ما يعني:
- قد يحاول دمج عدة أجزاء بحجم 150 GB في جزء واحد هائل
- قد يؤدي ذلك إلى أوقات دمج طويلة، وضغط على الذاكرة، أو حتى أخطاء نفاد الذاكرة
- قد تصبح هذه الأجزاء الكبيرة صعبة الدمج، أي إن محاولات دمجها لاحقًا قد تفشل للأسباب المذكورة أعلاه. وفي الحالات التي تكون فيها عمليات الدمج مطلوبة لضمان سلوك صحيح وقت الاستعلام، فقد يؤدي ذلك إلى عواقب غير مرغوبة، مثل تراكم السجلات المكررة في ReplacingMergeTree، مما يضعف الأداء وقت الاستعلام.
دع عمليات الدمج في الخلفية تتولى المهمة
