إعدادات جداول MergeTree الأخرى

إعدادات جداول MergeTree في ClickHouse ضمن مجموعة Other المُولَّدة.

هذه الإعدادات متاحة في system.merge_tree_settings، وهي مُولَّدة تلقائيًا من الشيفرة المصدرية لـ ClickHouse.

​

adaptive_write_buffer_initial_size

الحجم الأولي لمخزن مؤقت للكتابة التكيفية

​

add_implicit_sign_column_constraint_for_collapsing_engine

إذا كانت القيمة true، فسيُضاف قيد ضمني إلى العمود sign في جدول من نوع CollapsingMergeTree أو VersionedCollapsingMergeTree، بحيث لا يُسمح إلا بالقيم الصالحة (1 و -1).

​

alter_column_secondary_index_mode

يُحدِّد ما إذا كان ينبغي السماح بأوامر ALTER التي تُعدِّل الأعمدة المشمولة بفهارس ثانوية، وما الإجراء الذي يجب اتخاذه إذا كان ذلك مسموحًا. بشكل افتراضي، يُسمح بأوامر ALTER هذه وتُعاد بناء الفهارس.

القيم الممكنة:

• rebuild (الافتراضي): يعيد بناء أي فهارس ثانوية تتأثر بالعمود في أمر ALTER.
• throw: يمنع أي ALTER للأعمدة المشمولة بفهارس ثانوية صريحة عن طريق رفع استثناء. ولا يشمل هذا القيد الفهارس الضمنية، إذ ستُعاد بناؤها.
• drop: يحذف الفهارس الثانوية التابعة. ولن تحتوي الأجزاء الجديدة على هذه الفهارس، مما يتطلب MATERIALIZE INDEX لإعادة إنشائها.
• compatibility: يطابق السلوك الأصلي: throw مع ALTER ... MODIFY COLUMN وrebuild مع ALTER ... UPDATE/DELETE.
• ignore: مخصص لاستخدام الخبراء. سيترك الفهارس في حالة غير متسقة، مما قد يؤدي إلى نتائج استعلام غير صحيحة.

​

always_use_copy_instead_of_hardlinks

انسخ البيانات دائمًا بدلًا من إنشاء روابط صلبة أثناء عمليات تعديل/Replace/detach وما إلى ذلك.

​

apply_patches_on_merge

إذا كانت القيمة true، فسيتم تطبيق أجزاء التصحيح أثناء عمليات الدمج

​

assign_part_uuids

عند التفعيل، سيُخصَّص معرّف جزء فريد لكل جزء جديد. قبل التفعيل، تحقّق من أن جميع النسخ المتماثلة تدعم الإصدار 4 من UUID.

​

auto_statistics_types

قائمة مفصولة بفواصل لأنواع الإحصاءات التي تُحسب تلقائيًا لجميع الأعمدة المناسبة. أنواع الإحصاءات المدعومة: basic و tdigest و countmin و uniq و uniq_v2. نوع الإحصاءات minmax مُهمَل: فهو مجموعة فرعية من basic، لذا ينبغي استخدام basic بدلًا منه.

​

background_task_preferred_step_execution_time_ms

الوقت المستهدف لتنفيذ خطوة واحدة من عملية الدمج أو التعديل. يمكن تجاوزه إذا استغرقت إحدى الخطوات وقتًا أطول

​

clean_deleted_rows

إعداد متقادم، بلا أي تأثير.

​

clone_replica_zookeeper_create_get_part_batch_size

حجم الدفعة لطلبات get-part متعددة الإنشاء في ZooKeeper عند استنساخ النسخة المتماثلة.

​

compatibility_allow_sampling_expression_not_in_primary_key

يسمح بإنشاء جدول لا يكون تعبير أخذ العينات فيه ضمن المفتاح الأساسي. وهذا مطلوب فقط للسماح مؤقتًا بتشغيل الخادم مع جداول غير صحيحة حفاظًا على التوافق مع الإصدارات السابقة.

​

compute_exact_num_defaults_for_sparse_columns

احسب العدد الدقيق للقيم الافتراضية لكل عمود أثناء عمليات إدراج و الدمج، بدلًا من تقدير sampling الأقل تكلفة والمستخدَم لاتخاذ قرار تسلسل لـ متناثر. هذا الإعداد مطلوب بواسطة optimize_trivial_count_with_sparsity_filter، الذي يستخدم العداد المحفوظ num_defaults (كما تتطلب أعمدة Nullable أيضًا nullable_serialization_version = 'allow_sparse'). يؤدي تركه معطّلًا إلى الإبقاء على سرعة عمليات إدراج/الدمج كما كانت سابقًا؛ أما تفعيله فيضيف مرورًا بتعقيد O(rows) لكل عمود مؤهَّل لـ متناثر.

​

deduplicate_merge_projection_mode

يحدد ما إذا كان يُسمح بإنشاء إسقاط للجدول الذي يستخدم MergeTree غير الكلاسيكي، أي الذي لا يندرج ضمن MergeTree من النوعين (Replicated, Shared). خيار ignore مخصص فقط للتوافق، وقد يؤدي إلى نتائج غير صحيحة. بخلاف ذلك، إذا كان ذلك مسموحًا، فإنه يحدد الإجراء المتخذ عند merge للإسقاطات: إما drop أو rebuild. لذلك فإن MergeTree الكلاسيكي يتجاهل هذا الإعداد. كما أنه يتحكم أيضًا في OPTIMIZE DEDUPLICATE، لكن تأثيره يمتد إلى جميع أعضاء MergeTree family. وعلى غرار الخيار lightweight_mutation_projection_mode، فهو أيضًا على مستوى part.

القيم الممكنة:

• ignore
• throw
• drop
• rebuild

​

deduplication_hashes_cache_update_wait_ms

المدة التي تنتظرها كل عملية تكرار للإدراج حتى يتم تحديث ذاكرة التخزين المؤقت deduplication_hashes الموجودة في الذاكرة إلى إصدار أحدث قبل إعادة التحقق منها بحثًا عن الكتل التي أُدرجت بالفعل. تعكس ذاكرة التخزين المؤقت الدليل deduplication_hashes في ClickHouse Keeper، بحيث تتمكن عمليات الإدراج من اكتشاف التكرارات دون الحاجة إلى رحلة ذهاب وإياب إلى Keeper.

​

default_compression_codec

يحدّد مرمّز الضغط الافتراضي الذي يُستخدم إذا لم يُعرَّف أي مرمّز لعمود معيّن في تعريف الجدول. ترتيب اختيار مرمّز الضغط لعمود ما:

1. مرمّز الضغط المعرَّف للعمود في تعريف الجدول
2. مرمّز الضغط المعرَّف في default_compression_codec (هذا الإعداد)
3. مرمّز الضغط الافتراضي المعرَّف في إعدادات compression القيمة الافتراضية: سلسلة فارغة (غير معرَّفة).

​

القرص

اسم قرص التخزين. يمكن تحديده بدلًا من سياسة التخزين.

​

dynamic_serialization_version

إصدار التسلسل لنوع البيانات Dynamic. مطلوب لضمان التوافق.

القيم الممكنة:

• v1
• v2
• v3

​

enforce_index_structure_match_on_partition_manipulation

إذا كان هذا الإعداد مُمكّنًا لجدول الوجهة في استعلام لمعالجة قسم (ATTACH/MOVE/REPLACE PARTITION)، فيجب أن تكون الفهارس والإسقاطات متطابقة بين جدولَي المصدر والوجهة. وإلا، يمكن أن يشتمل جدول الوجهة على فهارس وإسقاطات أكثر من تلك الموجودة في جدول المصدر.

​

execute_merges_on_single_replica_time_threshold

عندما تكون قيمة هذا الإعداد أكبر من صفر، تبدأ نسخة متماثلة واحدة فقط عملية الدمج فورًا، بينما تنتظر النسخ المتماثلة الأخرى حتى هذه المدة لتنزيل النتيجة بدلًا من إجراء عمليات الدمج محليًا. وإذا لم تُنهِ النسخة المتماثلة المختارة عملية الدمج خلال هذه المدة، يتم الرجوع إلى السلوك القياسي.

القيم الممكنة:

• أي عدد صحيح موجب.

​

finished_mutations_to_keep

عدد السجلات الخاصة بعمليات التعديل المكتملة المطلوب الاحتفاظ بها. إذا كانت القيمة صفرًا، فسيتم الاحتفاظ بها كلها.

​

force_read_through_cache_for_merges

فرض القراءة عبر ذاكرة التخزين المؤقت لنظام الملفات أثناء عمليات الدمج

​

initialization_retry_period

فترة إعادة المحاولة لتهيئة الجدول، بالثواني.

​

kill_threads

إعداد متقادم، ولا تأثير له.

​

lightweight_mutation_projection_mode

افتراضيًا، لا يعمل الحذف الخفيف DELETE مع الجداول التي تحتوي على إسقاطات. ويعود ذلك إلى أن الصفوف في الإسقاط قد تتأثر بعملية DELETE. لذا تكون القيمة الافتراضية هي throw. ومع ذلك، يمكن لهذا الخيار تغيير هذا السلوك. عند ضبط القيمة على drop أو rebuild، سيعمل الحذف مع الإسقاطات. تؤدي القيمة drop إلى حذف الإسقاط، لذلك قد يكون ذلك سريعًا في الاستعلام الحالي لأن الإسقاط سيُحذف، لكنه قد يكون أبطأ في الاستعلامات المستقبلية لعدم وجود أي إسقاط مرفق. أما rebuild فسيؤدي إلى إعادة بناء الإسقاط، مما قد يؤثر في أداء الاستعلام الحالي، لكنه قد يسرّع الاستعلامات المستقبلية. ومن مزايا هذه الخيارات أنها تعمل فقط على مستوى الجزء، ما يعني أن الإسقاطات الموجودة في الجزء الذي لا يتأثر ستبقى سليمة بدلًا من أن تؤدي إلى أي إجراء مثل الحذف أو إعادة البناء.

القيم الممكنة:

• throw
• drop
• rebuild

​

load_existing_rows_count_for_old_parts

إذا كان هذا الإعداد مفعّلًا مع exclude_deleted_rows_for_part_size_in_merge، فسيُحتسب عدد الصفوف المحذوفة لأجزاء البيانات الموجودة عند بدء تشغيل الجدول. لاحظ أن ذلك قد يبطئ تحميل الجدول عند بدء التشغيل.

القيم الممكنة:

• true
• false

انظر أيضًا

• الإعداد exclude_deleted_rows_for_part_size_in_merge

​

lock_acquire_timeout_for_background_operations

لعمليات الخلفية مثل عمليات الدمج وعمليات التعديل وما إلى ذلك، يحدِّد عدد الثواني قبل الفشل في الحصول على أقفال الجدول.

​

mutation_workload

يُستخدم لتنظيم كيفية استخدام الموارد وتوزيعها بين عمليات التعديل وأعباء العمل الأخرى. وتُستخدم القيمة المحددة بوصفها قيمة إعداد workload لعمليات التعديل التي تعمل في الخلفية لهذا الجدول. وإذا لم تُحدَّد (كسلسلة فارغة)، فسيُستخدم بدلًا منها إعداد الخادم mutation_workload.

انظر أيضًا

• جدولة أعباء العمل

​

non_replicated_deduplication_window

عدد أحدث blocks المُدخلة في جدول MergeTree غير المكرَّر التي تُحفَظ لها قيم hash sums للتحقق من التكرارات.

القيم الممكنة:

• أي عدد صحيح موجب.
• 0 (تعطيل deduplication).

تُستخدم آلية deduplication مشابهة لتلك المستخدمة في الجداول المكرَّرة (راجع الإعداد replicated_deduplication_window): إذ يشمل hash sum الخاص بـ deduplication كامل inserted block. وتُكتَب قيم hash sums إلى ملف محلي على قرص بدلًا من ClickHouse Keeper.

​

notify_newest_block_number

إبلاغ SharedJoin أو SharedSet بأحدث رقم block. في ClickHouse Cloud فقط.

​

nullable_serialization_version

يتحكم في أسلوب التسلسل المستخدم لأعمدة Nullable(T).

القيم الممكنة:

• basic — استخدم أسلوب التسلسل القياسي لـ Nullable(T).

• allow_sparse — السماح لـ Nullable(T) باستخدام الترميز المتناثر.

​

object_serialization_version

إصدار التسلسل لنوع بيانات JSON. وهو مطلوب للتوافق.

القيم الممكنة:

• v1
• v2
• v3

لا يدعم تغيير إصدار تسلسل البيانات المشتركة إلا الإصدار v3.

​

old_parts_lifetime

المدة (بالثواني) التي تُحفَظ خلالها الأجزاء غير النشطة للحماية من فقدان البيانات أثناء إعادة تشغيل الخادوم بشكل مفاجئ.

القيم الممكنة:

• أي عدد صحيح موجب.

بعد دمج عدة أجزاء في جزء جديد، يضع ClickHouse علامة على الأجزاء الأصلية على أنها غير نشطة، ولا يحذفها إلا بعد مرور old_parts_lifetime ثانية. وتُزال الأجزاء غير النشطة إذا لم تكن مستخدمة في الاستعلامات الحالية، أي إذا كانت قيمة refcount للجزء تساوي 1.

لا يُستدعى fsync للأجزاء الجديدة، لذلك تبقى هذه الأجزاء لبعض الوقت موجودة فقط في ذاكرة RAM الخاصة بالخادوم (ذاكرة التخزين المؤقت لنظام التشغيل). وإذا أُعيد تشغيل الخادوم بشكل مفاجئ، فقد تُفقَد الأجزاء الجديدة أو تتلف. لذلك، لا تُحذف الأجزاء غير النشطة فورًا حمايةً للبيانات.

أثناء بدء التشغيل، يتحقق ClickHouse من سلامة الأجزاء. فإذا كان الجزء المُدمَج تالفًا، يعيد ClickHouse الأجزاء غير النشطة إلى القائمة النشطة، ثم يدمجها مرة أخرى لاحقًا. بعد ذلك، يُعاد تسمية الجزء التالف (تُضاف البادئة broken_) ويُنقل إلى المجلد detached. أما إذا لم يكن الجزء المُدمَج تالفًا، فتُعاد تسمية الأجزاء الأصلية غير النشطة (تُضاف البادئة ignored_) وتُنقل إلى المجلد detached.

القيمة الافتراضية لـ dirty_expire_centisecs (وهو إعداد في نواة Linux) هي 30 ثانية (وهي الحد الأقصى للمدة التي تُخزَّن خلالها البيانات المكتوبة في ذاكرة RAM فقط)، ولكن عند وجود أحمال كثيفة على نظام القرص، قد تُكتَب البيانات بعد ذلك بوقت أطول بكثير. وقد اختيرت تجريبيًا قيمة 480 ثانية لـ old_parts_lifetime، وهي مدة يُضمَن خلالها كتابة الجزء الجديد إلى القرص.

​

optimize_row_order

يتحكم هذا الإعداد في ما إذا كان ينبغي تحسين ترتيب الصفوف أثناء عمليات الإدراج لتحسين قابلية ضغط جزء الجدول المُدرج حديثًا.

لا يكون له تأثير إلا على جداول MergeTree-engine العادية. ولا يفعل شيئًا مع جداول محرك MergeTree المتخصصة (مثل CollapsingMergeTree).

تُضغط جداول MergeTree (اختياريًا) باستخدام ترميزات الضغط. وتحقق ترميزات الضغط العامة مثل LZ4 و ZSTD أعلى معدلات ضغط إذا كانت البيانات تُظهر أنماطًا. وعادةً ما تُضغط السلاسل الطويلة من القيمة نفسها بكفاءة عالية جدًا.

إذا كان هذا الإعداد مُمكّنًا، يحاول ClickHouse تخزين البيانات في الأجزاء المُدرجة حديثًا بترتيب صفوف يقلل عدد السلاسل ذات القيم المتساوية عبر أعمدة جزء الجدول الجديد. وبعبارة أخرى، فإن قلة عدد السلاسل ذات القيم المتساوية تعني أن كل سلسلة تكون طويلة وتُضغط جيدًا.

العثور على الترتيب الأمثل للصفوف غير ممكن عمليًا من الناحية الحسابية (NP hard). لذلك، يستخدم ClickHouse آلية استدلالية للعثور بسرعة على ترتيب صفوف يُحسّن معدلات الضغط مقارنة بترتيب الصفوف الأصلي.

إذا كان هذا الإعداد مُمكّنًا، فإن عمليات الإدراج تتحمل كلفة إضافية على CPU لتحليل ترتيب صفوف البيانات الجديدة وتحسينه. ومن المتوقع أن تستغرق عمليات INSERT وقتًا أطول بنسبة 30-50% تبعًا لخصائص البيانات. وتتحسن معدلات ضغط LZ4 أو ZSTD بمتوسط يتراوح بين 20-40%.

يعمل هذا الإعداد على أفضل وجه مع الجداول التي لا تحتوي على مفتاح أساسي أو التي تحتوي على مفتاح أساسي منخفض الكاردينالية، أي جدول لا يحتوي إلا على عدد قليل من قيم المفتاح الأساسي المميزة. ولا يُتوقع أن تستفيد المفاتيح الأساسية عالية الكاردينالية، مثل تلك التي تتضمن أعمدة طابع زمني من النوع DateTime64، من هذا الإعداد.

​

packed_skip_index_max_bytes

الحدّ (بالبايتات المتسلسلة على القرص، أي بعد ضغط التدفق الفرعي وسلسلة التجزئة) الذي إذا كان تدفق فرعي لفهرس التخطي دونه، فسيُجمَّع داخل أرشيف skp_idx.packed واحد لكل جزء بدلًا من كتابته في ملف skp_idx_<name>.idx2 / .mrk2 منفصل. أما التدفقات الفرعية الأكبر من ذلك فتبقى في التخطيط القديم القائم على ملف لكل تدفق. ويُتخذ القرار بشكل مستقل لكل تدفق فرعي وقت الكتابة، لذلك يمكن أن يحتوي جزء واحد على فهارس صغيرة (مثل minmax) مُجمَّعة، وأخرى كبيرة (مثل bloom_filter ثقيل) في ملفات منفصلة. اضبط القيمة على 0 لتعطيل التجميع بالكامل. القيمة الافتراضية هي 1 MiB، مما يجمع فهارس التخطي الصغيرة عادةً في أرشيف واحد لكل جزء ويقلل عدد الكائنات (وطلبات القراءة) على تخزين الكائنات، مع إبقاء التدفقات الفرعية الكبيرة فعلًا في تخطيط الملف لكل تدفق.

يتكوّن كل تدفق فرعي لفهرس التخطي فعليًا من ملف بيانات وملف علامات؛ ويُخزَّن كلاهما مؤقتًا في الذاكرة حتى بلوغ الحدّ قبل اتخاذ قرار spill. لذلك فإن الذاكرة القصوى أثناء الكتابة تتناسب مع 2 * packed_skip_index_max_bytes * (number of substreams that stay below the threshold).

فهارس النص الكامل غير مدعومة بهذا الإعداد ولا تُجمَّع أبدًا.

يقلّل التجميع من الضغط على inode عند تعريف العديد من فهارس التخطي على جدول (على سبيل المثال باستخدام add_minmax_index_for_numeric_columns).

تنسيق التخزين على القرص ذاتي الوصف: يكتشف القارئون skp_idx.packed ويخدمون التدفقات الفرعية المجمَّعة من داخله بشفافية. يؤثر تغيير هذا الإعداد في الأجزاء المكتوبة حديثًا فقط؛ أما الأجزاء الموجودة فستحتفظ بأي تخطيط كانت عليه وقت الكتابة.

​

part_minmax_index_columns

يحدِّد الأعمدة التي يغطيها فهرس min-max لكل جزء. وتُفعِّل كل قيمة مجموعة إضافية من الأعمدة فوق المجموعة السابقة.

القيم الممكنة:

• partition_key_only — لا تُتتبَّع إلا أعمدة مفتاح التقسيم.
• with_block_number_offset — أعمدة مفتاح التقسيم، بالإضافة إلى العمودين الافتراضيين المحفوظين _block_number و_block_offset. يتيح ذلك الاستبعاد على مستوى الجزء باستخدام هذين العمودين.

​

patch_parts_version

إصدار التسلسل على القرص لأجزاء التصحيح الناتجة عن استعلامات UPDATE خفيفة الوزن.

القيم الممكنة:

• v1 - التنسيق القديم: تحتوي أجزاء التصحيح على أعمدة النظام _part, _part_offset وتُفرز بحسب (_part, _part_offset). في أسوأ الحالات، يقتصر استخدام الذاكرة أثناء التطبيق على حجم جزء التصحيح بالكامل.
• v2 - تحتوي أجزاء التصحيح على أعمدة مفتاح الفرز للجدول الرئيسي وتُفرز بحسب (sorting_key_columns..., _block_number, _block_offset). يقتصر استخدام الذاكرة أثناء التطبيق على حجم أكبر مجموعة متتالية لها مفتاح فرز متطابق.

تظل التصحيحات ذات التنسيق القديم المخزنة على القرص قابلة للقراءة بغض النظر عن هذا الإعداد.

​

propagate_types_serialization_versions_to_nested_types

إذا كانت القيمة true، فستُمرَّر إصدارات التسلسل مثل string_serialization_version إلى داخل الأنواع المتداخلة مثل Array/Map/Nullable/JSON/etc. وإذا كان هذا الخيار معطّلًا، فلن يسري إصدار التسلسل إلا على الأعمدة ذات المستوى الأعلى من هذا النوع وعلى عناصر Tuple el

​

ratio_of_defaults_for_sparse_serialization

الحد الأدنى لنسبة عدد القيم الافتراضية إلى عدد إجمالي القيم في عمود. يؤدي ضبط هذه القيمة إلى تخزين العمود باستخدام التسلسلات المتناثرة.

إذا كان العمود متناثرًا (يحتوي في معظمه على أصفار)، يمكن لـ ClickHouse ترميزه بتنسيق متناثر وتحسين العمليات الحسابية تلقائيًا، إذ لا تتطلب البيانات فك الضغط الكامل أثناء الاستعلامات. ولتمكين هذا التسلسل المتناثر، عيّن الإعداد ratio_of_defaults_for_sparse_serialization ليكون أقل من 1.0. وإذا كانت القيمة أكبر من أو تساوي 1.0، فستُكتب الأعمدة دائمًا باستخدام التسلسل الكامل العادي.

القيم الممكنة:

• قيمة Float بين 0 و 1 لتمكين التسلسل المتناثر
• 1.0 (أو أكبر) إذا كنت لا تريد استخدام التسلسل المتناثر

مثال

لاحظ أن العمود s في الجدول التالي يكون سلسلة نصية فارغة في 95% من الصفوف. في my_regular_table لا نستخدم التسلسل المتناثر، وفي my_sparse_table نضبط ratio_of_defaults_for_sparse_serialization على 0.95:

CREATE TABLE my_regular_table
(
`id` UInt64,
`s` String
)
ENGINE = MergeTree
ORDER BY id;

INSERT INTO my_regular_table
SELECT
number AS id,
number % 20 = 0 ? toString(number): '' AS s
FROM
numbers(10000000);

CREATE TABLE my_sparse_table
(
`id` UInt64,
`s` String
)
ENGINE = MergeTree
ORDER BY id
SETTINGS ratio_of_defaults_for_sparse_serialization = 0.95;

INSERT INTO my_sparse_table
SELECT
number,
number % 20 = 0 ? toString(number): ''
FROM
numbers(10000000);

لاحظ أن العمود s في my_sparse_table يشغل مساحة تخزين أقل على القرص:

SELECT table, name, data_compressed_bytes, data_uncompressed_bytes FROM system.columns
WHERE table LIKE 'my_%_table';

┌─table────────────┬─name─┬─data_compressed_bytes─┬─data_uncompressed_bytes─┐
│ my_regular_table │ id   │              37790741 │                75488328 │
│ my_regular_table │ s    │               2451377 │                12683106 │
│ my_sparse_table  │ id   │              37790741 │                75488328 │
│ my_sparse_table  │ s    │               2283454 │                 9855751 │
└──────────────────┴──────┴───────────────────────┴─────────────────────────┘

يمكنك التحقق مما إذا كان عمودٌ ما يستخدم الترميز المتناثر بعرض العمود serialization_kind من الجدول system.parts_columns:

SELECT column, serialization_kind FROM system.parts_columns
WHERE table LIKE 'my_sparse_table';

يمكنك الاطلاع على الأجزاء من s التي خُزّنت باستخدام التسلسل المتناثر:

┌─column─┬─serialization_kind─┐
│ id     │ Default            │
│ s      │ Default            │
│ id     │ Default            │
│ s      │ Default            │
│ id     │ Default            │
│ s      │ Sparse             │
│ id     │ Default            │
│ s      │ Sparse             │
│ id     │ Default            │
│ s      │ Sparse             │
│ id     │ Default            │
│ s      │ Sparse             │
│ id     │ Default            │
│ s      │ Sparse             │
│ id     │ Default            │
│ s      │ Sparse             │
│ id     │ Default            │
│ s      │ Sparse             │
│ id     │ Default            │
│ s      │ Sparse             │
│ id     │ Default            │
│ s      │ Sparse             │
└────────┴────────────────────┘

​

reduce_blocking_parts_sleep_ms

متوفر فقط في ClickHouse Cloud. الحد الأدنى للوقت الذي يجب انتظاره قبل محاولة تقليل الأجزاء المُعيقة مرة أخرى إذا لم يتم إسقاط/استبدال أي نطاقات. سيؤدي خفض هذا الإعداد إلى تشغيل المهام في background_schedule_pool بشكل متكرر، مما يسفر عن عدد كبير من الطلبات إلى ZooKeeper في المجموعات كبيرة الحجم

​

replace_long_file_name_to_hash

إذا كان اسم ملف العمود طويلًا جدًا (أكثر من max_file_name_length بايت)، فاستبدله بـ SipHash128

​

replicated_can_become_leader

إذا كانت القيمة true، فستحاول النسخ المتماثلة للجداول المكرّرة على هذه العقدة تولّي القيادة.

القيم الممكنة:

• true
• false

​

search_orphaned_parts_disks

يفحص ClickHouse جميع الأقراص بحثًا عن الأجزاء اليتيمة عند تنفيذ أي ATTACH أو CREATE table، وذلك لتجنّب إغفال أجزاء البيانات الموجودة على أقراص غير معرّفة (غير مشمولة في سياسة التخزين). تنشأ الأجزاء اليتيمة نتيجة إعادة تهيئة للتخزين قد تكون غير آمنة، على سبيل المثال إذا جرى استبعاد قرص من سياسة التخزين. يحدّد هذا الإعداد نطاق الأقراص التي سيجري البحث فيها وفقًا لخصائص تلك الأقراص.

القيم الممكنة:

• any - النطاق غير مقيّد.
• local - يقتصر النطاق على الأقراص المحلية.
• none - نطاق فارغ، لا تُجرى أي عملية بحث

​

serialization_info_version

إصدار معلومات التسلسل المستخدَم عند كتابة serialization.json. هذا الإعداد مطلوب لضمان التوافق أثناء ترقيات العنقود.

القيم الممكنة:

• basic - تنسيق basic.
• with_types - تنسيق يتضمن الحقل الإضافي types_serialization_versions، مما يتيح إصدارات تسلسل لكل نوع. وهذا يجعل إعدادات مثل string_serialization_version فعّالة.
• with_missing_columns - كل ما يسجّله with_types، بالإضافة إلى الحقل missing_columns الذي يسرد الأعمدة المفقودة والنوع الذي تمثّل قيمته الافتراضية قيمها. مطلوب لتمكين skip_empty_columns_on_insert.

أثناء الترقيات المتدرجة، اضبط هذا على basic لكي تُنتج الخوادم الجديدة أجزاء بيانات متوافقة مع الخوادم القديمة. بعد اكتمال الترقية، بدّل إلى with_types (أو with_missing_columns) لتمكين الميزات المقابلة.

​

share_nested_offsets

عند تفعيله (وهو الإعداد الافتراضي)، تُعامل أعمدة Array ذات الأسماء المنقطة التي تشترك في بادئة واحدة (مثل n.a و n.b) على أنها جزء من بنية Nested: إذ تشترك في ملف offsets واحد على القرص (مثل n.size0)، ويُتحقق أثناء INSERT من تساوي أحجام المصفوفات فيها. وعند تعطيله، يحصل كل عمود Array على ملف offsets مستقل، ولا تعود الأسماء المنقطة تحمل أي دلالات خاصة، كما يمكن أن يتعايش عمود scalar مع أعمدة Array منقطة تشترك في البادئة نفسها (مثل n UInt32 إلى جانب n.a Array(String)). هذا الإعداد غير قابل للتغيير بعد إنشاء الجدول.

​

simultaneous_parts_removal_limit

إذا كان هناك عدد كبير من الأجزاء القديمة، فسيحاول مؤشر ترابط التنظيف حذف ما يصل إلى simultaneous_parts_removal_limit جزءًا خلال تكرار واحد. ويعني تعيين simultaneous_parts_removal_limit إلى 0 عدم وجود حد.

​

skip_empty_columns_on_insert

عند تفعيله، لا تُكتب إلى جزء البيانات على القرص الأعمدةُ التي تكون قيمها بالكامل هي القيم الافتراضية لنوعها ضمن block إدراج معيّن. وعند قراءة الجزء لاحقًا، تُملأ الأعمدة المفقودة بالقيمة الافتراضية للنوع المسجَّل لها. ويوفّر هذا مساحة على القرص في أحمال العمل ذات التحديثات المتفرقة، حيث تبقى معظم الأعمدة في كل INSERT عند القيمة الافتراضية لنوعها. أما الأعمدة التي تحتوي على تعبيرات DEFAULT أو MATERIALIZED أو ALIAS فلا تُتخطى أبدًا، لأن مسار القراءة سيقيّم التعبير بدلًا من إرجاع القيمة الافتراضية للنوع التي أُدرجت صراحةً. كما تُستثنى أجزاء التصحيح (المستخدمة في UPDATE خفيف الوزن). ويسجّل هذا التحسين الأعمدة المفقودة في ملف serialization.json الخاص بالجزء باستخدام إصدار الصيغة with_missing_columns، ولذلك لا يسري مفعوله إلا عندما تكون قيمة serialization_info_version مضبوطة على with_missing_columns. أما مع إصدار أقل (كأن تُثبَّت على قيمة أدنى من أجل ترقية متدرجة بحيث تتمكن الخوادم الأقدم من قراءة الأجزاء المكتوبة حديثًا) فلا تُتخطى أي أعمدة.

​

storage_policy

اسم سياسة تخزين القرص

​

string_serialization_version

يتحكم هذا الإعداد في تنسيق التسلسل لأعمدة String ذات المستوى الأعلى.

لا يكون هذا الإعداد فعّالًا إلا عندما تكون قيمة serialization_info_version مضبوطة على “with_types” أو أحدث. وعند ضبطه على with_size_stream، تُسلسَل أعمدة String ذات المستوى الأعلى باستخدام عمود فرعي منفصل .size لتخزين أطوال السلاسل النصية بدلًا من تضمينها مباشرةً. يتيح ذلك أعمدة فرعية حقيقية باسم .size، ويمكن أن يحسّن كفاءة الضغط.

لا تتأثر أنواع String المتداخلة (مثل داخل Nullable أو LowCardinality أو Array أو Map) بهذا الإعداد، إلا عندما تظهر داخل Tuple.

القيم الممكنة:

• single_stream — استخدم تنسيق التسلسل القياسي مع أحجام مضمنة.
• with_size_stream — استخدم تدفّق أحجام منفصلًا لأعمدة String ذات المستوى الأعلى.

​

temporary_directories_lifetime

عدد الثواني التي يتم خلالها الاحتفاظ بدلائل tmp_. يجب ألا تخفض هذه القيمة، لأن عمليات الدمج والتعديل قد لا تتمكن من العمل إذا كانت قيمة هذا الإعداد منخفضة.

​

try_fetch_recompressed_part_timeout

المهلة الزمنية (بالثواني) قبل بدء الدمج مع إعادة الضغط. خلال هذه المدة، يحاول ClickHouse جلب الجزء المُعاد ضغطه من النسخة المتماثلة التي أُسنِد إليها هذا الدمج مع إعادة الضغط.

تكون إعادة الضغط بطيئة في معظم الحالات، لذلك لا يبدأ الدمج مع إعادة الضغط إلا بعد انقضاء هذه المهلة الزمنية، مع الاستمرار في محاولة جلب الجزء المُعاد ضغطه من النسخة المتماثلة التي أُسنِد إليها هذا الدمج مع إعادة الضغط.

القيم الممكنة:

• أي عدد صحيح موجب.

​

ttl_only_drop_parts

يتحكم هذا الإعداد في ما إذا كانت أجزاء البيانات تُحذف بالكامل في جداول MergeTree عندما تكون جميع الصفوف في ذلك الجزء قد انتهت صلاحيتها وفقًا لإعدادات TTL الخاصة بها.

عندما يكون ttl_only_drop_parts معطّلًا (افتراضيًا)، لا تُزال إلا الصفوف التي انتهت صلاحيتها استنادًا إلى إعدادات TTL الخاصة بها.

عندما يكون ttl_only_drop_parts مفعّلًا، يُحذف الجزء بالكامل إذا كانت جميع الصفوف في ذلك الجزء قد انتهت صلاحيتها وفقًا لإعدادات TTL الخاصة بها.

ينطبق هذا فقط على إعدادات TTL التي تحذف الصفوف. أما TTL الخاص بأحد الأعمدة فلا يمكن تطبيقه إلا بإعادة كتابة الجزء، ولذلك تظل عمليات الدمج التي تنظّف الأعمدة منتهية الصلاحية مُجدولة حتى عند تمكين هذا الإعداد. ولأن مثل هذا الدمج يعيد كتابة الجزء على أي حال، فإنه يُزيل أيضًا الصفوف التي انتهت صلاحيتها فيه.

​

wait_for_unique_parts_send_before_shutdown_ms

قبل إيقاف التشغيل، سينتظر الجدول المدة الزمنية المطلوبة حتى تجلب النسخ المتماثلة الأخرى الأجزاء الفريدة (الموجودة فقط على النسخة المتماثلة الحالية) (0 يعني التعطيل).

​

zookeeper_session_expiration_check_period

الفاصل الزمني للتحقق من انتهاء صلاحية جلسة ZooKeeper، بالثواني.

القيم الممكنة:

• أي عدد صحيح موجب.