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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ignore
• throw
• drop
• rebuild

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

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

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

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

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

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

• v1
• v2
• v3

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

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

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

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

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

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

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

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

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

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

• throw
• drop
• rebuild

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

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

• true
• false

انظر أيضًا

• الإعداد exclude_deleted_rows_for_part_size_in_merge

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

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

انظر أيضًا

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

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

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

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

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

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

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

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

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

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

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

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

• v1
• v2
• v3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الحدّ (بالبايتات المتسلسلة على القرص، أي بعد ضغط التدفق الفرعي وسلسلة التجزئة) الذي إذا كان تدفق فرعي لفهرس التخطي دونه، فسيُجمَّع داخل أرشيف 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 ويخدمون التدفقات الفرعية المجمَّعة من داخله بشفافية. يؤثر تغيير هذا الإعداد في الأجزاء المكتوبة حديثًا فقط؛ أما الأجزاء الموجودة فستحتفظ بأي تخطيط كانت عليه وقت الكتابة.

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

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

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

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

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

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

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

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

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

إذا كان العمود متناثرًا (يحتوي في معظمه على أصفار)، يمكن لـ 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             │
└────────┴────────────────────┘

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

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

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

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

• true
• false

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

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

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

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

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

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

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

عند تفعيله (وهو الإعداد الافتراضي)، تُعامل أعمدة 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 إلى 0 عدم وجود حد.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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