Skip to main content
تُزيل عبارة DELETE الخفيفة الصفوف من الجدول [db.]table التي تطابق التعبير expr. ولا تتوفر إلا لعائلة محركات جداول *MergeTree.
يُسمّى “الحذف DELETE الخفيف” تمييزًا له عن الأمر ALTER TABLE … DELETE، الذي يُعد عملية ثقيلة.

​
أمثلة

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

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

​
اختر وضع الحذف

يحدد الإعداد lightweight_delete_mode ما إذا كان الحذف سيُنفَّذ عبر التعديلات (الوضع الافتراضي) أم عبر تحديثات خفيفة الوزن تكتب أجزاء تصحيح تحتوي على _row_exists = 0 للصفوف المحذوفة. وتُطبَّق هذه التصحيحات عند تنفيذ الاستعلامات، قبل إزالة البيانات فعليًا. راجع مرجع الإعداد للاطلاع على الأوضاع المتاحة، ومتطلبات التحديث الخفيف الوزن للاطلاع على المتطلبات المسبقة. عند استخدام أجزاء التصحيح، لا ينتظر lightweight_deletes_sync النسخ المتماثلة الأخرى؛ وفي ReplicatedMergeTree، قد تستمر النسخ المتماثلة الأخرى في إرجاع الصفوف المحذوفة إلى أن تتلقى التصحيح.

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

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

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

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

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

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

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

​
أذونات DELETE

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

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

  1. يُطبَّق “قناع” على الصفوف المتأثرة عند تنفيذ استعلام DELETE FROM table ...، يحفظ ClickHouse قناعًا تُوسَم فيه كل صفٍّ إما بأنه “موجود” أو “محذوف”. وتُستبعَد هذه الصفوف “المحذوفة” من الاستعلامات اللاحقة. ومع ذلك، لا تُزال الصفوف فعليًا إلا لاحقًا، عادةً أثناء عمليات الدمج في الخلفية. وتكون كتابة هذا القناع أخف بكثير مما يجري في استعلام ALTER TABLE ... DELETE. يُنفَّذ هذا القناع على شكل عمود نظامي مخفي باسم _row_exists يخزّن True لجميع الصفوف المرئية وFalse للصفوف المحذوفة. ولا يظهر هذا العمود في الجزء إلا إذا كانت بعض الصفوف في ذلك الجزء قد حُذفت. ولا يوجد هذا العمود عندما تكون جميع القيم في الجزء مساوية لـ True.
  2. تُحوَّل استعلامات SELECT لتتضمن القناع عند استخدام عمود مشمول بالقناع في استعلام، فإن استعلام SELECT ... FROM table WHERE condition يُوسَّع داخليًا بإضافة شرط على _row_exists ويُحوَّل إلى:
    وعند التنفيذ، يُقرأ العمود _row_exists لتحديد الصفوف التي يجب عدم إرجاعها. وإذا كان هناك عدد كبير من الصفوف المحذوفة، يمكن لـ ClickHouse تحديد الحبيبات التي يمكن تخطيها بالكامل عند قراءة بقية الأعمدة.
  3. تُحدِّث استعلامات DELETE القناع وفق الوضع المحدد عند استخدام أجزاء التصحيح، يُترجم DELETE FROM table WHERE condition إلى UPDATE table SET _row_exists = 0 WHERE condition. وتخزّن أجزاء التصحيح الناتجة تغييرات القناع للصفوف المحذوفة، وتُطبَّق هذه التغييرات عند قراءة البيانات ودمجها. في وضع alter_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 التقليدي، لأنه لا يعيد كتابة ملفات جميع الأعمدة للأجزاء المتأثرة.

​
محتوى ذو صلة