في ClickHouse، تشير التعديلات إلى العمليات التي تُعدّل البيانات الموجودة في جدول أو تحذفها—وعادةً ما يتم ذلك باستخدام ALTER TABLE ... DELETE أو ALTER TABLE ... UPDATE. وبينما قد تبدو هذه العبارات مشابهة لعمليات SQL القياسية، فإنها تختلف عنها جذريًا على المستوى الداخلي.
فبدلًا من تعديل الصفوف في موضعها، تكون التعديلات في ClickHouse عمليات غير متزامنة تُنفَّذ في الخلفية وتُعيد كتابة أجزاء البيانات المتأثرة بالتغيير بالكامل. وهذا النهج ضروري بسبب نموذج التخزين غير القابل للتغيير والموجَّه بالأعمدة في ClickHouse، وقد يؤدي إلى استهلاك كبير لـ I/O والموارد.
عند إصدار تعديل، يقوم ClickHouse بجدولة إنشاء أجزاء معدَّلة جديدة، مع ترك الأجزاء الأصلية دون مساس إلى أن تصبح الأجزاء الجديدة جاهزة. وما إن تصبح جاهزة، تحل الأجزاء المعدَّلة محل الأجزاء الأصلية استبدالًا ذريًا. لكن بما أن العملية تعيد كتابة الأجزاء كاملة، فقد يؤدي حتى تغيير طفيف (مثل تحديث صف واحد) إلى عمليات إعادة كتابة واسعة النطاق وتضخيم مفرط في عمليات الكتابة.
وبالنسبة إلى مجموعات البيانات الكبيرة، قد يتسبب ذلك في ارتفاع كبير في I/O على القرص ويؤدي إلى تراجع الأداء العام للعنقود. وعلى خلاف عمليات الدمج، لا يمكن التراجع عن التعديلات بعد إرسالها، وستستمر في التنفيذ حتى بعد إعادة تشغيل الخادوم ما لم تُلغَ صراحةً—راجع KILL MUTATION.
مراقبة عدد التعديلات النشطة أو الموضوعة في قائمة الانتظار في ClickHouseللاطلاع على كيفية مراقبة عدد التعديلات النشطة أو الموضوعة في قائمة الانتظار، ارجع إلى مقالة قاعدة المعرفة التالية. KILL MUTATION إذا علقت عملية ما أو بدأت تتصرف بشكل غير سليم. إن إساءة استخدام التعديلات قد تؤدي إلى تراجع الأداء، واستهلاك تخزين مفرط، واحتمال عدم استقرار الخدمة—لذا استخدمها بحذر وعلى نطاق محدود.
ولحذف البيانات، يمكنك أيضًا النظر في عمليات الحذف الخفيف أو إدارة البيانات من خلال الأقسام، مما يتيح حذف الأجزاء بالكامل بكفاءة. آخر تعديل في ٢٩ يونيو ٢٠٢٦
