Atomic استعلامات DROP TABLE وRENAME TABLE غير الحاجبة، واستعلامات EXCHANGE TABLES الذرّية. ويُستخدم محرك قاعدة البيانات Atomic افتراضيًا في ClickHouse مفتوح المصدر.
في ClickHouse Cloud، يُستخدم أيضًا افتراضيًا محرك قاعدة البيانات
Shared، كما يدعم العمليات المذكورة أعلاه.إنشاء قاعدة بيانات
ENGINE = Atomic، لأنه الخيار الافتراضي. ويمكن أن تتضمّن عبارة SETTINGS إعدادات محرك قاعدة البيانات (مثل disk أو max_tables) وإعدادات الاستعلام العادية معًا؛ إذ يُوجَّه كل اسم إلى الفئة التي ينتمي إليها منهما.
تفاصيل وتوصيات
معرّف UUID للجدول
لكل جدول في قاعدة البياناتAtomic معرّف معرّف UUID دائم، وتُخزَّن بياناته في الدليل التالي:
xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy إلى معرّف UUID الخاص بالجدول.
افتراضيًا، يُنشأ معرّف UUID تلقائيًا. ومع ذلك، يمكن للمستخدمين تحديد معرّف UUID صراحةً عند إنشاء جدول، رغم أن ذلك غير مُوصى به.
على سبيل المثال:
يمكنك استخدام الإعداد show_table_uuid_in_table_create_query_if_not_nil لعرض معرّف UUID عبر استعلام
SHOW CREATE.RENAME TABLE
لا تُعدّل استعلاماتRENAME معرّف UUID ولا تنقل بيانات الجدول. تُنفَّذ هذه الاستعلامات فورًا ولا تنتظر حتى تكتمل الاستعلامات الأخرى التي تستخدم الجدول.
DROP/DETACH TABLE
عند استخدامDROP TABLE، لا تُزال أي بيانات. يكتفي محرّك Atomic بوضع علامة على الجدول على أنه محذوف، وذلك بنقل البيانات الوصفية الخاصة به إلى /clickhouse_path/metadata_dropped/ وإخطار خيط المعالجة في الخلفية. ويُحدَّد التأخير قبل الحذف النهائي لبيانات الجدول بواسطة إعداد database_atomic_delay_before_drop_table_sec.
يمكنك تحديد الوضع المتزامن باستخدام المُعدِّل SYNC. استخدم الإعداد database_atomic_wait_for_drop_and_detach_synchronously لتحقيق ذلك. في هذه الحالة، ينتظر DROP حتى تنتهي استعلامات SELECT وINSERT وغيرها من الاستعلامات الجارية التي تستخدم الجدول. وسيُزال الجدول عندما لا يعود قيد الاستخدام.
EXCHANGE TABLES/DICTIONARIES
يُبدّل استعلامEXCHANGE الجداول أو القواميس تبديلًا ذريًا. على سبيل المثال، بدلًا من هذه العملية غير الذرية:
Non-atomic
Atomic
ReplicatedMergeTree في قاعدة بيانات atomic
بالنسبة إلى جداولReplicatedMergeTree، يُنصح بعدم تحديد معلمات المحرك الخاصة بالمسار في ZooKeeper واسم النسخة المتماثلة. في هذه الحالة، ستُستخدم معلمتا الإعداد default_replica_path وdefault_replica_name. وإذا أردت تحديد معلمات المحرك صراحةً، فيُنصح باستخدام ماكرو {uuid}. وهذا يضمن إنشاء مسارات فريدة تلقائيًا لكل جدول في ZooKeeper.
قرص البيانات الوصفية
عند تحديدdisk في SETTINGS، يُستخدم القرص لتخزين ملفات البيانات الوصفية للجدول.
ويمكن أن يشير إلى قرص مُعرَّف في إعدادات الخادم، أو أن يُعرَّف بشكل مضمّن باستخدام الدالة disk،
تمامًا كما هو الحال مع الجدول المفرد:
database_disk.disk.
تعمل عبارة SETTINGS نفسها مع ATTACH DATABASE، وهي الطريقة التي تُربط بها بالخادم قاعدة بيانات توجد
ملفات البيانات الوصفية الخاصة بها على قرص آخر. ويتطلب Atomic في هذه الحالة تحديد معرّف UUID الخاص
بقاعدة البيانات صراحةً:
تحديد عدد الجداول
يحدّ الإعدادmax_tables عدد الجداول التي يمكن أن تحتويها قاعدة البيانات، والقيمة 0 (وهي الافتراضية) تعني بلا حد. ويُحتسب ضمن هذا الحد كل كائن شبيه بالجدول: الجدول العادي، والـ VIEW، والـ materialized view، والقاموس المُنشأ باستخدام CREATE DICTIONARY. وعند بلوغ الحد، تُطلق العمليات CREATE TABLE وCREATE DICTIONARY وATTACH TABLE استثناء TOO_MANY_TABLES.
ALTER DATABASE:
CREATE OR REPLACE TABLE الجدول البديل لفترة وجيزة باسم مؤقت قبل أن يستبدله بالأصلي، لذا فإن استبدال جدول بينما تكون قاعدة البيانات عند max_tables بالضبط يفشل مع الخطأ TOO_MANY_TABLES رغم أن العدد النهائي للجداول لن يزداد. كما يخضع لهذا الحد نقل كائن إلى قاعدة البيانات باستخدام RENAME TABLE أو RENAME DICTIONARY.
العرض المُجسَّد (materialized view) الذي يُنشأ من دون TO clause يمتلك جدولًا داخليًا مخفيًا يُحتسب ضمن الحد كجدول قائم بذاته.
يُفحص الحد قبل بدء العملية، لذا فهو يعمل على أساس بذل أقصى جهد: إذ يمكن للاستعلامات المتزامنة أن تدفع قاعدة البيانات لتجاوزه قليلًا.
يتوفر هذا الإعداد لمحركات قواعد البيانات العاملة على القرص التي تحتفظ بجداولها في الذاكرة وببياناتها الوصفية في ملفات .sql محلية: Atomic وOrdinary. أما محرك Replicated فلا يدعمه.
انظر أيضًا
- system.databases جدول النظام