ما الذي يعنيه هذا الاستثناء
Too many parts عندما يؤدي تنفيذ INSERT إلى تجاوز حد مُعدّ مسبقًا لعدد أجزاء البيانات النشطة في جدول MergeTree. وغالبًا ما يتضمن الاستثناء الرسالة Merges are processing significantly slower than inserts.
ينشئ كل INSERT متزامن جزء بيانات واحدًا على الأقل. وإذا كان الإدراج يحتوي على صفوف تخص عدة قيم قسم، فقد ينشئ ClickHouse جزءًا واحدًا لكل قسم متأثر. وتدمج عمليات الدمج في الخلفية الأجزاء الأصغر في أجزاء أكبر، ولكن إذا أُنشئت أجزاء جديدة بوتيرة أسرع مما يستطيع ClickHouse دمجها، فسيستمر عدد الأجزاء النشطة في الازدياد.
يمكن أن يحدث هذا الاستثناء بسبب أيٍّ من هذين الإعدادين:
parts_to_throw_insert، الذي يحدّ من عدد الأجزاء النشطة في قسم واحد.max_parts_in_total، الذي يحدّ من العدد الإجمالي للأجزاء النشطة في table.
تشخيص السبب
max_parts_in_total، احسب جميع الأجزاء النشطة في الجدول:
- عمليات إدراج متزامنة صغيرة ومتكررة.
- مفتاح تقسيم عالي الكاردينالية.
- عمليات إدراج تتضمن صفوفًا تخص العديد من قيم الأقسام.
- عمليات دمج في الخلفية لا تستطيع مواكبة الحمل بسبب محدودية معدل نقل بيانات التخزين، أو عدم كفاية المساحة الحرة على القرص، أو وجود تنازع على الموارد.
system.merges ومراجعة سجلات الخادم للتحقق من حالات فشل الدمج.
حلّ الاستثناء
عمليات الإدراج المتزامنة على دفعات
INSERT متزامنة واحدة تقريبًا كل ثانية. فكلما قلّ عدد عمليات الإدراج وكبر حجمها، قلّ عدد الأجزاء التي يتم إنشاؤها وتراجع العمل المطلوب من عمليات الدمج في الخلفية.
استخدم عمليات الإدراج غير المتزامنة
wait_for_async_insert = 1 لكي لا يؤكّد ClickHouse عملية إدراج إلا بعد كتابة البيانات بنجاح.
راجع مفتاح التقسيم
استقصِ اختناقات الدمج
تجنّب زيادة حدود الأجزاء باعتبارها الحل الأساسي
parts_to_throw_insert أو max_parts_in_total لا تعالج السبب وراء الإنشاء المفرط للأجزاء. قد تؤدي الحدود الأعلى إلى تأخير ظهور الاستثناء، لكنها قد تزيد أيضًا العبء على نظام الملفات والبيانات الوصفية وتقلل من أداء الاستعلامات. لا تغيّر هذه الإعدادات إلا بعد تحديد السبب والتأكد من أن النظام يتمتع بسعة كافية.
تحقّق من التعافي
system.merges حتى يزول التراكم.