ALTER TABLE إعدادات الجدول أو بياناته:
لا تُدعَم معظم استعلامات
ALTER TABLE إلا في جداول *MergeTree وMerge وDistributed.ALTER التالية مع طرق العرض:
تُعدِّل عبارات
ALTER التالية الكيانات المرتبطة بالتحكم بالوصول المستند إلى الأدوار:
عمليات التعديل
ALTER التي تهدف إلى تعديل بيانات الجدول بآلية تُسمى “عمليات التعديل”، وأبرزها ALTER TABLE … DELETE وALTER TABLE … UPDATE. وهي عمليات غير متزامنة تُنفَّذ في الخلفية، وتشبه عمليات الدمج في جداول MergeTree، إذ تُنتج إصدارات جديدة “معدَّلة” من الأجزاء.
بالنسبة إلى جداول *MergeTree، تُنفَّذ عمليات التعديل عبر إعادة كتابة أجزاء البيانات بالكامل.
ولا توجد خاصية atomicity — إذ تُستبدل الأجزاء بأجزاء معدَّلة فور جهوزيتها، وسيعرض استعلام SELECT الذي يبدأ تنفيذه أثناء عملية التعديل بيانات من أجزاء عُدِّلت بالفعل إلى جانب بيانات من أجزاء لم تُعدَّل بعد.
تُرتَّب عمليات التعديل ترتيبًا كليًا بحسب ترتيب إنشائها، وتُطبَّق على كل جزء وفق هذا الترتيب. كما توجد علاقة ترتيب جزئي بينها وبين استعلامات INSERT INTO: فالبيانات التي أُدرجت في الجدول قبل إرسال عملية التعديل ستُعدَّل، أما البيانات التي أُدرجت بعد ذلك فلن تُعدَّل. لاحظ أن عمليات التعديل لا تحظر عمليات الإدراج بأي شكل.
يعيد استعلام التعديل النتيجة فور إضافة إدخال عملية التعديل (في حالة الجداول المُكرَّرة إلى ZooKeeper، وفي حالة الجداول غير المُكرَّرة إلى نظام الملفات). وتُنفَّذ عملية التعديل نفسها بشكل غير متزامن باستخدام إعدادات profile الخاصة بالنظام. ولمتابعة تقدّم عمليات التعديل، يمكنك استخدام جدول system.mutations. وستستمر عملية التعديل التي أُرسلت بنجاح في التنفيذ حتى لو أُعيد تشغيل خوادم ClickHouse. ولا توجد طريقة للتراجع عن عملية التعديل بعد إرسالها، ولكن إذا توقفت لسبب ما، فيمكن إلغاؤها باستخدام استعلام KILL MUTATION.
لا تُحذف إدخالات عمليات التعديل المكتملة فورًا (ويُحدَّد عدد الإدخالات المحفوظة بواسطة المَعلمة finished_mutations_to_keep الخاصة بمحرك التخزين). وتُحذف إدخالات عمليات التعديل الأقدم.
تزامن استعلامات ALTER
ALTER بشكل متزامن. أما بالنسبة إلى الجداول المكررة، فلا يضيف الاستعلام سوى تعليمات بالإجراءات المناسبة إلى ZooKeeper، بينما تُنفَّذ هذه الإجراءات نفسها في أقرب وقت ممكن. ومع ذلك، يمكن أن ينتظر الاستعلام حتى تكتمل هذه الإجراءات على جميع النسخ المتماثلة.
بالنسبة إلى استعلامات ALTER التي تُنشئ عمليات التعديل (مثل UPDATE وDELETE وMATERIALIZE INDEX وMATERIALIZE PROJECTION وMATERIALIZE COLUMN وAPPLY DELETED MASK وAPPLY PATCHES وCLEAR STATISTIC وMATERIALIZE STATISTIC، على سبيل المثال لا الحصر)، فإن التزامن يحدده الإعداد mutations_sync.
أما استعلامات ALTER الأخرى التي لا تعدّل سوى البيانات الوصفية، فيمكنك استخدام الإعداد alter_sync لضبط الانتظار.
يمكنك تحديد مدة الانتظار (بالثواني) حتى تنفّذ النسخ المتماثلة غير النشطة جميع استعلامات ALTER باستخدام الإعداد replication_wait_for_inactive_replica_timeout.
بالنسبة إلى جميع استعلامات
ALTER، إذا كانت قيمة alter_sync = 2 وكانت بعض النسخ المتماثلة غير نشطة لمدة تتجاوز الوقت المحدد في الإعداد replication_wait_for_inactive_replica_timeout، فسيتم طرح الاستثناء UNFINISHED.إسناد ALTER متزامن لجدول واحد
ALTER منفصلة إلى الجدول نفسه على التوالي وبسرعة إلى الفشل بالخطأ CANNOT_ASSIGN_ALTER (الرمز 517). يحدث ذلك في المسار المنسوخ عندما لا تكون النسخة المتماثلة قد طبّقت بعض عمليات ALTER السابقة بعد (أي إن إصدار البيانات الوصفية لا يزال متأخرًا عن البيانات الوصفية المشتركة؛ وقد يذكر الخادم أن النسخة المتماثلة “still not applied some of previous alters” أو “Probably too many alters executing concurrently”). وقد تظل هذه الحالة قائمة حتى بعد إسناد عملية ALTER سابقة بالفعل. هذه حالة عامة لعمليات ALTER المتزامنة للبيانات الوصفية / عمليات التعديل، وليست مقتصرة على العبارات الخاصة بعمليات التعديل. ويمكن لعمليات تعديل البيانات الوصفية المتزامنة العادية (ADD / DROP / MODIFY وما شابهها) أن تؤدي إلى الرمز نفسه القابل لإعادة المحاولة (انظر، على سبيل المثال، مسار إعادة المحاولة الذي يغطيه tests/queries/0_stateless/03518_alter_logical_race.sh).
الأساليب التي تتجنب حالة السباق:
- ادمج عمليات البيانات الوصفية المستقلة في عبارة
ALTERواحدة متعددة البنود، عندما تسمح القواعد بذلك (على سبيل المثال، عدة بنودADD INDEX). - نفّذ عبارات
ALTERتسلسليًا وأعِد المحاولة عند ظهور الرمز 517 إلى أن تُطبَّق عملياتALTERالسابقة على النسخة المتماثلة. - بالنسبة إلى عمليات
ALTERالتي تُنتج عمليات التعديل، انتظر حتى تنتهي عملية التعديل السابقة باستخدام مؤشر موثق قابل للرصد، مثلmutations_syncأوis_doneفيsystem.mutations، قبل إرسال العملية التالية.
دمج بنود MATERIALIZE INDEX
MATERIALIZE INDEX ضمن تعليمة ALTER واحدة. الحالة التي يغطيها الاختبار ضمن الشجرة هي تجميع عدة بنود ADD INDEX مع MATERIALIZE INDEX للفهارس الجديدة نفسها في تعليمة واحدة (راجع tests/queries/0_stateless/02911_add_index_and_materialize_index.sql). يجمع هذا الشكل المدمج، ADD INDEX + MATERIALIZE INDEX، بين مقطع AlterCommand ومقطع MutationCommand، لذا يرفضه DatabaseReplicated بالخطأ QUERY_IS_PROHIBITED (InterpreterAlterQuery::validateReplicatedDatabaseSegments). اعتبر المثال 02911 صالحًا لقواعد البيانات العادية (غير DatabaseReplicated)؛ أما في DatabaseReplicated، فاجعل تغييرات البيانات الوصفية وعمليات التعديل الخاصة بـ materialize في عبارات منفصلة.
في التنفيذ الحالي، يُحلّ كل بند MATERIALIZE INDEX بالرجوع إلى لقطة البيانات الوصفية للجدول عند تحضير عملية التعديل، لذلك تتبع الصيغ متعددة البنود التي تقتصر على materialize للفهارس الموجودة مسبقًا مسار التحضير نفسه (لعملية التعديل فقط، ومن ثم تبقى ضمن مقطع واحد). لا يوجد بعد اختبار عديم الحالة ومركّز يغطي هذا الشكل تحديدًا؛ لذا اعتبره سلوكًا للتنفيذ الحالي، وليس ضمانًا مستقلًا، إلى أن تتوفر هذه التغطية.
إذا كنت بحاجة إلى تطبيق عمليات التعديل بالترتيب، فلا يزال بإمكانك إصدار MATERIALIZE INDEX واحدة في كل عبارة والانتظار باستخدام mutations_sync.