DELETE

تزيل عبارة 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 الخفيفة على هيئة 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. لكن يمكن تغيير هذا السلوك باستخدام إعداد MergeTree lightweight_mutation_projection_mode.

قد يؤثر حذف كميات كبيرة من البيانات باستخدام عبارة DELETE الخفيفة سلبًا على أداء استعلامات SELECT.

قد تؤثر العوامل التالية أيضًا سلبًا على أداء عبارة DELETE الخفيفة:

• وجود شرط WHERE معقّد في استعلام DELETE.
• إذا كان صفّ mutations ممتلئًا بعدد كبير من mutations الأخرى، فقد يؤدي ذلك إلى مشكلات في الأداء، لأن جميع mutations على الجدول تُنفَّذ بشكل تسلسلي.
• يحتوي الجدول المتأثر على عدد كبير جدًا من data parts.
• وجود كمية كبيرة من البيانات في compact parts. في compact part، تُخزَّن جميع الأعمدة في file واحد.

يتطلب DELETE امتياز ALTER DELETE. لتمكين عبارات DELETE على جدول محدد لمستخدم معيّن، نفّذ الأمر التالي:

GRANT ALTER DELETE ON db.table to username;

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. استنادًا إلى الأوامر أعلاه، تُطبَّق بعد ذلك mutations على الأجزاء المتأثرة، وتُنشأ hardlinks للأجزاء غير المتأثرة. وفي حالة الأجزاء العريضة، يُحدَّث العمود _row_exists لكل صف، وتُنشأ hardlinks لملفات جميع الأعمدة الأخرى. أما في الأجزاء المدمجة، فتُعاد كتابة جميع الأعمدة لأنها كلها مخزنة معًا في ملف واحد.

   ومن الخطوات أعلاه، يتضح أن DELETE الخفيف باستخدام أسلوب القناع يحسّن الأداء مقارنةً بـ ALTER TABLE ... DELETE التقليدي لأنه لا يعيد كتابة ملفات جميع الأعمدة في الأجزاء المتأثرة.

• المدونة: التعامل مع التحديثات وعمليات الحذف في ClickHouse