الحالة 1: INSERT إلى قسم واحد، في جدول واحد، من عائلة MergeTree*
- Atomic: تنجح عملية INSERT بالكامل أو تُرفَض بالكامل: فإذا أُرسل تأكيد إلى العميل، فهذا يعني أن جميع الصفوف قد أُدرجت؛ وإذا أُرسل خطأ إلى العميل، فهذا يعني أنه لم يُدرج أي صف.
- Consistent: إذا لم تُنتهك أي قيود على الجدول، فستُدرج جميع الصفوف في عملية INSERT وتنجح العملية؛ وإذا انتُهكت القيود، فلن يُدرج أي صف.
- Isolated: يرى العملاء المتزامنون لقطة متسقة من الجدول — أي حالة الجدول كما كانت قبل محاولة INSERT أو بعد نجاحها؛ ولا تظهر أي حالة جزئية. العملاء داخل معاملة أخرى لديهم snapshot isolation، بينما العملاء خارج المعاملة لديهم مستوى العزل read uncommitted.
- Durable: تُكتَب عملية INSERT الناجحة إلى نظام الملفات قبل الرد على العميل، سواء على replica واحدة أو عدة replicas (ويتحكم في ذلك الإعداد
insert_quorum)، ويمكن لـ ClickHouse أن يطلب من نظام التشغيل مزامنة بيانات نظام الملفات مع وسيط التخزين (ويتحكم في ذلك الإعدادfsync_after_insert). - يمكن تنفيذ INSERT إلى عدة جداول بتعليمة واحدة إذا كانت العروض المادية متضمَّنة (أي تكون عملية INSERT من العميل إلى جدول لديه عروض مادية مرتبطة).
الحالة 2: INSERT في عدة أقسام ضمن جدول واحد من عائلة MergeTree*
- إذا كان الجدول يحتوي على عدد كبير من الأقسام وكان INSERT يشمل عدة أقسام، فإن الإدراج في كل قسم يكون معاملة مستقلة بحد ذاته
الحالة 3: INSERT إلى جدول Distributed واحد من عائلة MergeTree*
- إن عملية INSERT إلى جدول Distributed ليست تعاملية ككل، بينما يكون الإدراج في كل shard تعامليًا
الحالة 4: استخدام جدول Buffer
- عمليات الإدراج في جداول Buffer ليست ذرية ولا معزولة ولا متسقة ولا دائمة
الحالة 5: استخدام async_insert
- تكون خاصية الذرّية مضمونة حتى إذا كان
async_insertمفعّلًا وكانwait_for_async_insertمضبوطًا على 1 (القيمة الافتراضية)، ولكن إذا كانwait_for_async_insertمضبوطًا على 0، فلن تكون خاصية الذرّية مضمونة.
ملاحظات
- تُجمَّع الصفوف التي يُدرجها العميل بأي تنسيق بيانات في كتلة واحدة عندما:
- يكون تنسيق الإدراج قائمًا على الصفوف (مثل CSV وTSV وValues وJSONEachRow وغيرها)، وتحتوي البيانات على أقل من
max_insert_block_sizeصف (~1 000 000 افتراضيًا) أو أقل منmin_chunk_bytes_for_parallel_parsingبايت (10 MB افتراضيًا) عند استخدام التحليل المتوازي (وهو مُمكَّن افتراضيًا) - يكون تنسيق الإدراج قائمًا على الأعمدة (مثل Native وParquet وORC وغيرها)، وتحتوي البيانات على كتلة بيانات واحدة فقط
- يكون تنسيق الإدراج قائمًا على الصفوف (مثل CSV وTSV وValues وJSONEachRow وغيرها)، وتحتوي البيانات على أقل من
- قد يعتمد حجم الكتلة المُدرَجة عمومًا على العديد من الإعدادات (على سبيل المثال:
max_block_sizeوmax_insert_block_sizeوmin_insert_block_size_rowsوmin_insert_block_size_bytesوpreferred_block_size_bytesوغيرها) - إذا لم يتلقَّ العميل ردًا من الخادم، فلن يعرف ما إذا كانت المعاملة قد نجحت، وقد يعيد المعاملة باستخدام خصائص الإدراج exactly-once
- يستخدم ClickHouse داخليًا MVCC مع snapshot isolation للمعاملات المتزامنة
- تظل جميع خصائص ACID متحققة حتى في حالة إيقاف الخادم قسرًا أو تعطّله
- يجب تمكين insert_quorum عبر مناطق AZ مختلفة أو تمكين fsync لضمان متانة عمليات الإدراج في الإعدادات المعتادة
- لا يغطي “الاتساق” في مصطلحات ACID دلالات الأنظمة الموزعة؛ راجع https://jepsen.io/consistency، إذ تتحكم في ذلك إعدادات مختلفة (select_sequential_consistency)
- لا يشمل هذا الشرح ميزة المعاملات الجديدة التي تتيح معاملات كاملة الميزات عبر جداول متعددة وعروض مادية ولعدة عمليات SELECT وغير ذلك. (راجع القسم التالي حول Transactions وCommit وRollback)
المعاملات، وCommit، والتراجع
المتطلبات
- انشر ClickHouse Keeper أو ZooKeeper لتتبّع المعاملات
- قاعدة بيانات atomic فقط (الافتراضي)
- محرك جدول MergeTree غير المُكرَّر فقط
- فعِّل دعم المعاملات Experimental بإضافة هذا الإعداد في
config.d/transactions.xml:
ملاحظات
- هذه ميزة تجريبية، ومن المتوقع أن تطرأ عليها تغييرات.
- إذا حدث استثناء أثناء معاملة، فلا يمكنك تنفيذ
commitللمعاملة. ويشمل ذلك جميع الاستثناءات، بما فيها استثناءاتUNKNOWN_FUNCTIONالناتجة عن الأخطاء الإملائية. - المعاملات المتداخلة غير مدعومة؛ أنهِ المعاملة الحالية وابدأ معاملة جديدة بدلًا من ذلك
الإعدادات
فعّل دعم المعاملات التجريبية
/etc/clickhouse-server/config.d/transactions.xml
التهيئة الأساسية لعقدة واحدة من خادم ClickHouse مع تفعيل ClickHouse Keeper
راجع وثائق النشر للاطلاع على تفاصيل نشر خادم ClickHouse وتوفير النصاب المناسب من عقد ClickHouse Keeper. التهيئة المعروضة هنا مخصّصة لأغراض تجريبية.
/etc/clickhouse-server/config.d/config.xml
مثال
تحقّق من تفعيل المعاملات التجريبية
BEGIN TRANSACTION أو START TRANSACTION ثم ROLLBACK للتأكّد من تفعيل المعاملات التجريبية، ومن تفعيل ClickHouse Keeper أيضًا، إذ يُستخدم لتتبّع المعاملات.
أنشئ جدولًا للاختبار
ابدأ معاملة ثم أدرِج صفًا
يمكنك تنفيذ استعلام على الجدول من داخل معاملة، وسترى أن الصف قد أُدرج رغم أنه لم يُنفَّذ له commit بعد.
التراجع عن المعاملة، ثم الاستعلام من الجدول مرة أخرى
أتمّ المعاملة ثم استعلم من الجدول مرة أخرى
استقصاء المعاملات
system.transactions، لكن انتبه إلى أنه لا يمكنك الاستعلام عن هذا
الجدول من جلسة ضمن معاملة. افتح جلسة clickhouse client ثانية للاستعلام عن هذا الجدول.