إعدادات الجلسة enable_*

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

يُفعّل خوارزمية GROUP BY التكيفية: يُجمّع كل خيط البيانات في جدول التجزئة المحلي الخاص به حتى يبلغ adaptive_aggregator_freeze_threshold مفتاحًا (أو adaptive_aggregator_freeze_threshold_bytes من الذاكرة)، ثم يُجمَّد الجدول، بحيث تستمر صفوف المفاتيح المرصودة مسبقًا (المتكررة) في تحديثه مباشرةً، بينما تُوجَّه المفاتيح الجديدة (النادرة) وفق تجزئتها إلى قوائم انتظار لكل bucket وتُجمَّع مرة واحدة فقط ضمن الدمج المتوازي للـbucket. تبقى المفاتيح المتكررة في جداول صغيرة مقيمة في ذاكرة التخزين المؤقت، بينما تُخزَّن المفاتيح النادرة وتُعالج مرة واحدة بدلًا من مرة لكل خيط.

تُراعى إعدادات التجميع الخارجي (max_bytes_before_external_group_by، max_bytes_ratio_before_external_group_by): عند تجاوز العتبة، تُفرَّغ قوائم الانتظار مبكرًا في الجدول المشترك، وإذا لم يكن ذلك كافيًا للعودة إلى ما دون العتبة، يُرحَّل الجدول المشترك إلى القرص باستخدام التجميع الخارجي العادي.

يحفّز المعالج على تفريغ البيانات إلى التخزين الخارجي بشكل تكيّفي. يتوفر دعم grace join حاليًا.

فعِّل DISTINCT في الاستعلامات الفرعية IN. هذا إعداد للموازنة بين الفوائد والتكلفة: إذ يمكن أن يؤدي تفعيله إلى تقليل حجم الجداول المؤقتة المنقولة للاستعلامات الفرعية IN الموزعة بشكل كبير، وتسريع نقل البيانات بين المقاطع بشكل ملحوظ، من خلال ضمان إرسال القيم الفريدة فقط. ومع ذلك، فإن تفعيل هذا الإعداد يضيف عبئًا إضافيًا على عمليات الدمج في كل عقدة، إذ يجب تنفيذ إزالة التكرار (DISTINCT). استخدم هذا الإعداد عندما يكون نقل البيانات عبر الشبكة هو عنق الزجاجة وتكون الكلفة الإضافية للدمج مقبولة.

يسمح باستخدام برنامج الترميز التجريبي للضغط ALP.

إذا تم تعيينه، فسيُفعِّل ClickHouse هذا التحسين تلقائيًا عندما يكون تعبير مفتاح التقسيم حتميًا، وعندما تكون جميع الأعمدة المستخدمة في تعبير مفتاح التقسيم مُضمَّنة في المفتاح الأساسي. ويضمن هذا الاستنتاج التلقائي أن الصفوف ذات قيم المفتاح الأساسي نفسها ستنتمي دائمًا إلى القسم نفسه، مما يجعل تجنّب عمليات الدمج عبر الأقسام آمنًا.

فعّل مُحسِّن Cascades المعتمد على التكلفة لخطط الاستعلامات الموزعة. لا يسري مفعوله إلا عند استخدام make_distributed_plan = 1: فهذا الإعداد وحده لا يغيّر تخطيط الاستعلامات على عقدة واحدة.

تمكين تحسين الاستعلام، حيث نحلل نتائج الدوال والاستعلامات الفرعية ونعيد كتابة الاستعلام إذا كانت تتضمن ثوابت

يؤدي إلى تمكين أو تعطيل إرجاع نتائج من النوع Date32 بنطاق موسّع (مقارنةً بالنوع Date) أو من النوع DateTime64 بنطاق موسّع (مقارنةً بالنوع DateTime).

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

• 0 — تُرجِع الدوال Date أو DateTime لجميع أنواع الوسيطات.
• 1 — تُرجِع الدوال Date32 أو DateTime64 عند استخدام وسيطات من النوع Date32 أو DateTime64، وتُرجِع Date أو DateTime في غير ذلك.

يوضح الجدول أدناه سلوك هذا الإعداد في دوال التاريخ والوقت المختلفة.

الأسماء البديلة: allow_experimental_full_text_index

إذا ضُبط هذا الإعداد على true، فسيُسمح باستخدام فهرس النص الكامل.

فعّل طيّ الثوابت مبكرًا باستخدام التقييم قصير الدائرة لـ and وor أثناء تحليل الاستعلام. عند تفعيله، تُحلَّل الفروع غير القابلة للوصول والمؤهلة في الاستعلامات الفرعية القياسية للحفاظ على أنواعها والتحقق من دلالات الاستعلام، لكنها لا تُنفَّذ. ويعود التحسين إلى التحليل العادي عندما تكون قيمة العددية القياسية أو قيم وقت التشغيل مطلوبة.

تمرير عبارات WITH إلى استعلامات UNION وجميع الاستعلامات الفرعية

فعّل تحسين تصفية TopK أثناء التجميع في استعلامات GROUP BY keys ORDER BY <prefix of keys> LIMIT K، وكذلك في استعلامات GROUP BY keys LIMIT K التي لا تتضمن ORDER BY (إذ تكون أي مجموعات K نتيجة صالحة، لذا يُنشأ فرز على جميع المفاتيح).

عند تفعيله، يحتفظ المُجمِّع بكومة محدودة تضم أفضل K مفاتيح ظهرت حتى الآن، ويتخطى إدراج صفوف جديدة في جدول التجزئة عندما لا يمكن لمفتاح التجميع الخاص بها أن يندرج ضمن النتيجة النهائية. يؤدي ذلك إلى تجنب تجميع الصفوف التي سيتخلص منها ORDER BY ... LIMIT اللاحق. وعندما ترتب الكومة مفتاح GROUP BY بالكامل، فإنها تحذف أيضًا المجموعات المُزالة من جدول التجزئة الوسيط، مما يحدّ حجمه بـ LIMIT بدلًا من عدد المفاتيح المميزة. أما عندما يغطي ORDER BY بادئة حقيقية فقط من مفاتيح GROUP BY، فلا يمكن للترتيب تحديد مجموعة كاملة، لذا لا يُطبّق سوى تخطي الصفوف: يحتفظ جدول التجزئة بكل مجموعة مقبولة، وقد يستمر في النمو بحسب عدد عناصر أعمدة المفاتيح المتبقية.

يُعطّل التحسين عندما يتجاوز LIMIT المطلوب query_plan_max_limit_for_top_k_optimization أو الحد الأقصى الصارم البالغ 100000، لأن تكلفة الذاكرة ووحدة المعالجة المركزية للكومة تزداد بزيادة LIMIT المطلوب.

يُتخطى التحسين في أشكال الاستعلامات التي قد يؤدي فيها حذف المجموعات إلى تغيير النتيجة، بما في ذلك WITH TOTALS وHAVING وQUALIFY ودوال النافذة وROLLUP/CUBE/GROUPING SETS وLIMIT WITH TIES، ووجود COLLATE على أي من مفاتيح GROUP BY المطابقة (أما COLLATE على عمود ORDER BY لاحق بعد بادئة المفتاح الكاملة فلا يمكن أن يؤثر في المجموعات المؤهلة، لذا لا يعطّل التحسين)، وORDER BY على قيمة مجمّعة أو على أي عنصر ليس بادئة أولية من مفاتيح GROUP BY، وعند تعيين max_rows_to_group_by أو exact_rows_before_limit.

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

• 0 — معطّل.
• 1 — مفعّل.

تمكين تحويل حمولة hash join إلى تخطيط صفّي.

يُفعِّل أو يُعطِّل pread لملفات HDFS. افتراضيًا، يُستخدَم hdfsPread. وإذا تم تعطيله، فسيُستخدَم hdfsRead وhdfsSeek لقراءة ملفات HDFS.

يُمكّن ضغط البيانات في الاستجابة لطلب HTTP أو يعطّله.

لمزيد من المعلومات، اقرأ وصف واجهة HTTP.

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

• 0 — معطّل.
• 1 — مفعّل.

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

يُخرج تتبّع المكدس لمنشئ المهمة عندما تؤدي المهمة إلى استثناء. وهو معطّل افتراضيًا لتجنّب الكلفة الإضافية على الأداء.

فعّل القيمة clickhouse_json لإعداد dialect.

عند ضبط dialect على clickhouse_json، تُفسَّر الاستعلامات على أنها أشجار AST بتنسيق JSON (ناتج parseQueryToJSON) بدلاً من نص SQL. يظل استعلام SET مُحلَّلاً بصيغة SQL عادية، بحيث يمكن تبديل اللهجة مرة أخرى.

مثال:

SET enable_json_ast_dialect = 1;
SET dialect = 'clickhouse_json';

-- Subsequent queries are parsed as JSON ASTs:
{"type":"SelectWithUnionQuery", ...}

يُمكّن النسخ الكسول للأعمدة في JOIN وARRAY JOIN والتقاطات لامبدا للدوال عالية الرتبة (مثل arrayMap)، مما يجنّب نسخ الصفوف نفسها في الذاكرة عدة مرات دون داعٍ.

تمكين تعبيرات الجدول الشائعة المُجسَّدة؛ وسيُفضَّل هذا الإعداد على enable_global_with_statement

فعّل استراتيجية الدمج المقيّدة بالذاكرة لنتائج التجميع.

انقل مزيدًا من الشروط من WHERE إلى PREWHERE، ونفّذ القراءة من القرص والتصفية على مراحل متعددة إذا كانت هناك شروط متعددة مدمجة باستخدام AND

إنشاء tuples مسماة في الدالة tuple() عندما تكون جميع الأسماء فريدة ويمكن التعامل معها كمُعرِّفات غير مقتبسة.

يتيح أو يعطّل الفرز باستخدام الصيغة ORDER BY ALL، راجع ORDER BY.

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

• 0 — تعطيل ORDER BY ALL.
• 1 — تمكين ORDER BY ALL.

مثال

الاستعلام:

CREATE TABLE TAB(C1 Int, C2 Int, ALL Int) ENGINE=Memory();

INSERT INTO TAB VALUES (10, 20, 30), (20, 20, 10), (30, 10, 20);

SELECT * FROM TAB ORDER BY ALL; -- returns an error that ALL is ambiguous

SELECT * FROM TAB ORDER BY ALL SETTINGS enable_order_by_all = 0;

النتيجة:

┌─C1─┬─C2─┬─ALL─┐
│ 20 │ 20 │  10 │
│ 30 │ 10 │  20 │
│ 10 │ 20 │  30 │
└────┴────┴─────┘

استخدم جدول تجزئة بمفاتيح من مراجع سلاسل معبأة بطول 16 بايتًا (PackedStringRef) مع GROUP BY ذي مفتاح String واحد غير قابل لـ NULL. تُخزَّن المفاتيح التي يصل طولها إلى 11 بايتًا مباشرةً في المرجع المعبأ، بينما تُخزَّن المفاتيح الأطول بالإشارة إليها في Arena. يكون هذا أسرع في معظم أحمال العمل، لكنه قد يكون أبطأ من الطريقة القديمة عند استخدام GROUP BY مع عدد قليل جدًا من المفاتيح المميزة التي يزيد طولها على 11 بايتًا، ولا سيما بطول 12..24 بايتًا؛ إذ يحتفظ جدول التجزئة القديم بالمفاتيح مباشرةً في الخلية، بينما يفك الجدول المعبأ مرجع مؤشر Arena عند كل عملية بحث. عند تعطيله، تُستخدم الطريقة القديمة المستندة إلى StringHashTable، وهي الطريقة الافتراضية قبل الإصدار 26.8.

يجب أن تتفق جميع الخوادم المشاركة في استعلام موزّع على هذه القيمة. فعند استخدام distributed_aggregation_memory_efficient، تعتمد أرقام buckets ثنائية المستوى على تجزئة المفتاح، وهي تختلف بين الطريقتين؛ لذلك قد تقسم الخوادم التي تختلف في هذا الإعداد المفتاح نفسه إلى buckets مختلفة وتنتج نتيجة مدمجة بصورة غير صحيحة. ولضمان هذا الاتفاق، ترسل initiator دائمًا قيمتها الفعلية مع الاستعلامات الثانوية، حتى عندما تكون مستمدة فقط من الإعدادات الافتراضية للخادم/الملف الشخصي، متجاوزةً الإعدادات الافتراضية للخوادم البعيدة.

إذا كانت القيمة true، فيمكن تحليل البيانات مباشرةً إلى الأعمدة ذات التسلسل المخصّص (مثل Sparse) وفقًا لتلميحات التسلسل المستمدة من الجدول.

السماح للتجميع الموفّر للذاكرة (راجع distributed_aggregation_memory_efficient) بإنتاج buckets بترتيب غير متسلسل. قد يحسّن ذلك الأداء عندما تكون أحجام buckets التجميع غير متوازنة، إذ يتيح للنسخة المتماثلة إرسال buckets ذات المعرّفات الأعلى إلى initiator بينما تواصل معالجة بعض buckets الكبيرة ذات المعرّفات الأقل. والجانب السلبي هو احتمال زيادة استخدام الذاكرة.

يسمح باستخدام برنامج الترميز الضغط التجريبي Quantized.

إذا كان هذا الخيار مفعّلًا، فستُسترجَع نتائج استعلامات SELECT من ذاكرة التخزين المؤقت للاستعلامات.

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

• 0 - معطّل
• 1 - مفعّل

يُفعّل تسجيلًا مفصلًا جدًا لطلبات S3. وهذا مناسب لأغراض التصحيح فقط.

إذا تم ضبطه على true، فإنه يمنع الاستعلامات الفرعية ذات القيمة المفردة من تسلسل/إلغاء تسلسل القيم المفردة الكبيرة، وقد يجنّب تنفيذ الاستعلام الفرعي نفسه أكثر من مرة.

إذا كان هذا الإعداد معطّلًا، فستتصرّف التعريفات في عبارات WITH الأب كما لو كانت مُعلنة ضمن النطاق الحالي نفسه.

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

يُمكّن تحسين GROUP BY المُشطَّر، الذي يوزّع الصفوف على الخيوط عبر تجزئة مفتاح التجميع، بحيث يُجمّع كل خيط مجموعة فرعية مستقلة من المفاتيح من دون مرحلة دمج.

يكون هذا فعّالًا للمفاتيح عالية الكاردينالية عندما تكون البيانات موزّعة بالتساوي، لكنه قد يتأثر سلبًا عند وجود توزيعات شديدة الانحراف للمفاتيح أو استعلامات تتضمن عددًا قليلًا جدًا من المفاتيح المميزة.

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

• 0 — تحسين التجميع المُشطَّر معطّل.
• 1 — تحسين التجميع المُشطَّر مفعّل.

إذا كان مُمكّنًا، فستشارك جميع الاستعلامات الفرعية ضمن استعلام واحد نفس StorageSnapshot لكل جدول. ويضمن ذلك عرضًا متسقًا للبيانات على مستوى الاستعلام بأكمله، حتى إذا جرى الوصول إلى الجدول نفسه عدة مرات.

وهذا مطلوب للاستعلامات التي يكون فيها الاتساق الداخلي لأجزاء البيانات مهمًا. مثال:

SELECT
    count()
FROM events
WHERE (_part, _part_offset) IN (
    SELECT _part, _part_offset
    FROM events
    WHERE user_id = 42
)

من دون هذا الإعداد، قد تعمل الاستعلامات الخارجية والداخلية على لقطات مختلفة من البيانات، مما يؤدي إلى نتائج غير صحيحة.

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

• 0 - معطّل
• 1 - مفعّل

السماح بمشاركة كائنات set المُنشأة من أجل الاستعلامات الفرعية IN بين المهام المختلفة ضمن عملية mutation نفسها. يقلل ذلك من استخدام الذاكرة واستهلاك CPU

يسمح بالاستعلامات المستمرة SELECT ... FROM t STREAM [CURSOR '{...}']. عند إيقافه، يُرفَض أي تعبير جدول يستخدم المعدِّل STREAM أثناء بناء الخطة. هذا هو مفتاح التحكم الرئيسي لميزة الاستعلامات المتدفقة؛ وقد تُقيَّد إمكانات إضافية بإعداداتها الخاصة.

يتيح استخدام برنامج الترميز الضغط التجريبي SZ3.

الأسماء البديلة: allow_experimental_time_time64_type

يسمح بإنشاء نوعَي البيانات Time وTime64.

يسمح باستخدام ARRAY JOIN مع عدة مصفوفات ذات أحجام مختلفة. عند تمكين هذا الإعداد، سيُعاد ضبط حجم المصفوفات وفقًا لأطولها.

يسمح بتمكين أو تعطيل فك ترميز المسار وترميزه في عنوان URI في جداول محرك URL.

يكون معطّلًا افتراضيًا.

عند التمكين، تُزال الصفوف المكررة أثناء FINAL عبر تمييز الصفوف على أنها محذوفة ثم ترشيحها لاحقًا بدلًا من دمج الصفوف

إذا كان هذا الإعداد مفعّلًا، فسيتم تخزين نتائج استعلامات SELECT في ذاكرة التخزين المؤقت للاستعلامات.

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

• 0 - معطّل
• 1 - مفعّل

يسمح باستخدام برنامج الترميز التجريبي للضغط ZXC.