ALTER TABLE إعدادات الجدول أو بياناته:
لا تُدعَم معظم استعلامات
ALTER TABLE إلا في جداول *MergeTree وMerge وDistributed.ALTER التالية مع طرق العرض:
تُعدِّل عبارات
ALTER التالية الكيانات المرتبطة بالتحكم بالوصول المستند إلى الأدوار:
دمج عدة إجراءات في عبارة ALTER واحدة
تقبل عبارة ALTER TABLE الواحدة عدة إجراءات مفصولة بفواصل، ما يتيح تنفيذ عمل كان سيُرسَل في العادة على هيئة سلسلة من العبارات ضمن عبارة واحدة فقط:
ALTER، فإن الإعداد الذي يتحكم في هذا الانتظار يتحدد بحسب الإجراء لا بحسب العبارة: فالإجراء الذي يمر بمسار تنفيذ التعديل، مثل MATERIALIZE INDEX، يخضع للإعداد mutations_sync، في حين تخضع إجراءات البيانات الوصفية للإعداد alter_sync، ومن ثَمّ فإن الجمع بينهما في عبارة واحدة لا يجعلهما خاضعين لإعداد واحد. راجع تزامن استعلامات ALTER لمعرفة الإجراءات التي يغطيها كل إعداد، والجمع بين عبارات MATERIALIZE INDEX للاطلاع على القيد المفروض على مثل هذه العبارة المختلطة في قاعدة بيانات Replicated.
عمليات التعديل
تُنفَّذ استعلامات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 TABLE، ميّز بين تغيير البيانات الوصفية والعمل المطلوب على أجزاء البيانات الموجودة. ويتوقف انتظار العميل لاكتمال العملية على نوعها: إذ يتحكم alter_sync في عمليات البيانات الوصفية وفي MODIFY COLUMN، بما في ذلك تحويلات الأنواع التي تعيد كتابة البيانات؛ بينما يتحكم mutations_sync في عمليات التعديل التي تجري في الخلفية مثل UPDATE وDELETE وMATERIALIZE .... لا تعتمد على مُدد ثابتة مرجعًا تشغيليًا، فالتكلفة تتوقف على حجم البيانات الوصفية، وأجزاء البيانات والبايتات المتأثرة، وتكلفة التحويل، والحمل الحالي في الخلفية.
تزامن استعلامات ALTER
افتراضيًا، تنتظر استعلامات ALTER على الجداول غير المكررة حتى يكتمل عملها. ومع alter_sync = 0، يمكن لاستعلام ALTER الذي يؤدي عملًا في الخلفية أن يعيد النتيجة قبل انتهاء ذلك العمل. أما بالنسبة إلى الجداول المكررة، فيضيف الاستعلام تعليمات بالإجراءات المناسبة إلى ZooKeeper، بينما تُنفَّذ هذه الإجراءات نفسها في أقرب وقت ممكن. ويمكن أن ينتظر الاستعلام حتى تكتمل هذه الإجراءات على جميع النسخ المتماثلة.
بالنسبة إلى استعلامات ALTER التي تُنشئ عمليات التعديل عبر مسار تنفيذ التعديلات (مثل UPDATE وDELETE وMATERIALIZE INDEX وMATERIALIZE PROJECTION وMATERIALIZE COLUMN وAPPLY DELETED MASK وAPPLY PATCHES وCLEAR STATISTIC وMATERIALIZE STATISTIC، على سبيل المثال لا الحصر)، فإن التزامن يحدده الإعداد mutations_sync.
أما استعلامات ALTER الأخرى، بما في ذلك عمليات إعادة الكتابة الناتجة عن MODIFY COLUMN، فيتحكم الإعداد alter_sync في انتظارها.
يمكنك تحديد مدة الانتظار (بالثواني) حتى تنفّذ النسخ المتماثلة غير النشطة جميع استعلامات ALTER باستخدام الإعداد replication_wait_for_inactive_replica_timeout.
بالنسبة إلى جميع استعلامات
ALTER، إذا كانت قيمة alter_sync = 2 وكانت بعض النسخ المتماثلة غير نشطة لمدة تتجاوز الوقت المحدد في الإعداد replication_wait_for_inactive_replica_timeout، فسيتم طرح الاستثناء UNFINISHED. مع alter_sync = 3، لا يتم انتظار النسخ المتماثلة غير النشطة، لذا لا يُطرح أي استثناء.إسناد 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واحدة. - نفّذ عبارات
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.