الانتقال إلى المحتوى الرئيسي
تشير طفرات الحذف إلى استعلامات ALTER التي تعدّل بيانات الجدول عبر الحذف. وأشهرها استعلامات مثل ALTER TABLE DELETE وغيرها. ويؤدي تنفيذ مثل هذه الاستعلامات إلى إنشاء إصدارات مُطفَّرة جديدة من أجزاء البيانات. وهذا يعني أن مثل هذه العبارات ستؤدي إلى إعادة كتابة أجزاء البيانات بالكامل لكل البيانات التي أُدرجت قبل الطفرة، ما يترتب عليه عدد كبير من طلبات الكتابة.
في عمليات الحذف، يمكنك تجنب هذا العدد الكبير من طلبات الكتابة باستخدام محركات جداول متخصصة مثل ReplacingMergeTree أو CollapsingMergeTree بدلًا من محرك جدول MergeTree الافتراضي.
تُزيل عبارة DELETE الخفيفة الصفوف من الجدول [db.]table التي تطابق التعبير expr. ولا تتوفر إلا لعائلة محركات جداول *MergeTree. 
DELETE FROM [db.]table [ON CLUSTER cluster] [IN PARTITION partition_expr] WHERE expr;
يُسمّى “الحذف DELETE الخفيف” تمييزًا له عن الأمر ALTER TABLE … DELETE، الذي يُعد عملية ثقيلة.

​
أمثلة

-- Deletes all rows from the `hits` table where the `Title` column contains the text `hello`
DELETE FROM hits WHERE Title LIKE '%hello%';

​
لا يحذف DELETE الخفيف البيانات فورًا

يُنَفَّذ DELETE الخفيف باعتباره mutation تضع علامة على الصفوف بأنها محذوفة، لكنها لا تحذفها فعليًا على الفور. بشكل افتراضي، تنتظر عبارات DELETE حتى يكتمل وضع علامة الحذف على الصفوف قبل أن تعود. وقد يستغرق ذلك وقتًا طويلًا إذا كان حجم البيانات كبيرًا. بدلًا من ذلك، يمكنك تشغيله بشكل غير متزامن في الخلفية باستخدام الإعداد lightweight_deletes_sync. وإذا كان هذا الإعداد معطّلًا، فستعود عبارة DELETE فورًا، لكن قد تظل البيانات مرئية للاستعلامات إلى أن تنتهي الـ mutation في الخلفية. لا تحذف الـ mutation الصفوف التي وُضعت عليها علامة الحذف فعليًا؛ إذ لا يحدث ذلك إلا أثناء عملية الدمج التالية. ونتيجة لذلك، قد لا تُحذف البيانات فعليًا من التخزين لفترة غير محددة، وإنما يُكتفى فقط بوضع علامة عليها بأنها محذوفة. إذا كنت بحاجة إلى ضمان حذف بياناتك من التخزين خلال مدة يمكن التنبؤ بها، ففكّر في استخدام إعداد الجدول min_age_to_force_merge_seconds. أو يمكنك استخدام الأمر ALTER TABLE … DELETE. لاحظ أن حذف البيانات باستخدام ALTER TABLE ... DELETE قد يستهلك قدرًا كبيرًا من الموارد لأنه يعيد إنشاء جميع الأجزاء المتأثرة.

​
حذف كميات كبيرة من البيانات

قد يؤثر حذف كميات كبيرة من البيانات سلبًا على أداء ClickHouse. إذا كنت تحاول حذف جميع الصفوف من جدول، ففكّر في استخدام الأمر TRUNCATE TABLE. إذا كنت تتوقع تكرار عمليات الحذف، ففكّر في استخدام مفتاح تقسيم مخصّص. عندها يمكنك استخدام الأمر ALTER TABLE ... DROP PARTITION لإزالة جميع الصفوف المرتبطة بهذا القسم بسرعة.

​
قيود DELETE الخفيف

​
عمليات DELETE الخفيفة مع الإسقاطات

افتراضيًا، لا تعمل DELETE مع الجداول التي تتضمن إسقاطات. والسبب في ذلك أن الصفوف في الإسقاط قد تتأثر بعملية DELETE. لكن يوجد إعداد MergeTree باسم lightweight_mutation_projection_mode لتغيير هذا السلوك.

​
اعتبارات الأداء عند استخدام lightweight DELETE

قد يؤثر حذف كميات كبيرة من البيانات باستخدام عبارة DELETE الخفيف سلبًا على أداء استعلامات SELECT. يمكن أن تؤثر العوامل التالية أيضًا سلبًا على أداء lightweight DELETE:
  • وجود شرط WHERE معقّد في استعلام DELETE.
  • إذا كان طابور عمليات mutation ممتلئًا بالعديد من عمليات mutation الأخرى، فقد يؤدي ذلك إلى مشكلات في الأداء، لأن جميع عمليات mutation على الجدول تُنفَّذ بالتسلسل.
  • يحتوي الجدول المتأثر على عدد كبير جدًا من أجزاء البيانات.
  • وجود كمية كبيرة من البيانات في الأجزاء المضغوطة. في الجزء المضغوط، تُخزَّن جميع الأعمدة في ملف واحد.

​
أذونات DELETE

يتطلب DELETE امتياز ALTER DELETE. لتمكين عبارة DELETE على جدول محدد لمستخدم معيّن، شغّل الأمر التالي: 
GRANT ALTER DELETE ON db.table to username;

​
كيف تعمل عمليات DELETE الخفيفة داخليًا في ClickHouse

  1. يُطبَّق “قناع” على الصفوف المتأثرة عند تنفيذ استعلام DELETE FROM table ...، يحفظ ClickHouse قناعًا تُوسَم فيه كل صفٍّ إما بأنه “موجود” أو “محذوف”. وتُستبعَد هذه الصفوف “المحذوفة” من الاستعلامات اللاحقة. ومع ذلك، لا تُزال الصفوف فعليًا إلا لاحقًا عبر عمليات الدمج اللاحقة. وتكون كتابة هذا القناع أخف بكثير مما يجري في استعلام ALTER TABLE ... DELETE. يُنفَّذ هذا القناع على شكل عمود نظامي مخفي باسم _row_exists يخزّن True لجميع الصفوف المرئية وFalse للصفوف المحذوفة. ولا يظهر هذا العمود في الجزء إلا إذا كانت بعض الصفوف في ذلك الجزء قد حُذفت. ولا يوجد هذا العمود عندما تكون جميع القيم في الجزء مساوية لـ True.
  2. تُحوَّل استعلامات SELECT لتتضمن القناع عند استخدام عمود مشمول بالقناع في استعلام، فإن استعلام SELECT ... FROM table WHERE condition يُوسَّع داخليًا بإضافة شرط على _row_exists ويُحوَّل إلى: 
    SELECT ... FROM table PREWHERE _row_exists WHERE condition
    وعند التنفيذ، يُقرأ العمود _row_exists لتحديد الصفوف التي يجب عدم إرجاعها. وإذا كان هناك عدد كبير من الصفوف المحذوفة، يمكن لـ ClickHouse تحديد الحبيبات التي يمكن تخطيها بالكامل عند قراءة بقية الأعمدة.
  3. تُحوَّل استعلامات DELETE إلى استعلامات ALTER TABLE ... UPDATE يُترجم DELETE FROM table WHERE condition إلى عملية mutation بالشكل ALTER TABLE table UPDATE _row_exists = 0 WHERE condition. داخليًا، تُنفَّذ هذه الـ mutation على خطوتين:
    1. يُنفَّذ الأمر SELECT count() FROM table WHERE condition لكل جزء على حدة لتحديد ما إذا كان الجزء متأثرًا.
    2. استنادًا إلى الأوامر أعلاه، تُطبَّق mutation بعد ذلك على الأجزاء المتأثرة، وتُنشأ hardlinks للأجزاء غير المتأثرة. وفي حالة wide parts، يُحدَّث العمود _row_exists لكل صف، وتُربط ملفات جميع الأعمدة الأخرى عبر hardlink. أما في الأجزاء المضغوطة، فتُعاد كتابة جميع الأعمدة لأنها مخزنة معًا في ملف واحد.
    ومن الخطوات أعلاه، يتضح أن DELETE الخفيف باستخدام أسلوب القناع يحسّن الأداء مقارنةً بـ ALTER TABLE ... DELETE التقليدي، لأنه لا يعيد كتابة ملفات جميع الأعمدة للأجزاء المتأثرة.

​
محتوى ذو صلة

آخر تعديل في ٢٩ يونيو ٢٠٢٦