Skip to main content
التحديث خفيف الوزن لا يزال حاليًا في المرحلة التجريبية. إذا واجهت أي مشكلات، يُرجى فتح issue في مستودع ClickHouse.
تعمل تعليمة UPDATE خفيفة الوزن على تحديث الصفوف في الجدول [db.]table التي تطابق التعبير filter_expr. وسُمّيت “lightweight update” لتمييزها عن استعلام ALTER TABLE ... UPDATE، وهي عملية ثقيلة تعيد كتابة أعمدة كاملة في أجزاء البيانات. وهي متاحة فقط لعائلة محركات الجداول MergeTree.
يجب أن يكون filter_expr من النوع UInt8. يحدّث هذا الاستعلام قيم الأعمدة المحددة إلى قيم التعبيرات المقابلة في الصفوف التي تكون فيها قيمة filter_expr غير صفرية. تُحوَّل القيم إلى نوع العمود باستخدام العامل CAST. لا يُدعم تحديث الأعمدة المستخدمة في حساب المفتاح الأساسي أو مفتاح التقسيم.

أمثلة

التحديثات خفيفة الوزن لا تُحدِّث البيانات على الفور

يُنفَّذ UPDATE خفيف الوزن باستخدام أجزاء التصحيح - وهي نوع خاص من أجزاء البيانات لا يحتوي إلا على الأعمدة والصفوف المحدَّثة. ينشئ UPDATE خفيف الوزن أجزاء تصحيح، لكنه لا يُعدِّل البيانات الأصلية فعليًا في التخزين على الفور. تشبه عملية التحديث استعلام INSERT ... SELECT ...، لكن استعلام UPDATE ينتظر حتى يكتمل إنشاء جزء التصحيح قبل أن يُرجِع النتيجة. تكون القيم المحدَّثة:
  • مرئية فورًا في استعلامات SELECT من خلال تطبيق التصحيحات
  • تُطبَّق فعليًا على التخزين فقط أثناء عمليات الدمج وعمليات mutation اللاحقة
  • تُنظَّف تلقائيًا بمجرد أن تُطبَّق التصحيحات فعليًا على جميع الأجزاء النشطة

متطلبات التحديثات خفيفة الوزن

تدعم التحديثات خفيفة الوزن محركات MergeTree وReplacingMergeTree وCollapsingMergeTree وVersionedCollapsingMergeTree، بالإضافة إلى إصداراتها Replicated وShared. لاستخدام التحديثات خفيفة الوزن، يجب تمكين التجسيد المادي على العمودين _block_number و_block_offset باستخدام إعدادات الجدول enable_block_number_column وenable_block_offset_column.

عمليات الحذف الخفيفة

يمكن تنفيذ استعلام DELETE خفيف الوزن باعتباره UPDATE خفيفًا بدلًا من عملية mutation من نوع ALTER UPDATE. ويُتحكَّم في آلية تنفيذ DELETE خفيف الوزن من خلال الإعداد lightweight_delete_mode.

اعتبارات الأداء

مزايا التحديثات خفيفة الوزن:
  • زمن استجابة التحديث مماثل لزمن استجابة استعلام INSERT ... SELECT ...
  • لا تُكتب سوى الأعمدة والقيم المُحدَّثة، وليس الأعمدة كاملةً في أجزاء البيانات
  • لا حاجة إلى انتظار اكتمال عمليات الدمج/التعديلات الجارية حاليًا، لذلك يكون زمن استجابة التحديث متوقعًا
  • يمكن تنفيذ التحديثات خفيفة الوزن بالتوازي
التأثيرات المحتملة على الأداء:
  • تضيف عبئًا إضافيًا على استعلامات SELECT التي تحتاج إلى تطبيق التصحيحات
  • لن تُستخدم فهارس التخطي للأعمدة في أجزاء البيانات التي توجد عليها تصحيحات يجب تطبيقها. ولن تُستخدم الإسقاطات إذا كانت هناك أجزاء التصحيح في الجدول، بما في ذلك أجزاء البيانات التي لا توجد عليها تصحيحات يجب تطبيقها.
  • قد تؤدي التحديثات الصغيرة المتكررة جدًا إلى ظهور الخطأ “too many parts”. ويُنصح بتجميع عدة تحديثات في استعلام واحد، على سبيل المثال بوضع معرّفات التحديثات في عبارة IN واحدة داخل عبارة WHERE
  • صُممت التحديثات خفيفة الوزن لتحديث عدد صغير من الصفوف (حتى نحو 10% من الجدول). وإذا كنت بحاجة إلى تحديث كمية أكبر، فيُنصح باستخدام ALTER TABLE ... UPDATE mutation

العمليات المتزامنة

لا تنتظر التحديثات خفيفة الوزن اكتمال عمليات الدمج/التعديلات الجارية حاليًا، بخلاف التعديلات الثقيلة. ويُتحكَّم في اتساق التحديثات خفيفة الوزن المتزامنة من خلال الإعدادات update_sequential_consistency وupdate_parallel_mode.

أذونات UPDATE

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

تفاصيل التنفيذ

أجزاء التصحيح هي نفسها الأجزاء العادية، لكنها لا تحتوي إلا على الأعمدة المحدَّثة وأعمدة مفتاح الفرز الخاصة بالجدول وأعمدة النظام التالية:
  • _part - اسم الجزء الأصلي
  • _block_number - رقم block الخاص بالصف في الجزء الأصلي
  • _block_offset - إزاحة block الخاصة بالصف في الجزء الأصلي
  • _data_version - إصدار البيانات المحدَّثة (رقم block المخصَّص لاستعلام UPDATE)
وتساعد أعمدة النظام في العثور على الصفوف في الجزء الأصلي التي يجب تحديثها. وترتبط بـ الأعمدة الافتراضية في الجزء الأصلي، والتي تُضاف عند القراءة إذا كان يلزم تطبيق أجزاء التصحيح. وتُرتَّب أجزاء التصحيح حسب مفتاح الفرز الخاص بالجدول، مع إلحاق العمودين _block_number و _block_offset به. ويعتمد العبء الإضافي للتخزين لكل صف محدَّث على حجم قيم أعمدة مفتاح الفرز. تنتمي أجزاء التصحيح إلى تقسيمات مختلفة عن الجزء الأصلي. ويكون معرّف التقسيم لجزء التصحيح هو patch-<hash of the patch part structure>-<original_partition_id>. لذلك تُخزَّن أجزاء التصحيح ذات الأعمدة المختلفة في تقسيمات مختلفة. فعلى سبيل المثال، ستنشئ ثلاثة تحديثات SET x = 1 WHERE <cond> و SET y = 1 WHERE <cond> و SET x = 1, y = 1 WHERE <cond> ثلاثة أجزاء تصحيح في ثلاثة تقسيمات مختلفة. يمكن دمج أجزاء التصحيح فيما بينها لتقليل عدد التصحيحات المطبَّقة على استعلامات SELECT وتقليل العبء الإضافي. ويستخدم دمج أجزاء التصحيح خوارزمية الدمج الاستبدالية مع _data_version بوصفه version column. لذلك تحتفظ أجزاء التصحيح دائمًا بأحدث إصدار لكل صف محدَّث في الجزء. يُطبَّق جزء التصحيح بدمجه مع جزء البيانات وفقًا لمفتاح الفرز الخاص بالجدول: يُحدَّث الصف إذا كانت قيم أعمدة مفتاح الفرز والعمودين _block_number و _block_offset متساوية في جزء البيانات وجزء التصحيح. يتطلب تطبيق أجزاء التصحيح قراءة أعمدة مفتاح الفرز في جزء البيانات حتى إذا لم يحددها الاستعلام. يقتصر memory usage لتطبيق جزء تصحيح على أكبر نطاق من الصفوف ذات قيم مفتاح الفرز المتساوية.

تنسيق أجزاء التصحيح في العناقيد ذات الإصدارات المختلطة

يتحكم إعداد مستوى الجدول patch_parts_version في تنسيق أجزاء التصحيح التي تُكتب حديثًا. لا تدعم إصدارات ClickHouse الأقدم من 26.8 إلا التنسيق القديم v1، ولا تستطيع قراءة أجزاء التصحيح بالتنسيق الحالي v2 الموضح أعلاه. أثناء ترقية متدرجة من إصدار كهذا، استمر في كتابة التنسيق v1 إلى أن تُرقّى جميع النسخ المتماثلة: عيّن patch_parts_version = 'v1' للجداول التي تستخدم التحديثات خفيفة الوزن، أو عيّن إعداد compatibility إلى الإصدار الذي تُجري الترقية منه. بعد اكتمال الترقية، أزل التجاوز لبدء كتابة أجزاء التصحيح بالتنسيق v2. تظل أجزاء التصحيح بكلا التنسيقين قابلة للقراءة والتطبيق، بغض النظر عن قيمة الإعداد.
آخر تعديل في ١٨ أغسطس ٢٠٢٦