دروس - رؤى تصحيح الأخطاء

اعثر على حلول لأكثر مشكلات ClickHouse شيوعًا، بما في ذلك الاستعلامات البطيئة، وأخطاء الذاكرة، ومشكلات الاتصال، ومشكلات الإعداد.

هذا الدليل جزء من مجموعة من الخلاصات المستمدة من لقاءات المجتمع. ولمزيد من الحلول العملية والرؤى، يمكنك التصفح حسب المشكلة. هل تعاني من ارتفاع التكاليف التشغيلية؟ اطّلع على دليل رؤى المجتمع حول تحسين التكلفة.

​

جداول النظام الأساسية

تُعد جداول النظام هذه ضرورية لتصحيح الأخطاء في بيئة الإنتاج:

​

system.errors

يعرض جميع الأخطاء النشطة في مثيل ClickHouse الخاص بك.

SELECT name, value, changed 
FROM system.errors 
WHERE value > 0 
ORDER BY value DESC;

​

system.replicas

يحتوي على معلومات عن حالة النسخ المتماثل ودرجة تأخره لمراقبة صحة العنقود.

SELECT database, table, replica_name, absolute_delay, queue_size, inserts_in_queue
FROM system.replicas 
WHERE absolute_delay > 60
ORDER BY absolute_delay DESC;

​

system.replication_queue

يوفّر معلومات مفصّلة لتشخيص مشكلات النسخ المتماثل.

SELECT database, table, replica_name, position, type, create_time, last_exception
FROM system.replication_queue 
WHERE last_exception != ''
ORDER BY create_time DESC;

​

system.merges

يعرض عمليات الدمج الحالية، ويمكن من خلاله تحديد العمليات العالقة.

SELECT database, table, elapsed, progress, is_mutation, total_size_bytes_compressed
FROM system.merges 
ORDER BY elapsed DESC;

​

system.parts

ضروري لمراقبة عدد الأجزاء واكتشاف مشكلات التجزؤ.

SELECT database, table, count() as part_count
FROM system.parts 
WHERE active = 1
GROUP BY database, table
ORDER BY count() DESC;

​

المشكلات الشائعة في بيئة الإنتاج

​

مشكلات مساحة القرص

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

إذا كنت تستخدم AWS، فاعلم أن وحدات EBS الافتراضية للأغراض العامة لها حد أقصى يبلغ 16 تيرابايت.

​

خطأ «Too many parts»

تتسبب عمليات الإدراج الصغيرة والمتكررة في مشكلات بالأداء. وقد تبيّن في المجتمع أن معدلات الإدراج التي تتجاوز 10 مرات في الثانية كثيرًا ما تؤدي إلى ظهور أخطاء «Too many parts»، لأن ClickHouse لا يستطيع دمج الأجزاء بالسرعة الكافية.

الحلول:

• اجمع البيانات على دفعات باستخدام حدود 30 ثانية أو 200 ميغابايت
• فعّل async_insert للتجميع التلقائي على دفعات
• استخدم الجداول المؤقتة للتجميع على دفعات على جانب الخادم
• اضبط Kafka للتحكم في أحجام الدفعات

التوصية الرسمية: حد أدنى 1,000 صف لكل عملية إدراج، ويُفضّل أن يتراوح العدد بين 10,000 و100,000.

​

مشكلات الطوابع الزمنية غير الصالحة

تتسبب التطبيقات التي ترسل بيانات بطوابع زمنية عشوائية في حدوث مشكلات في الأقسام. وينتج عن ذلك أقسام تضم بيانات بتواريخ غير واقعية (مثل 1998 أو 2050)، مما يسبب سلوكًا غير متوقع في التخزين.

​

مخاطر عملية ALTER

قد تستهلك عمليات ALTER الكبيرة على الجداول التي تبلغ أحجامها عدة تيرابايت موارد كبيرة، وقد تتسبب في قفل قواعد البيانات. وفي أحد الأمثلة من المجتمع، أدى تغيير النوع من Integer إلى Float على 14 تيرابايت من البيانات إلى قفل قاعدة البيانات بالكامل، واستلزم إعادة بنائها من النسخ الاحتياطية.

راقب عمليات التعديل المكلفة:

SELECT database, table, mutation_id, command, parts_to_do, is_done
FROM system.mutations 
WHERE is_done = 0;

اختبر تغييرات المخطط أولًا على مجموعات بيانات أصغر حجمًا.

​

الذاكرة والأداء

​

التجميع الخارجي

فعِّل التجميع الخارجي للعمليات كثيفة الاستهلاك للذاكرة. يكون أبطأ، لكنه يمنع الأعطال الناتجة عن نفاد الذاكرة عبر تفريغ البيانات إلى القرص. يمكنك إجراء ذلك باستخدام max_bytes_before_external_group_by، ما يساعد على منع الأعطال الناتجة عن نفاد الذاكرة في عمليات GROUP BY الكبيرة. يمكنك معرفة المزيد عن هذا الإعداد هنا.

SELECT 
    column1,
    column2,
    COUNT(*) as count,
    SUM(value) as total
FROM large_table
GROUP BY column1, column2
SETTINGS max_bytes_before_external_group_by = 1000000000; -- 1GB threshold

​

تفاصيل الإدراج غير المتزامن

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

الوثائق ذات الصلة

• اختيار استراتيجية الإدراج

​

تهيئة الجدول الموزّع

بشكل افتراضي، تستخدم الجداول الموزّعة عمليات insert أحادية الخيط. فعِّل insert_distributed_sync للمعالجة المتوازية والإرسال الفوري للبيانات إلى المقاطع.

راقب تراكم البيانات المؤقتة عند استخدام الجداول الموزّعة.

​

عتبات مراقبة الأداء

عتبات المراقبة التي يوصي بها المجتمع:

• عدد الأجزاء لكل قسم: يُفضَّل أن يكون أقل من 100
• عمليات الإدراج المتأخرة: يجب أن تبقى عند الصفر
• معدل الإدراج: احصره في نحو عملية واحدة في الثانية للحصول على أفضل أداء

الوثائق ذات الصلة

• مفتاح التقسيم المخصص

​

مرجع سريع

المشكلة	كيفية الاكتشاف	الحل
مساحة القرص	تحقّق من إجمالي عدد البايتات في system.parts	راقب الاستخدام وخطّط للتوسعة
عدد كبير جدًا من الأجزاء	احسب عدد الأجزاء لكل جدول	إدراج البيانات على دفعات، وفعّل async_insert
تأخر النسخ المتماثل	تحقّق من مقدار التأخير في system.replicas	راقب الشبكة، وأعد تشغيل النسخ المتماثلة
بيانات غير سليمة	تحقّق من صحة تواريخ الأقسام	طبّق التحقّق من صحة timestamp
عمليات التعديل العالقة	تحقّق من حالة system.mutations	اختبر أولًا على كمية صغيرة من البيانات

​

مصادر الفيديو

• 10 دروس من تشغيل ClickHouse
• عمليات الإدراج غير المتزامنة السريعة والمتوازية والمتسقة في ClickHouse