إعدادات الجلسة - ClickHouse Documentation

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

add_http_cors_header

إضافة ترويسة CORS الخاصة بـ HTTP.

additional_result_filter

تعبير تصفية إضافي يُطبَّق على نتيجة استعلام SELECT. لا يُطبَّق هذا الإعداد على أي استعلام فرعي. مثال

INSERT INTO table_1 VALUES (1, 'a'), (2, 'bb'), (3, 'ccc'), (4, 'dddd');
SElECT * FROM table_1;

┌─x─┬─y────┐
│ 1 │ a    │
│ 2 │ bb   │
│ 3 │ ccc  │
│ 4 │ dddd │
└───┴──────┘

SELECT *
FROM table_1
SETTINGS additional_result_filter = 'x != 2'

┌─x─┬─y────┐
│ 1 │ a    │
│ 3 │ ccc  │
│ 4 │ dddd │
└───┴──────┘

additional_table_filters

تعبير تصفية إضافي يُطبَّق بعد قراءة البيانات من الجدول المحدد. مثال

INSERT INTO table_1 VALUES (1, 'a'), (2, 'bb'), (3, 'ccc'), (4, 'dddd');
SELECT * FROM table_1;

┌─x─┬─y────┐
│ 1 │ a    │
│ 2 │ bb   │
│ 3 │ ccc  │
│ 4 │ dddd │
└───┴──────┘

SELECT *
FROM table_1
SETTINGS additional_table_filters = {'table_1': 'x != 2'}

┌─x─┬─y────┐
│ 1 │ a    │
│ 3 │ ccc  │
│ 4 │ dddd │
└───┴──────┘

aggregate_function_input_format

تنسيق إدخال AggregateFunction أثناء عمليات INSERT. القيم الممكنة:

state — سلسلة ثنائية تحتوي على الحالة المُسلسلة (الافتراضي). وهذا هو السلوك الافتراضي، حيث يُتوقع أن تكون قيم AggregateFunction بيانات ثنائية.
value — يتوقع التنسيق قيمة واحدة لوسيطة الدالة التجميعية، أو في حال وجود عدة وسائط، Tuple منها. سيُفك تسلسلها باستخدام IDataType أو DataTypeTuple المقابل، ثم تُجمَّع لتكوين الحالة.
array — يتوقع التنسيق Array من القيم، كما هو موضح في الخيار value أعلاه. وستُجمَّع جميع عناصر Array لتكوين الحالة.

أمثلة لجدول ذي البنية التالية:

CREATE TABLE example (
    user_id UInt64,
    avg_session_length AggregateFunction(avg, UInt32)
);

عند استخدام aggregate_function_input_format = 'value':

INSERT INTO example FORMAT CSV
123,456

عند استخدام aggregate_function_input_format = 'array':

INSERT INTO example FORMAT CSV
123,"[456,789,101]"

ملاحظة: تنسيقا value وarray أبطأ من تنسيق state الافتراضي، لأنهما يتطلبان إنشاء القيم وتجميعها أثناء عملية الإدراج.

aggregate_functions_null_for_empty

يُتيح تمكين أو تعطيل إعادة كتابة جميع aggregate functions في الاستعلام، مع إضافة اللاحقة -OrNull إليها. فعِّله لتحقيق التوافق مع معيار SQL. يُنفَّذ ذلك من خلال query rewrite (على غرار الإعداد count_distinct_implementation) للحصول على نتائج متسقة في distributed queries. القيم الممكنة:

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

مثال انظر إلى الاستعلام التالي الذي يتضمن aggregate functions:

SELECT SUM(-1), MAX(0) FROM system.one WHERE 0;

مع aggregate_functions_null_for_empty = 0 ستكون النتيجة:

┌─SUM(-1)─┬─MAX(0)─┐
│       0 │      0 │
└─────────┴────────┘

مع aggregate_functions_null_for_empty = 1 فستكون النتيجة:

┌─SUMOrNull(-1)─┬─MAXOrNull(0)─┐
│          NULL │         NULL │
└───────────────┴──────────────┘

aggregation_in_order_max_block_bytes

الحد الأقصى لحجم الكتلة بالبايتات التي تتراكم أثناء التجميع وفق ترتيب المفتاح الأساسي. يتيح تقليل حجم الكتلة زيادة التوازي في المرحلة النهائية من دمج التجميع.

aggregation_memory_efficient_merge_threads

عدد الخيوط المستخدمة لدمج نتائج التجميع الوسيطة في الوضع الموفّر للذاكرة. كلما زاد هذا العدد، زاد استهلاك الذاكرة. وتعني القيمة 0 — نفس قيمة max_threads.

ai_function_credentials

اسم المجموعة المسماة التي تستخدمها دوال الذكاء الاصطناعي لبيانات اعتماد المزوّد والتهيئة (provider وendpoint وmodel وapi_key الاختياري وغيرها). عند تركها فارغة، يُرفَع استثناء.

ai_function_embedding_max_batch_size

الحد الأقصى لعدد النصوص التي يمكن تضمينها في طلب HTTP واحد يُرسله aiEmbed. تُجمَّع النصوص في دفعات بهذا الحجم لتقليل العبء الزائد الناتج عن استدعاءات واجهة برمجة تطبيقات. على سبيل المثال، ينتج عن 500 نصًا فريدًا مع حجم دفعة قدره 100 عدد 5 طلبات HTTP.

ai_function_max_api_calls_per_query

الحد الأقصى لعدد طلبات HTTP التي يمكن لدوال الذكاء الاصطناعي إرسالها لكل استعلام. اضبطه على 0 للتعطيل.

ai_function_max_input_tokens_per_query

الحد الأقصى لإجمالي رموز الإدخال (prompt) عبر جميع استدعاءات واجهة برمجة تطبيقات دالة الذكاء الاصطناعي ضمن استعلام واحد. ويُتتبَّع هذا الإجمالي تراكميًا من استجابات المزوّد. لاحظ أن هذا الحد قد يُتجاوَز بمقدار رموز الإدخال الخاصة باستدعاء واحد، لأن عدد رموز الإدخال لذلك الاستدعاء لا يكون معروفًا مسبقًا. اضبط القيمة على 0 للتعطيل. لا يُطبَّق هذا الحد إلا على المزوّدين الذين يرسلون كائن usage في استجابتهم (OpenAI وAnthropic وvLLM). أمّا المزوّدون الذين لا يرسلون معلومات استخدام الرموز (وأبرزهم HuggingFace TEI)، فيجعلون العداد يبقى عند 0 — استخدم ai_function_max_api_calls_per_query بدلًا من ذلك لتقييد مثل هذه الاستدعاءات.

ai_function_max_output_tokens_per_query

الحد الأقصى لإجمالي رموز الإخراج (completion) عبر جميع استدعاءات واجهة برمجة تطبيقات الخاصة بدالة الذكاء الاصطناعي ضمن استعلام واحد. ويُحتسب ذلك تراكميًا من استجابات المزوّد. لاحظ أن هذا الحد قد يُتجاوز بمقدار رموز الإخراج الخاصة باستدعاء واحد، لأن عدد رموز الإخراج لذلك الاستدعاء لا يكون معروفًا مسبقًا. اضبط القيمة على 0 للتعطيل. لا يُطبَّق هذا الحد إلا على المزوّدين الذين يرسلون كائن usage في استجابتهم (OpenAI وAnthropic وvLLM). ولا ينطبق على دوال embedding (وخاصة aiEmbed)، لأنها لا تُنتج أي رموز إخراج مطلقًا.

ai_function_max_retries

الحد الأقصى لعدد مرات إعادة المحاولة عند حدوث أخطاء عابرة لكل طلب فردي إلى واجهة برمجة تطبيقات. تستخدم كل محاولة إعادة آلية تراجع أسي تبدأ من ai_function_retry_initial_delay_ms.

ai_function_request_timeout_sec

المهلة الزمنية، بالثواني، لكل طلب HTTP فردي تُجريه دوال الذكاء الاصطناعي (عمليات الإكمال في AI Chat واستدعاءات واجهة برمجة تطبيقات التضمين). إذا لم يكتمل الطلب خلال هذه المدة، فسيُعتبر فاشلًا وقد تُعاد محاولته وفقًا لـ ai_function_max_retries.

ai_function_retry_initial_delay_ms

التأخير الأولي، بالملي ثانية، قبل أول إعادة محاولة لطلب واجهة برمجة تطبيقات لدالة الذكاء الاصطناعي بعد فشله. ويتضاعف التأخير مع كل محاولة لاحقة (تراجع أُسّي). على سبيل المثال، مع الإعدادات الافتراضية: 1000ms، 2000ms، 4000ms.

ai_function_throw_on_error

إذا كانت القيمة true (وهي القيمة الافتراضية)، فإن استدعاء دالة الذكاء الاصطناعي الذي يفشل نهائيًا بعد استنفاد جميع retries يُجهض الاستعلام برفع Exception. وإذا كانت false، يتلقى الصف الذي فشل القيمة الافتراضية لنوع العمود (سلسلة فارغة لنوع String)، وتستمر المعالجة.

ai_function_throw_on_quota_exceeded

إذا كانت القيمة true (افتراضيًا)، فإن تجاوز حد الحصة لدالة الذكاء الاصطناعي (ai_function_max_input_tokens_per_query أو ai_function_max_output_tokens_per_query أو ai_function_max_api_calls_per_query) يُجهِض الاستعلام مع إطلاق استثناء. وإذا كانت القيمة false، فستتلقى الصفوف المتبقية القيمة الافتراضية لنوع العمود (سلسلة فارغة لنوع String).

allow_aggregate_partitions_independently

تمكين التجميع المستقل للأقسام على خيوط منفصلة عندما يكون مفتاح القسم ملائمًا لمفتاح group by. ويكون ذلك مفيدًا عندما يكون عدد الأقسام قريبًا من عدد الأنوية وتكون الأقسام متقاربة في الحجم

allow_archive_path_syntax

ستفسّر محركات File وS3 ودالة الجدول المسارات التي تحتوي على ’::’ على أنها <archive> :: <file> إذا كان للأرشيف الامتداد الصحيح.

allow_asynchronous_read_from_io_pool_for_merge_tree

استخدم مجمّع I/O في الخلفية للقراءة من جداول MergeTree. قد يزيد هذا الإعداد من الأداء في الاستعلامات المقيّدة بعمليات I/O

allow_calculating_subcolumns_sizes_for_merge_tree_reading

عند التمكين، سيحسب ClickHouse أحجام الملفات المطلوبة لقراءة كل عمود فرعي، بما يحسّن حساب أحجام المهام وكتل البيانات.

allow_changing_replica_until_first_data_packet

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

allow_create_index_without_type

يسمح بتنفيذ استعلام CREATE INDEX بدون TYPE. سيتم تجاهل الاستعلام. هذا مخصص لاختبارات التوافق مع SQL.

allow_custom_error_code_in_throwif

يتيح استخدام رمز خطأ مخصص في الدالة throwIf(). إذا كانت القيمة true، فقد تحمل الاستثناءات المُطلَقة رموز الخطأ غير متوقعة.

allow_ddl

إذا ضُبطت هذه القيمة على true، فسيُسمح للمستخدم بتنفيذ استعلامات DDL.

allow_deprecated_database_ordinary

يسمح بإنشاء قواعد بيانات باستخدام محرك Ordinary المُهمَل

allow_deprecated_error_prone_window_functions

السماح باستخدام دوال النوافذ المُهملة والمُعرَّضة للأخطاء (neighbor, runningAccumulate, runningDifferenceStartingWithFirstValue, runningDifference)

allow_deprecated_snowflake_conversion_functions

الدوال snowflakeToDateTime و snowflakeToDateTime64 و dateTimeToSnowflake و dateTime64ToSnowflake مهجورة ومُعطَّلة افتراضيًا. يُرجى استخدام الدوال snowflakeIDToDateTime و snowflakeIDToDateTime64 و dateTimeToSnowflakeID و dateTime64ToSnowflakeID بدلًا منها. لإعادة تفعيل الدوال المهجورة (على سبيل المثال، خلال فترة انتقالية)، يُرجى ضبط هذا الإعداد على true.

allow_deprecated_syntax_for_merge_tree

السماح بإنشاء جداول *MergeTree باستخدام صياغة قديمة لتعريف المحرّك

allow_distributed_ddl

إذا ضُبطت هذه القيمة على true، فسيُسمح للمستخدم بتنفيذ استعلامات DDL الموزعة.

allow_drop_detached

السماح بتنفيذ استعلامات ALTER TABLE … DROP DETACHED PART[ITION] …

allow_dynamic_type_in_join_keys

يسمح باستخدام النوع Dynamic في مفاتيح JOIN. أُضيف هذا الإعداد للتوافق. لا يُنصح باستخدام النوع Dynamic في مفاتيح JOIN لأن المقارنة مع الأنواع الأخرى قد تؤدي إلى نتائج غير متوقعة.

allow_execute_multiif_columnar

السماح بتنفيذ الدالة multiIf بصورة عمودية

allow_experimental_ai_functions

فعِّل دوال الذكاء الاصطناعي التجريبية (مثل aiGenerateContent). تُجري هذه الوظائف استدعاءات HTTP خارجية إلى مزوّدي خدمات الذكاء الاصطناعي.

allow_experimental_analyzer

الأسماء البديلة: enable_analyzer السماح باستخدام محلل الاستعلامات الجديد.

allow_experimental_cleanup_old_data_files_compaction

السماح بتنظيف ملفات البيانات القديمة أثناء عملية دمج Iceberg.

allow_experimental_codecs

إذا ضُبط على true، فسيُسمح بتحديد برامج ترميز ضغط تجريبية (لكن لا توجد لدينا أيٌّ منها بعد، لذا لا يفعل هذا الخيار شيئًا).

allow_experimental_correlated_subqueries

يسمح بتنفيذ الاستعلامات الفرعية المترابطة.

allow_experimental_database_glue_catalog

الأسماء البديلة: allow_database_glue_catalog السماح باستخدام محرك قاعدة البيانات التجريبي DataLakeCatalog مع catalog_type = ‘glue’ القيمة الافتراضية في Cloud: 1.

allow_experimental_database_hms_catalog

السماح باستخدام محرك قاعدة البيانات التجريبي DataLakeCatalog مع catalog_type = ‘hms’

allow_experimental_database_iceberg

الأسماء البديلة: allow_database_iceberg السماح باستخدام محرك قاعدة البيانات التجريبي DataLakeCatalog مع catalog_type = ‘iceberg’ القيمة الافتراضية في Cloud: 1.

allow_experimental_database_materialized_postgresql

السماح بإنشاء قاعدة بيانات باستخدام Engine=MaterializedPostgreSQL(…).

allow_experimental_database_paimon_rest_catalog

تمكين محرك قاعدة البيانات التجريبي DataLakeCatalog مع catalog_type = 'paimon_rest'

allow_experimental_database_unity_catalog

اسم بديل: allow_database_unity_catalog السماح باستخدام محرك قاعدة البيانات التجريبي DataLakeCatalog مع catalog_type = ‘unity’ القيمة الافتراضية في Cloud: 1.

allow_experimental_delta_kernel_rs

يسمح بالتنفيذ التجريبي لـ delta-kernel-rs.

allow_experimental_delta_lake_writes

يُفعّل ميزة الكتابة عبر delta-kernel.

allow_experimental_expire_snapshots

يسمح بتنفيذ أمر Iceberg التجريبي ALTER TABLE ... EXECUTE expire_snapshots.

allow_experimental_funnel_functions

يُمكّن الوظائف التجريبية لتحليل مسار التحويل.

allow_experimental_geo_types_in_iceberg

يسمح بتحليل حقول Iceberg من النوعين geometry وgeography على أنها من النوع Geometry ‏(Variant) في ClickHouse.

allow_experimental_hash_functions

تفعيل دوال التجزئة التجريبية

allow_experimental_iceberg_compaction

يسمح باستخدام ‘OPTIMIZE’ صراحةً مع جداول Iceberg.

allow_experimental_join_right_table_sorting

إذا ضُبطت على true، ومع استيفاء شرطي join_to_sort_minimum_perkey_rows وjoin_to_sort_maximum_table_rows، يُعاد ترتيب الجدول الأيمن حسب المفتاح لتحسين الأداء في عمليات ربط تجزئة من نوع left أو inner.

allow_experimental_json_lazy_type_hints

يُفعِّل تلميحات الأنواع المؤجَّلة التجريبية لنوع JSON. تتيح هذه الميزة تحسين تحويلات نوع JSON عبر تأجيل تقييم تلميحات الأنواع.

allow_experimental_kafka_offsets_storage_in_keeper

يتيح هذا الخيار استخدام ميزة تجريبية لتخزين الإزاحات المرتبطة بـ Kafka في ClickHouse Keeper. عند التمكين، يمكن تحديد مسار ClickHouse Keeper واسم النسخة المتماثلة لمحرك جدول Kafka. ونتيجة لذلك، بدلًا من محرك Kafka المعتاد، سيُستخدم نوع جديد من محركات التخزين يخزّن الإزاحات المُثبتة بشكل أساسي في ClickHouse Keeper

allow_experimental_kusto_dialect

فعّل لغة استعلام Kusto ‏(KQL) — وهي بديل لـ SQL.

allow_experimental_materialized_postgresql_table

يسمح باستخدام محرك جدول MaterializedPostgreSQL. يكون معطّلًا افتراضيًا لأن هذه الميزة تجريبية

allow_experimental_nlp_functions

تمكين الوظائف التجريبية لمعالجة اللغة الطبيعية.

allow_experimental_nullable_tuple_type

الأسماء البديلة: enable_nullable_tuple_type يسمح بإنشاء أعمدة Nullable من النوع Tuple في الجداول. لا يتحكم هذا الإعداد في ما إذا كان يمكن أن تكون الأعمدة الفرعية المستخرجة من Tuple من النوع Nullable (على سبيل المثال، من أعمدة Dynamic أو Variant أو JSON أو Tuple). استخدم allow_nullable_tuple_in_extracted_subcolumns للتحكم في ما إذا كان يمكن أن تكون الأعمدة الفرعية المستخرجة من Tuple من النوع Nullable.

allow_experimental_object_storage_queue_hive_partitioning

يسمح باستخدام تقسيم Hive مع محركي S3Queue/AzureQueue

allow_experimental_paimon_storage_engine

يسمح بإنشاء جداول باستخدام محركات الجداول Paimon*.

allow_experimental_parallel_reading_from_replicas

الأسماء البديلة: enable_parallel_replicas استخدم ما يصل إلى max_parallel_replicas من النسخ المتماثلة من كل شريحة لتنفيذ استعلام SELECT. تُنفَّذ القراءة بالتوازي ويُنسَّق ذلك ديناميكيًا. 0 - معطّل، 1 - مفعّل، ويُعطَّل بصمت في حال الفشل، 2 - مفعّل، مع طرح استثناء في حال الفشل

allow_experimental_polyglot_dialect

تمكين مُحوِّل SQL متعدد اللهجات — يحوّل SQL من أكثر من 30 لهجة (MySQL وPostgreSQL وSQLite وSnowflake وDuckDB وغيرها) إلى ClickHouse SQL.

allow_experimental_prql_dialect

فعّل PRQL، وهو بديل لـ SQL.

allow_experimental_text_index_lazy_apply

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

allow_experimental_time_series_aggregate_functions

الأسماء البديلة: allow_experimental_ts_to_grid_aggregate_function دوال timeSeries* التجميعية التجريبية لإعادة أخذ عينات السلاسل الزمنية على غرار Prometheus، وحساب المعدل، وdelta.

allow_experimental_time_series_table

يسمح بإنشاء جداول باستخدام محرك الجدول TimeSeries. القيم الممكنة:

0 — محرك الجدول TimeSeries معطّل.
1 — محرك الجدول TimeSeries مفعّل.

allow_experimental_unique_key

يسمح بإنشاء جداول باستخدام العبارة UNIQUE KEY في محركات عائلة MergeTree.

allow_experimental_window_view

تمكين WINDOW VIEW. هذه الميزة غير ناضجة بما يكفي.

allow_experimental_ytsaurus_dictionary_source

مصدر قاموس تجريبي للتكامل مع YTsaurus.

allow_experimental_ytsaurus_table_engine

محرك جدول تجريبي للتكامل مع YTsaurus.

allow_experimental_ytsaurus_table_function

محرك جدول تجريبي للتكامل مع YTsaurus.

allow_fuzz_query_functions

يُمكّن الدالة fuzzQuery التي تُجري تعديلات عشوائية على AST الخاصة بسلسلة الاستعلام.

allow_general_join_planning

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

allow_get_client_http_header

يسمح باستخدام الدالة getClientHTTPHeader التي تتيح الحصول على قيمة ترويسة من ترويسات طلب HTTP الحالي. وهي غير مُمكّنة افتراضيًا لأسباب أمنية، لأن بعض الترويسات، مثل Cookie، قد تحتوي على معلومات حساسة. لاحظ أن الترويسات X-ClickHouse-* وAuthentication تكون مقيّدة دائمًا، ولا يمكن الحصول عليها باستخدام هذه الدالة.

allow_hyperscan

يسمح بالدوال التي تستخدم مكتبة Hyperscan. عطِّله لتجنّب أوقات التجميع الطويلة المحتملة والاستهلاك المفرط للموارد.

allow_iceberg_remove_orphan_files

يسمح باستخدام ALTER TABLE ... EXECUTE remove_orphan_files() لجداول Iceberg.

allow_insert_into_iceberg

الأسماء البديلة: allow_experimental_insert_into_iceberg يسمح بتنفيذ استعلامات insert في Iceberg.

allow_introspection_functions

يُفعِّل أو يعطِّل دوال فحص البنية الداخلية لتحليل أداء الاستعلامات. القيم الممكنة:

1 — دوال فحص البنية الداخلية مفعّلة.
0 — دوال فحص البنية الداخلية معطّلة.

انظر أيضًا

أداة أخذ العينات لتحليل أداء الاستعلامات
جدول النظام trace_log

allow_key_condition_coalesce_rewrite

يسمح للمفتاح الأساسي في MergeTree وskip indexes بتقليص granules لشروط WHERE/PREWHERE التي تتضمن coalesce أو ifNull. من دون هذا الإعداد، تكون هذه الشروط غير قابلة للتحليل من ناحية الفهرس ولا تؤدي إلى التقليص، لذلك تظل granules التي لا يمكن أن تطابق مقروءة. يؤثر ذلك فقط في granules التي تُقرأ؛ أما نتيجة الاستعلام فتبقى بلا تغيير، لأن الصفوف تظل تُرشَّح بواسطة الشرط الأصلي. يُعاد كتابة شكلين من الشروط المرشِّحة قبل تحليل الفهرس:

تتحول المقارنة مع coalesce/ifNull، مثل coalesce(a, b) = 5، إلى فصل منطقي بحيث يتمكن الفهرس على كل argument من التقليص: a = 5 OR (a IS NULL AND b = 5)، مع التوسعة لتشمل المزيد من المُعامِلات.
إذا استُخدم coalesce/ifNull مع ثابت افتراضي ذي قيمة كاذبة (صفر) مباشرةً كشرط، مثل ifNull(a = 5, 0) أو coalesce(a = 5, 0)، فيُكشف إلى شرطه الداخلي a = 5. وتؤدي مثل هذه wrappers إلى اختزال النتيجة ثلاثية القيم للشرط الداخلي إلى قيمة منطقية محددة (أي تحويل NULL إلى false).

allow_limit_by_partitions_independently

يُمكّن التقييم المستقل لـ LIMIT BY لكل قسم باستخدام خيوط تنفيذ منفصلة عندما يكون تعبير القسم دالة حتمية لأعمدة LIMIT BY.

allow_materialized_view_with_bad_select

السماح بـ CREATE MATERIALIZED VIEW مع استعلام SELECT يشير إلى جداول أو أعمدة غير موجودة. يجب أن يظل الاستعلام صحيحًا نحويًا. لا ينطبق ذلك على MVs القابلة للتحديث. ولا ينطبق أيضًا إذا كان مخطط MV يحتاج إلى أن يُستنتج من استعلام SELECT (أي إذا كان CREATE لا يتضمن قائمة أعمدة ولا جدول TO). يمكن استخدامه لإنشاء MV قبل جدول المصدر الخاص بها.

allow_named_collection_override_by_default

السماح بتجاوز حقول المجموعات المسماة افتراضيًا.

allow_non_metadata_alters

السماح بتنفيذ أوامر ALTER التي لا تؤثر فقط في البيانات الوصفية للجداول، بل تؤثر أيضًا في البيانات المخزنة على القرص

allow_nonconst_timezone_arguments

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

allow_nondeterministic_mutations

إعداد على مستوى المستخدم يتيح تنفيذ mutations على الجداول المكررة باستخدام دوال غير حتمية مثل dictGet. ونظرًا إلى أن القواميس قد تكون، على سبيل المثال، غير متزامنة بين العُقد، فإن mutations التي تسحب منها قيمًا تكون غير مسموح بها على الجداول المكررة افتراضيًا. ويؤدي تمكين هذا الإعداد إلى السماح بهذا السلوك، ما يجعل المستخدم مسؤولًا عن التأكد من أن البيانات المستخدمة متزامنة عبر جميع العُقد. مثال

<profiles>
    <default>
        <allow_nondeterministic_mutations>1</allow_nondeterministic_mutations>

        <!-- ... -->
    </default>

    <!-- ... -->

</profiles>

allow_nondeterministic_optimize_skip_unused_shards

يسمح باستخدام الدوال غير الحتمية (مثل rand أو dictGet، إذ إن الأخيرة لها بعض القيود المتعلقة بالتحديثات) في مفتاح التجزئة. القيم الممكنة:

0 — غير مسموح.
1 — مسموح.

allow_nullable_tuple_in_extracted_subcolumns

يتحكم هذا الإعداد في ما إذا كان يمكن تحديد نوع الأعمدة الفرعية المستخرجة من النوع Tuple(...) على أنه Nullable(Tuple(...)).

false: يُرجع Tuple(...) ويستخدم قيم tuple الافتراضية للصفوف التي يكون فيها العمود الفرعي مفقودًا.
true: يُرجع Nullable(Tuple(...)) ويستخدم NULL للصفوف التي يكون فيها العمود الفرعي مفقودًا.

يتحكم هذا الإعداد فقط في سلوك الأعمدة الفرعية المستخرجة. ولا يتحكم في ما إذا كان يمكن إنشاء أعمدة Nullable(Tuple(...)) في الجداول؛ إذ يتحكم في ذلك enable_nullable_tuple_type. يستخدم ClickHouse القيمة الخاصة بهذا الإعداد التي تُحمَّل عند بدء تشغيل الخادم. لا تؤدي التغييرات التي تُجرى باستخدام SET أو SETTINGS على مستوى query إلى تغيير سلوك الأعمدة الفرعية المستخرجة. لتغيير سلوك الأعمدة الفرعية المستخرجة، حدّث allow_nullable_tuple_in_extracted_subcolumns في إعدادات profile عند بدء التشغيل (على سبيل المثال، users.xml) ثم أعد تشغيل الخادم.

allow_prefetched_read_pool_for_local_filesystem

يفضّل استخدام تجمّع مؤشرات الترابط للجلب المسبق إذا كانت جميع الأجزاء موجودة على نظام الملفات المحلي”

allow_prefetched_read_pool_for_remote_filesystem

يُفضَّل استخدام تجمّع مؤشرات الترابط للجلب المسبق إذا كانت جميع الأجزاء على نظام ملفات بعيد

allow_push_predicate_ast_for_distributed_subqueries

يسمح بدفع شرط التصفية على مستوى AST إلى الاستعلامات الفرعية الموزعة عند تمكين المُحلِّل

allow_push_predicate_when_subquery_contains_with

يسمح بدفع شرط التصفية عندما يحتوي الاستعلام الفرعي على عبارة WITH

allow_rank_dense_rank_arguments

يسمح بتمرير وسائط إلى دالتي النافذة RANK وDENSE_RANK للحفاظ على التوافق مع الإصدارات السابقة. وفقًا لمعيار SQL، فإن RANK وDENSE_RANK لا تقبلان أي وسائط — إذ ترتّبان الصفوف استنادًا فقط إلى النافذة OVER (ORDER BY ...). وفي إصدارات ClickHouse السابقة لـ 26.5، كانت الاستعلامات مثل RANK(x) OVER (...) تُقبل بصمت مع تجاهل الوسيط، مما كان يسبّب التباسًا لدى المستخدمين (إذ كان الوسيط الظاهر يوحي بأنه يؤثر في الترتيب، لكنه في الواقع لا يفعل ذلك). عندما يكون هذا الإعداد false (وهو الإعداد الافتراضي)، فإن RANK وDENSE_RANK ترفضان أي وسائط وتُطلقان NUMBER_OF_ARGUMENTS_DOESNT_MATCH. وعند ضبطه على true، يُستعاد السلوك القديم المتساهل — إذ تُتجاهل الوسائط بصمت، بما يتوافق مع السلوك المتّبع قبل 26.5.

allow_reorder_prewhere_conditions

عند نقل الشروط من WHERE إلى PREWHERE، اسمح بإعادة ترتيب هذه الشروط لتحسين التصفية

allow_settings_after_format_in_insert

يحدّد ما إذا كان يُسمح باستخدام SETTINGS بعد FORMAT في استعلامات INSERT أم لا. لا يُنصح باستخدام هذا الإعداد، لأن ذلك قد يؤدي إلى تفسير جزء من SETTINGS على أنه قيم. مثال:

INSERT INTO FUNCTION null('foo String') SETTINGS max_threads=1 VALUES ('bar');

لكن الاستعلام التالي سيعمل فقط عند استخدام allow_settings_after_format_in_insert:

SET allow_settings_after_format_in_insert=1;
INSERT INTO FUNCTION null('foo String') VALUES ('bar') SETTINGS max_threads=1;

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

0 — ممنوع.
1 — مسموح.

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

allow_simdjson

يتيح استخدام مكتبة simdjson في دوال ‘JSON*’ إذا كانت تعليمات AVX2 متاحة. وإذا كان هذا الخيار معطّلًا، فستُستخدم rapidjson.

allow_special_serialization_kinds_in_output_formats

يسمح بإخراج الأعمدة ذات أنواع التسلسل الخاصة مثل Sparse وReplicated دون تحويلها إلى تمثيل عمود كامل. يساعد ذلك على تجنب النسخ غير الضروري للبيانات أثناء التنسيق.

allow_statistics

الأسماء البديلة: allow_experimental_statistics يسمح بتعريف إحصاءات للأعمدة وإدارة الإحصاءات.

allow_statistics_optimize

الأسماء البديلة: allow_statistic_optimize يسمح باستخدام الإحصاءات لتحسين الاستعلامات

allow_suspicious_codecs

إذا ضُبطت قيمته على true، يُسمح بتحديد ترميزات ضغط غير ذات معنى.

allow_suspicious_fixed_string_types

تسمح عبارة CREATE TABLE بإنشاء أعمدة من النوع FixedString(n) عندما تكون n > 256. ويُعد استخدام FixedString بطول >= 256 أمرًا مريبًا، وغالبًا ما يشير إلى استخدام غير صحيح

allow_suspicious_indices

رفض الفهارس الأساسية/الثانوية ومفاتيح الفرز ذات التعبيرات المتطابقة

allow_suspicious_low_cardinality_types

يسمح هذا الإعداد باستخدام LowCardinality مع أنواع البيانات ذات الحجم الثابت البالغ 8 بايتات أو أقل، أو يقيّد ذلك: أي أنواع البيانات الرقمية وFixedString(8_bytes_or_less). يكون استخدام LowCardinality مع القيم الثابتة الصغيرة غير فعّال عادةً، لأن ClickHouse يخزّن فهرسًا رقميًا لكل صف. ونتيجة لذلك:

قد يزداد استخدام مساحة القرص.
قد يرتفع استهلاك RAM، بحسب حجم القاموس.
قد تعمل بعض الدوال ببطء أكبر بسبب عمليات الترميز وفك الترميز الإضافية.

قد تزداد أوقات الدمج في الجداول التي تستخدم محرك MergeTree بسبب جميع الأسباب المذكورة أعلاه. القيم الممكنة:

1 — لا يكون استخدام LowCardinality مقيّدًا.
0 — يكون استخدام LowCardinality مقيّدًا.

allow_suspicious_primary_key

السماح باستخدام PRIMARY KEY/ORDER BY المريبَين في MergeTree (أي SimpleAggregateFunction).

allow_suspicious_ttl_expressions

ارفض تعبيرات TTL التي لا تعتمد على أي عمود من أعمدة الجدول. وهذا يشير في معظم الحالات إلى خطأ من المستخدم.

allow_suspicious_types_in_group_by

يسمح باستخدام النوعين Variant وDynamic في مفاتيح GROUP BY أو يقيّده.

allow_suspicious_types_in_order_by

يتيح أو يقيّد استخدام النوعين Variant وDynamic في مفاتيح ORDER BY.

allow_suspicious_variant_types

في عبارة CREATE TABLE، يسمح هذا بتحديد النوع Variant مع أنواع متغيرات متشابهة (على سبيل المثال، أنواع رقمية مختلفة أو أنواع Date مختلفة). قد يؤدي تمكين هذا الإعداد إلى حدوث بعض الالتباس عند العمل مع قيم ذات أنواع متشابهة.

allow_unrestricted_reads_from_keeper

يسمح بعمليات قراءة غير مقيّدة (من دون شرط على المسار) من جدول system.zookeeper، وقد يكون ذلك مفيدًا، لكنه غير آمن لـ ZooKeeper

alter_move_to_space_execute_async

تنفيذ ALTER TABLE MOVE … TO [DISK|VOLUME] بشكل غير متزامن

alter_partition_verbose_result

يُفعّل أو يعطّل عرض معلومات عن الأجزاء التي طُبِّقت عليها بنجاح عمليات المعالجة الخاصة بالتقسيمات والأجزاء. ينطبق على ATTACH PARTITION|PART وعلى FREEZE PARTITION. القيم الممكنة:

0 — تعطيل العرض التفصيلي.
1 — تفعيل العرض التفصيلي.

مثال

CREATE TABLE test(a Int64, d Date, s String) ENGINE = MergeTree PARTITION BY toYYYYMDECLARE(d) ORDER BY a;
INSERT INTO test VALUES(1, '2021-01-01', '');
INSERT INTO test VALUES(1, '2021-01-01', '');
ALTER TABLE test DETACH PARTITION ID '202101';

ALTER TABLE test ATTACH PARTITION ID '202101' SETTINGS alter_partition_verbose_result = 1;

┌─command_type─────┬─partition_id─┬─part_name────┬─old_part_name─┐
│ ATTACH PARTITION │ 202101       │ 202101_7_7_0 │ 202101_5_5_0  │
│ ATTACH PARTITION │ 202101       │ 202101_8_8_0 │ 202101_6_6_0  │
└──────────────────┴──────────────┴──────────────┴───────────────┘

ALTER TABLE test FREEZE SETTINGS alter_partition_verbose_result = 1;

┌─command_type─┬─partition_id─┬─part_name────┬─backup_name─┬─backup_path───────────────────┬─part_backup_path────────────────────────────────────────────┐
│ FREEZE ALL   │ 202101       │ 202101_7_7_0 │ 8           │ /var/lib/clickhouse/shadow/8/ │ /var/lib/clickhouse/shadow/8/data/default/test/202101_7_7_0 │
│ FREEZE ALL   │ 202101       │ 202101_8_8_0 │ 8           │ /var/lib/clickhouse/shadow/8/ │ /var/lib/clickhouse/shadow/8/data/default/test/202101_8_8_0 │
└──────────────┴──────────────┴──────────────┴─────────────┴───────────────────────────────┴─────────────────────────────────────────────────────────────┘

alter_sync

الأسماء البديلة: replication_alter_partitions_sync يتيح لك تحديد سلوك الانتظار للعمليات التي ستُنفَّذ على النسخ المتماثلة بواسطة استعلامات ALTER أو OPTIMIZE أو TRUNCATE. القيم الممكنة:

0 — لا تنتظر.
1 — انتظر التنفيذ على النسخة الحالية.
2 — انتظر جميع النسخ المتماثلة.
3 - انتظر النسخ المتماثلة النشطة فقط.

القيمة الافتراضية في Cloud: 0.

ينطبق alter_sync على جداول Replicated وSharedMergeTree فقط، ولا يكون له أي تأثير عند تعديل الجداول غير Replicated أو Shared.

alter_update_mode

نمط لاستعلامات ALTER التي تحتوي على أوامر UPDATE. القيم الممكنة:

heavy - نفّذ mutation عادية.
lightweight - نفّذ lightweight update إذا أمكن، وإلا فنفّذ mutation عادية.
lightweight_force - نفّذ lightweight update إذا أمكن، وإلا فاستخدم throw.

analyze_index_with_space_filling_curves

إذا كان الجدول يحتوي على منحنى ملء الفراغ في فهرسه، مثل ORDER BY mortonEncode(x, y) أو ORDER BY hilbertEncode(x, y)، وكان الاستعلام يتضمن شروطًا على وسائطه، مثل x >= 10 AND x <= 20 AND y >= 20 AND y <= 30، فاستخدم منحنى ملء الفراغ لتحليل الفهرس.

analyzer_compatibility_allow_compound_identifiers_in_unflatten_nested

يسمح بإضافة المعرّفات المركّبة إلى Nested. هذا إعداد توافق لأنه يغيّر نتيجة الاستعلام. عند تعطيله، لا يعمل SELECT a.b.c FROM table ARRAY JOIN a، ولا يُدرج SELECT a FROM table العمود a.b.c في ناتج Nested a.

analyzer_compatibility_join_using_top_level_identifier

فرض حلّ المعرّف في JOIN USING انطلاقًا من الإسقاط (على سبيل المثال، في SELECT a + 1 AS b FROM t1 JOIN t2 USING (b) سيتم تنفيذ عملية join وفقًا لـ t1.a + 1 = t2.b بدلًا من t1.b = t2.b).

analyzer_compatibility_prefer_alias_over_subcolumn

عندما يمكن أن يشير معرّف متعدد الأجزاء مثل b.id إما إلى العمود id في جدول يحمل الاسم المستعار b أو إلى عمود فرعي b.id من نوع Tuple تابع لعمود آخر، فامنح الأفضلية لتفسير بادئة الاسم المستعار (أي العمود id في b). افتراضيًا، يفضّل analyzer الجديد العمود الفرعي. فعِّل هذا الإعداد لمطابقة آلية التحليل في analyzer القديم.

analyzer_inline_views

عند تفعيله، يستبدل المُحلِّل طرق العرض العادية (غير المُجسَّدة وغير المُعلَّمة بمعلمات) بالاستعلامات الفرعية التي تعرّفها، مما يتيح تحسينات عبر الحدود مثل دفع الشروط وتشذيب الأعمدة.

any_join_distinct_right_table_keys

يُفعّل السلوك القديم لخادم ClickHouse في عمليات ANY INNER|LEFT JOIN.

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

عند تفعيل السلوك القديم:

لا تكون نتائج العمليتين t1 ANY LEFT JOIN t2 وt2 ANY RIGHT JOIN t1 متساوية، لأن ClickHouse يستخدم منطق تعيين مفاتيح الجداول من اليسار إلى اليمين بعلاقة متعدد إلى واحد.
تحتوي نتائج عمليات ANY INNER JOIN على جميع الصفوف من الجدول الأيسر، كما هو الحال في عمليات SEMI LEFT JOIN.

عند تعطيل السلوك القديم:

تكون نتائج العمليتين t1 ANY LEFT JOIN t2 وt2 ANY RIGHT JOIN t1 متساوية، لأن ClickHouse يستخدم منطقًا يوفّر تعيينًا للمفاتيح بعلاقة واحد إلى متعدد في عمليات ANY RIGHT JOIN.
تحتوي نتائج عمليات ANY INNER JOIN على صف واحد لكل مفتاح من الجدولين الأيسر والأيمن.

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

0 — السلوك القديم معطّل.
1 — السلوك القديم مفعّل.

انظر أيضًا:

صرامة JOIN

apply_deleted_mask

يُمكّن من استبعاد الصفوف المحذوفة باستخدام lightweight DELETE. وإذا كان معطّلًا، فسيتمكّن الاستعلام من قراءة تلك الصفوف. وهذا مفيد في سيناريوهات تصحيح الأخطاء و”التراجع عن الحذف”

apply_mutations_on_fly

إذا كانت القيمة true، فستُطبَّق عمليات mutation ‏(UPDATE وDELETE) التي لم تُطبَّق ماديًا في جزء البيانات عند تنفيذ عمليات SELECT.

apply_patch_parts

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

apply_patch_parts_join_cache_buckets

عدد الحاويات في ذاكرة التخزين المؤقتة المستخدمة لتطبيق أجزاء التصحيح في وضع Join.

apply_prewhere_after_final

عند التمكين، تُطبَّق شروط PREWHERE بعد معالجة FINAL في ReplacingMergeTree والمحركات المشابهة. قد يكون ذلك مفيدًا عندما يشير PREWHERE إلى أعمدة قد تختلف قيمها بين الصفوف المكررة، وتريد أن يحدد FINAL الصف المعتمد قبل التصفية. عند التعطيل، يُطبَّق PREWHERE أثناء القراءة. ملاحظة: إذا كان apply_row_level_security_after_final مُمكّنًا وكانت سياسة الصفوف تستخدم أعمدة ليست من مفتاح الفرز، فسيُؤجَّل أيضًا تطبيق PREWHERE للحفاظ على ترتيب التنفيذ الصحيح (يجب تطبيق سياسة الصفوف قبل PREWHERE).

apply_row_policy_after_final

عند تمكين هذا الإعداد، تُطبَّق سياسات الصفوف وPREWHERE بعد معالجة FINAL في جداول *MergeTree. (وخاصةً ReplacingMergeTree) وعند تعطيله، تُطبَّق سياسات الصفوف قبل FINAL، ما قد يؤدي إلى نتائج مختلفة عندما تستبعد السياسة صفوفًا ينبغي استخدامها لإزالة التكرار في ReplacingMergeTree أو المحركات المشابهة. إذا كان تعبير سياسة الصفوف يعتمد فقط على الأعمدة الموجودة في ORDER BY، فسيظل يُطبَّق قبل FINAL كتحسين، لأن مثل هذه التصفية لا يمكن أن تؤثر في نتيجة إزالة التكرار. القيم الممكنة:

0 — تُطبَّق سياسة الصفوف وPREWHERE قبل FINAL (افتراضيًا).
1 — تُطبَّق سياسة الصفوف وPREWHERE بعد FINAL.

apply_settings_from_server

ما إذا كان ينبغي للعميل قبول الإعدادات من الخادم. لا يؤثر هذا إلا في العمليات التي تُنفَّذ على جهة العميل، وبخاصة parsing لبيانات إدخال INSERT وformatting لنتيجة الاستعلام. يحدث معظم تنفيذ الاستعلام على الخادم، ولا يتأثر بهذا الإعداد. عادةً، يجب ضبط هذا الإعداد في profile المستخدم (users.xml أو استعلامات مثل ALTER USER)، وليس من خلال العميل (وسيطات سطر أوامر العميل، أو استعلام SET، أو قسم SETTINGS في استعلام SELECT). ويمكن تغييره من خلال العميل إلى false، لكن لا يمكن تغييره إلى true (لأن الخادم لن يرسل الإعدادات إذا كان profile المستخدم يحتوي على apply_settings_from_server = false). لاحظ أنه في البداية (24.12) كان هناك إعداد على مستوى الخادم (send_settings_to_client)، لكنه استُبدل لاحقًا بهذا الإعداد على جهة العميل لتحسين سهولة الاستخدام.

archive_adaptive_buffer_max_size_bytes

يحدّد الحجم الأقصى للمخزن المؤقت المتكيف المستخدم عند الكتابة إلى ملفات الأرشيف (على سبيل المثال، أرشيفات tar

arrow_flight_request_descriptor_type

نوع الواصف المستخدم لطلبات Arrow Flight. يرسل 'path' اسم مجموعة البيانات كواصف من نوع path. ويرسل 'command' استعلام SQL كواصف من نوع command (وهو مطلوب لـ Dremio). القيم الممكنة:

‘path’ — استخدم FlightDescriptor::Path (الافتراضي، ويعمل مع معظم خوادم Arrow Flight)
‘command’ — استخدم FlightDescriptor::Command مع استعلام SELECT (مطلوب لـ Dremio)

ast_fuzzer_any_query

عندما تكون القيمة false (الافتراضية)، تقتصر أداة تشويش AST على جهة الخادم (التي يتحكم فيها ast_fuzzer_runs) على تشويش استعلامات القراءة فقط (SELECT, EXPLAIN, SHOW, DESCRIBE, EXISTS). وعندما تكون القيمة true، يتم تشويش جميع أنواع الاستعلامات، بما في ذلك DDL و INSERT.

ast_fuzzer_runs

يُفعّل أداة تشويش AST من جهة الخادم، والتي تُشغّل استعلامات عشوائية بعد كل استعلام عادي مع تجاهل نتائجها.

0: معطّل (افتراضي).
قيمة بين 0 و1 (على نحو حصري): احتمال تشغيل استعلام عشوائي واحد.
قيمة >= 1: عدد الاستعلامات العشوائية التي تُشغَّل لكل استعلام عادي.

تُراكِم أداة الاختبار مقاطع AST من جميع الاستعلامات عبر كل الجلسات، مما ينتج طفرات تزداد إثارةً للاهتمام بمرور الوقت. وتُهمَل الاستعلامات العشوائية التي تفشل بصمت؛ ولا تُعاد النتائج مطلقًا إلى العميل.

asterisk_include_alias_columns

تضمين أعمدة ALIAS في استعلام أحرف البدل (SELECT *). القيم الممكنة:

0 - معطّل
1 - مُمكّن

asterisk_include_materialized_columns

تضمين الأعمدة MATERIALIZED في استعلام أحرف البدل (SELECT *). القيم الممكنة:

0 - معطّل
1 - مُمكّن

asterisk_include_virtual_columns

تضمين الأعمدة الظاهرية في استعلام أحرف البدل (SELECT *). القيم الممكنة:

0 - معطّل
1 - مُمكّن

async_insert

إذا كانت القيمة true، فستُخزَّن البيانات الناتجة عن استعلام INSERT في قائمة انتظار، ثم تُكتب لاحقًا إلى الجدول في الخلفية. وإذا كانت قيمة wait_for_async_insert هي false، فستُعالَج عملية INSERT بشكل شبه فوري، وإلا فسوف ينتظر العميل حتى تُكتب البيانات إلى الجدول

async_insert_busy_timeout_decrease_rate

معدل النمو الأُسّي الذي تنخفض وفقه مهلة الإدراج غير المتزامن التكيفية

async_insert_busy_timeout_increase_rate

معدل النمو الأُسِّي الذي تزداد وفقه مهلة الإدراج غير المتزامن التكيفية

async_insert_busy_timeout_max_ms

الأسماء المستعارة: async_insert_busy_timeout_ms الحد الأقصى للوقت الذي يجب انتظاره قبل تفريغ البيانات المجمّعة لكل query، وذلك منذ وصول أول البيانات. قيمة Cloud الافتراضية: 1000 (1s).

async_insert_busy_timeout_min_ms

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

async_insert_deduplicate

بالنسبة إلى استعلامات INSERT غير المتزامنة في الجدول المُكرَّر، يحدّد ما إذا كان ينبغي إجراء إزالة تكرار الكتل المُدرجة

async_insert_max_data_size

الحد الأقصى لحجم البيانات غير المُحلَّلة المجمَّعة لكل استعلام، بالبايت، قبل إدراجها القيمة الافتراضية في Cloud: 104857600 (100 MiB).

async_insert_max_query_number

الحد الأقصى لعدد استعلامات الإدراج قبل إدراجها. يُطبَّق فقط إذا كانت قيمة الإعداد async_insert_deduplicate هي 1.

async_insert_poll_timeout_ms

مهلة لاستطلاع البيانات من قائمة انتظار الإدراج غير المتزامن

async_insert_use_adaptive_busy_timeout

إذا ضُبط على true، فستُستخدم مهلة انشغال تكيّفية لعمليات الإدراج غير المتزامنة

async_query_sending_for_remote

يُفعّل إنشاء الاتصالات وإرسال الاستعلامات بشكل غير متزامن أثناء تنفيذ استعلام عن بُعد. مفعّل افتراضيًا.

async_socket_for_remote

يُفعّل القراءة غير المتزامنة من المقبس أثناء تنفيذ استعلام عن بُعد. مُفعّل افتراضيًا.

automatic_parallel_replicas_min_bytes_per_replica

عتبة عدد البايتات المطلوب قراءتها لكل نسخة متماثلة لتمكين النسخ المتماثلة المتوازية تلقائيًا (ينطبق ذلك فقط عندما تكون automatic_parallel_replicas_mode=1). وتعني القيمة 0 عدم وجود عتبة. يُقدَّر العدد الإجمالي للبايتات المطلوب قراءتها استنادًا إلى الإحصاءات المُجمَّعة.

automatic_parallel_replicas_mode

يُمكّن من التبديل تلقائيًا إلى التنفيذ باستخدام النسخ المتماثلة المتوازية استنادًا إلى الإحصاءات المُجمَّعة. يتطلب enable_analyzer = 1 وenable_parallel_replicas != 0 وparallel_replicas_local_plan = 1 مع تحديد cluster_for_parallel_replicas. 0 - معطّل، 1 - مفعّل، 2 - يكون جمع الإحصاءات فقط مفعّلًا (ويكون التبديل إلى التنفيذ باستخدام النسخ المتماثلة المتوازية معطّلًا).

azure_allow_parallel_part_upload

استخدم سلاسل تنفيذ متعددة للرفع متعدد الأجزاء في Azure.

azure_check_objects_after_upload

تحقّق من كل كائن تم رفعه إلى Azure blob storage للتأكد من نجاح عملية الرفع

azure_connect_timeout_ms

مهلة الاتصال بالمضيف لأقراص Azure.

azure_create_new_file_on_insert

يتيح تمكين أو تعطيل إنشاء ملف جديد مع كل عملية إدراج في جداول محرك Azure

azure_ignore_file_doesnt_exist

تجاهل عدم وجود الملف عند قراءة مفاتيح معيّنة إذا لم يكن موجودًا. القيم الممكنة:

1 — يعيد SELECT نتيجة فارغة.
0 — يثير SELECT استثناءً.

azure_list_object_keys_size

الحد الأقصى لعدد الملفات التي يمكن أن يُرجعها طلب ListObject دفعةً واحدة

azure_max_blocks_in_multipart_upload

الحد الأقصى لعدد الكتل في الرفع متعدد الأجزاء في Azure.

azure_max_get_burst

الحد الأقصى لعدد الطلبات التي يمكن إرسالها بالتزامن قبل بلوغ حدّ الطلبات في الثانية. افتراضيًا، تكون القيمة (0) مساوية لـ azure_max_get_rps

azure_max_get_rps

الحد الأقصى لمعدل طلبات GET إلى Azure في الثانية قبل تطبيق تقييد المعدل. تعني القيمة 0 عدم وجود حد.

azure_max_inflight_parts_for_one_file

الحد الأقصى لعدد الأجزاء التي يتم تحميلها بالتوازي في طلب الرفع متعدد الأجزاء. 0 يعني عدم وجود حد.

azure_max_put_burst

الحد الأقصى لعدد الطلبات التي يمكن إرسالها في الوقت نفسه قبل بلوغ حد الطلبات في الثانية. افتراضيًا، تكون القيمة (0) مساوية لـ azure_max_put_rps

azure_max_put_rps

الحد الأقصى لمعدل طلبات PUT على Azure في الثانية قبل تطبيق تقييد المعدل. تعني القيمة 0 عدم وجود حد.

azure_max_redirects

الحد الأقصى المسموح به لعدد مرات إعادة التوجيه في Azure.

azure_max_single_part_copy_size

الحد الأقصى لحجم الكائن الذي يمكن نسخه إلى Azure blob storage باستخدام نسخ من جزء واحد.

azure_max_single_part_upload_size

الحد الأقصى لحجم الكائن الذي يمكن رفعه باستخدام رفع أحادي الجزء إلى Azure blob storage.

azure_max_single_read_retries

الحد الأقصى لعدد مرات إعادة المحاولة أثناء قراءة واحدة من Azure blob storage.

azure_max_unexpected_write_error_retries

الحد الأقصى لعدد محاولات إعادة المحاولة عند حدوث أخطاء غير متوقعة أثناء الكتابة إلى Azure blob storage

azure_max_upload_part_size

الحد الأقصى لحجم الجزء الذي سيتم رفعه أثناء الرفع متعدد الأجزاء إلى Azure blob storage.

azure_min_upload_part_size

الحد الأدنى لحجم الجزء المراد رفعه عند استخدام الرفع متعدد الأجزاء إلى Azure blob storage.

azure_request_timeout_ms

مهلة الخمول لإرسال البيانات إلى Azure واستقبالها منه. يفشل إذا ظلّت عملية قراءة أو كتابة واحدة عبر TCP محظورة لهذه المدة.

azure_sdk_max_retries

الحد الأقصى لعدد مرات إعادة المحاولة في azure sdk

azure_sdk_retry_initial_backoff_ms

الحد الأدنى لفاصل التراجع بين عمليات إعادة المحاولة في azure sdk

azure_sdk_retry_max_backoff_ms

الحد الأقصى لفترة التراجع بين مرات إعادة المحاولة في azure sdk

azure_skip_empty_files

يُفعّل أو يعطّل تجاوز الملفات الفارغة في محرك S3. القيم الممكنة:

0 — يُطلق SELECT استثناءً إذا كان الملف الفارغ غير متوافق مع التنسيق المطلوب.
1 — يعيد SELECT نتيجة فارغة للملف الفارغ.

azure_strict_upload_part_size

الحجم الدقيق للجزء المطلوب رفعه أثناء الرفع متعدد الأجزاء إلى Azure Blob Storage.

azure_throw_on_zero_files_match

يتم إصدار خطأ إذا لم تتم مطابقة أي ملفات وفقًا لقواعد توسيع glob. القيم الممكنة:

1 — يُطلق SELECT استثناءً.
0 — يعيد SELECT نتيجة فارغة.

azure_truncate_on_insert

يُمكّن أو يعطّل تنفيذ truncate قبل insert في جداول محرك Azure.

azure_upload_part_size_multiply_factor

اضرب azure_min_upload_part_size في هذا العامل كلما تم رفع azure_multiply_parts_count_threshold من الأجزاء من عملية كتابة واحدة إلى Azure Blob Storage.

azure_upload_part_size_multiply_parts_count_threshold

في كل مرة يُرفَع فيها هذا العدد من الأجزاء إلى Azure blob storage، تُضاعَف قيمة azure_min_upload_part_size بمعامل azure_upload_part_size_multiply_factor.

azure_use_adaptive_timeouts

عند ضبطها على true، تُجرى أول محاولتين لجميع طلبات Azure باستخدام مهلات إرسال واستقبال منخفضة. عند ضبطها على false، تُجرى جميع المحاولات باستخدام مهلات متطابقة.

backup_restore_batch_size_for_keeper_multi

الحد الأقصى لحجم الدفعة في طلب multi إلى [Zoo]Keeper أثناء النسخ الاحتياطي أو الاستعادة

backup_restore_batch_size_for_keeper_multiread

الحد الأقصى لحجم الدفعة في طلب القراءة المتعددة إلى [Zoo]Keeper أثناء النسخ الاحتياطي أو الاستعادة

backup_restore_failure_after_host_disconnected_for_seconds

إذا لم يُعِد أحد المضيفين، أثناء عملية BACKUP ON CLUSTER أو RESTORE ON CLUSTER، إنشاء عقدة ‘alive’ المؤقتة الخاصة به في ZooKeeper خلال هذه المدة، فستُعتبر عملية النسخ الاحتياطي أو الاستعادة بالكامل فاشلة. يجب أن تكون هذه القيمة أكبر من أي مدة معقولة قد يحتاجها المضيف لإعادة الاتصال بـ ZooKeeper بعد حدوث عطل. يعني الصفر عدم وجود حد.

backup_restore_finish_timeout_after_error_sec

المدة التي ينبغي أن ينتظرها initiator حتى تستجيب المضيفات الأخرى للعقدة ‘error’ وتتوقف عن العمل في عملية BACKUP ON CLUSTER أو RESTORE ON CLUSTER الحالية.

backup_restore_keeper_fault_injection_probability

الاحتمال التقريبي لفشل طلب Keeper أثناء إجراء النسخ الاحتياطي أو الاستعادة. تقع القيمة الصالحة ضمن النطاق [0.0f, 1.0f]

backup_restore_keeper_fault_injection_seed

0 - البذرة العشوائية، وإلا فتُستخدم قيمة الإعداد

backup_restore_keeper_max_retries

الحد الأقصى لعدد إعادة المحاولة لعمليات [Zoo]Keeper أثناء تنفيذ عملية BACKUP أو RESTORE. يجب أن تكون كبيرة بما يكفي حتى لا تفشل العملية بالكامل بسبب عطل مؤقت في [Zoo]Keeper.

backup_restore_keeper_max_retries_while_handling_error

الحد الأقصى لعدد إعادة المحاولة لعمليات [Zoo]Keeper عند معالجة خطأ في عملية BACKUP ON CLUSTER أو RESTORE ON CLUSTER.

backup_restore_keeper_max_retries_while_initializing

الحد الأقصى لمرات إعادة المحاولة لعمليات [Zoo]Keeper أثناء تهيئة عملية BACKUP ON CLUSTER أو RESTORE ON CLUSTER.

backup_restore_keeper_retry_initial_backoff_ms

مهلة التراجع الأولية لعمليات [Zoo]Keeper أثناء النسخ الاحتياطي أو الاستعادة

backup_restore_keeper_retry_max_backoff_ms

الحد الأقصى لمهلة التراجع لعمليات [Zoo]Keeper أثناء النسخ الاحتياطي أو الاستعادة Cloud default value: 60000.

backup_restore_keeper_value_max_size

الحد الأقصى لحجم البيانات لعقدة [Zoo]Keeper أثناء النسخ الاحتياطي

backup_restore_s3_retry_attempts

إعداد خاص بـ Aws::Client::RetryStrategy، إذ يتولى Aws::Client إعادة المحاولة بنفسه، وتشير القيمة 0 إلى عدم إجراء أي محاولات إعادة. وينطبق ذلك فقط على النسخ الاحتياطي/الاستعادة.

backup_restore_s3_retry_initial_backoff_ms

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

backup_restore_s3_retry_jitter_factor

معامل التذبذب المُطبَّق على زمن تأخير التراجع لإعادة المحاولة في Aws::Client::RetryStrategy أثناء عمليات النسخ الاحتياطي والاستعادة. يُضرَب زمن تأخير التراجع المحتسَب في عامل عشوائي ضمن النطاق [1.0, 1.0 + jitter]، حتى الحد الأقصى backup_restore_s3_retry_max_backoff_ms. يجب أن تكون قيمته ضمن النطاق [0.0, 1.0]

backup_restore_s3_retry_max_backoff_ms

الحد الأقصى للفاصل الزمني، بالمللي ثانية، بين عمليات إعادة المحاولة أثناء عمليات النسخ الاحتياطي والاستعادة.

backup_slow_all_threads_after_retryable_s3_error

عند ضبطه على true، يتم إبطاء جميع سلاسل التنفيذ التي تنفّذ طلبات S3 إلى نقطة نهاية النسخ الاحتياطي نفسها إذا واجه أي طلب S3 واحد خطأ S3 قابلاً لإعادة المحاولة، مثل ‘Slow Down’. وعند ضبطه على false، تتعامل كل سلسلة تنفيذ مع آلية التراجع لطلبات S3 بشكل مستقل عن سلاسل التنفيذ الأخرى.

cache_warmer_threads

لا يؤثر هذا الإعداد إلا في ClickHouse Cloud. عدد الخيوط الخلفية لتنزيل أجزاء البيانات الجديدة استباقيًا إلى ذاكرة التخزين المؤقت لنظام الملفات عند تمكين cache_populated_by_fetch. اضبط القيمة على صفر للتعطيل.

calculate_text_stack_trace

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

cancel_http_readonly_queries_on_client_close

يُلغي استعلامات HTTP المخصّصة للقراءة فقط (مثل SELECT) عند إغلاق العميل للاتصال دون انتظار الاستجابة. القيمة الافتراضية في Cloud: 1.

cast_ipv4_ipv6_default_on_conversion_error

سيُرجع عامل CAST إلى IPv4، وعامل CAST إلى النوع IPv6، والدالتان toIPv4 و toIPv6 القيمة الافتراضية بدلًا من إطلاق استثناء عند حدوث خطأ في التحويل.

cast_keep_nullable

يُفعِّل أو يعطّل الاحتفاظ بنوع البيانات Nullable في عمليات CAST. عند تمكين هذا الإعداد وكان وسيط الدالة CAST من النوع Nullable، تُحوَّل النتيجة أيضًا إلى النوع Nullable. وعند تعطيل هذا الإعداد، تكون النتيجة دائمًا من نوع الوجهة المحدد تمامًا. القيم الممكنة:

0 — تكون نتيجة CAST من نوع الوجهة المحدد تمامًا.
1 — إذا كان نوع الوسيط هو Nullable، فتُحوَّل نتيجة CAST إلى Nullable(DestinationDataType).

أمثلة يعطي الاستعلام التالي نوع بيانات الوجهة المحدد تمامًا:

SET cast_keep_nullable = 0;
SELECT CAST(toNullable(toInt32(0)) AS Int32) as x, toTypeName(x);

النتيجة:

┌─x─┬─toTypeName(CAST(toNullable(toInt32(0)), 'Int32'))─┐
│ 0 │ Int32                                             │
└───┴───────────────────────────────────────────────────┘

يؤدي الاستعلام التالي إلى تطبيق المُعدِّل Nullable على نوع بيانات الوجهة:

SET cast_keep_nullable = 1;
SELECT CAST(toNullable(toInt32(0)) AS Int32) as x, toTypeName(x);

النتيجة:

┌─x─┬─toTypeName(CAST(toNullable(toInt32(0)), 'Int32'))─┐
│ 0 │ Nullable(Int32)                                   │
└───┴───────────────────────────────────────────────────┘

انظر أيضًا

دالة CAST

cast_string_to_date_time_mode

يسمح باختيار محلّل للتمثيل النصي للتاريخ والوقت عند التحويل من String. القيم الممكنة:

'best_effort' — يفعّل التحليل الموسّع. يمكن لـ ClickHouse تحليل التنسيق الأساسي YYYY-MM-DD HH:MM:SS وجميع تنسيقات التاريخ والوقت وفق ISO 8601. على سبيل المثال، '2018-06-08T01:02:03.000Z'.
'best_effort_us' — مشابه لـ best_effort (راجع الفرق في parseDateTimeBestEffortUS
'basic' — يستخدم المحلّل الأساسي. لا يمكن لـ ClickHouse تحليل إلا التنسيق الأساسي YYYY-MM-DD HH:MM:SS أو YYYY-MM-DD. على سبيل المثال، 2019-08-20 10:18:56 أو 2019-08-20.

راجع أيضًا:

cast_string_to_dynamic_use_inference

استخدم استنتاج الأنواع أثناء تحويل String إلى Dynamic

cast_string_to_variant_use_inference

استخدم استنتاج الأنواع عند التحويل من String إلى Variant.

check_named_collection_dependencies

تحقّق من أن DROP NAMED COLLECTION لن يتسبب في تعطّل الجداول التي تعتمد عليها

check_query_single_value_result

يحدّد مستوى التفاصيل في نتيجة استعلام CHECK TABLE لمحركات عائلة MergeTree. القيم الممكنة:

0 — يعرض الاستعلام حالة التحقق لكل جزء بيانات على حدة في الجدول.
1 — يعرض الاستعلام الحالة العامة للتحقق من الجدول.

check_referential_table_dependencies

تحقّق من أن استعلام DDL (مثل DROP TABLE أو RENAME) لن يتسبب في تعطيل التبعيات المرجعية

check_table_dependencies

تحقّق من أن استعلام DDL (مثل DROP TABLE أو RENAME) لن يتسبب في تعطيل التبعيات

checksum_on_read

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

cloud_mode

وضع Cloud القيمة الافتراضية في Cloud: 1.

cloud_mode_database_engine

محرك قاعدة البيانات المسموح به في Cloud. 1 - تُعاد كتابة DDLs لاستخدام Replicated database، 2 - تُعاد كتابة DDLs لاستخدام Shared database القيمة الافتراضية في Cloud: 2.

cloud_mode_engine

عائلة المحركات المسموح بها في Cloud.

0 - السماح بكل شيء
1 - إعادة كتابة DDLs لاستخدام *ReplicatedMergeTree
2 - إعادة كتابة DDLs لاستخدام SharedMergeTree
3 - إعادة كتابة DDLs لاستخدام SharedMergeTree إلا عند تحديد قرص بعيد بشكل صريح
4 - مثل 3، مع استخدام Alias بدلًا من Distributed أيضًا (سيشير جدول Alias إلى الجدول الوجهة لجدول Distributed، لذا سيستخدم الجدول المحلي المقابل)

UInt64 لتقليل الجزء العام القيمة الافتراضية في Cloud: 2.

cluster_for_parallel_replicas

العنقود الخاص بـ shard الذي يقع فيه الخادم الحالي القيمة الافتراضية في Cloud: default.

cluster_function_process_archive_on_multiple_nodes

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

cluster_table_function_buckets_batch_size

يحدّد الحجم التقريبي للدفعة (بالبايت) المستخدمة في المعالجة الموزعة للمهام ضمن دوال الجداول الخاصة بالعنقود عند استخدام درجة تقسيم bucket. ويواصل النظام تجميع البيانات حتى يصل إلى هذا الحجم على الأقل. وقد يكون الحجم الفعلي أكبر قليلًا ليتوافق مع حدود البيانات.

cluster_table_function_split_granularity

يتحكم هذا الإعداد في كيفية تقسيم البيانات إلى مهام عند تنفيذ CLUSTER TABLE FUNCTION. يحدّد هذا الإعداد مستوى تفصيل توزيع العمل عبر العنقود:

file — تعالج كل مهمة ملفًا كاملًا.
bucket — تُنشأ المهام لكل كتلة بيانات داخلية داخل الملف (على سبيل المثال، مجموعات الصفوف في Parquet).

يمكن أن يؤدي اختيار مستوى تفصيل أدق (مثل bucket) إلى تحسين التوازي عند العمل على عدد صغير من الملفات الكبيرة. فعلى سبيل المثال، إذا كان ملف Parquet يحتوي على عدة مجموعات صفوف، فإن تفعيل مستوى bucket يتيح معالجة كل مجموعة بشكل مستقل بواسطة عمّال مختلفين.

collect_hash_table_stats_during_aggregation

فعّل جمع إحصاءات جدول التجزئة لتحسين تخصيص الذاكرة

collect_hash_table_stats_during_joins

تفعيل جمع إحصاءات جدول التجزئة لتحسين تخصيص الذاكرة

compatibility

يجعل الإعداد compatibility ClickHouse يستخدم الإعدادات الافتراضية لإصدار سابق من ClickHouse، على أن يُحدَّد ذلك الإصدار السابق من خلال هذا الإعداد. إذا كانت بعض الإعدادات مضبوطة على قيم غير افتراضية، فستظل هذه القيم مُعتمدة (ولا يؤثر الإعداد compatibility إلا في الإعدادات التي لم تُعدَّل). يأخذ هذا الإعداد رقم إصدار ClickHouse كسلسلة نصية، مثل 22.3 و22.8. وتعني القيمة الفارغة أن هذا الإعداد معطّل. يكون معطّلًا افتراضيًا.

في ClickHouse Cloud، يجب أن يضبط فريق ClickHouse Cloud Support إعداد compatibility الافتراضي على مستوى الخدمة. يُرجى فتح طلب دعم ليتم ضبطه. ومع ذلك، يمكن تجاوز إعداد compatibility على مستوى المستخدم أو الدور أو profile أو query أو session باستخدام آليات إعدادات ClickHouse القياسية، مثل SET compatibility = '22.3' داخل session أو SETTINGS compatibility = '22.3' داخل query.

compatibility_ignore_auto_increment_in_create_table

تجاهل الكلمة المفتاحية AUTO_INCREMENT في تعريف العمود إذا كانت القيمة true، وإلا فأعِد error. يسهّل ذلك الترحيل من MySQL

compatibility_ignore_collation_in_create_table

التوافق: تجاهل Collation في CREATE TABLE

compatibility_s3_presigned_url_query_in_path

التوافق: عند التمكين، تُضمَّن معلمات استعلام URL الموقَّعة مسبقًا (مثل X-Amz-*) في مفتاح S3 (السلوك القديم)، بحيث تعمل ’?’ كمحرف بدل في المسار. وعند التعطيل (وهو الوضع الافتراضي)، تُحفَظ معلمات استعلام URL الموقَّعة مسبقًا في جزء الاستعلام من URL لتجنّب تفسير ’?’ على أنه محرف بدل.

compile_aggregate_expressions

يُفعِّل أو يُعطِّل الترجمة الفورية (JIT) للدوال التجميعية إلى شيفرة أصلية. يمكن أن يؤدي تفعيل هذا الإعداد إلى تحسين الأداء. القيم الممكنة:

0 — يُجرى التجميع دون ترجمة فورية (JIT).
1 — يُجرى التجميع باستخدام الترجمة الفورية (JIT).

راجع أيضًا

min_count_to_compile_aggregate_expression

compile_expressions

ترجمة بعض الدوال القيَمية والمعاملات إلى شيفرة أصلية.

compile_sort_description

ترجمة وصف الفرز إلى شيفرة أصلية.

connect_timeout

مهلة الاتصال عند عدم وجود نُسخ متماثلة.

connect_timeout_with_failover_ms

المهلة، بالميلي ثانية، للاتصال بخادم بعيد باستخدام محرك الجدول Distributed، إذا استُخدم القسمان ‘shard’ و ‘replica’ في تعريف العنقود. إذا لم تنجح المحاولة، تُجرى عدة محاولات للاتصال بنسخ متماثلة مختلفة.

connect_timeout_with_failover_secure_ms

مهلة الاتصال لاختيار أول نسخة متماثلة سليمة في الاتصالات الآمنة.

connection_pool_max_wait_ms

مدة الانتظار بالمللي ثانية للحصول على اتصال عندما يكون مجمع الاتصالات ممتلئًا. القيم الممكنة:

عدد صحيح موجب.
0 — مهلة غير محدودة.

connections_with_failover_max_tries

الحد الأقصى لعدد محاولات الاتصال مع كل نسخة متماثلة في محرك الجدول Distributed.

convert_query_to_cnf

عند ضبطه على true، سيُحوَّل استعلام SELECT إلى الصيغة العادية الاقترانية (CNF). في بعض الحالات، قد يؤدّي إعادة كتابة الاستعلام بهذه الصيغة إلى تنفيذ أسرع (راجِع issue على GitHub للاطلاع على الشرح). على سبيل المثال، لاحظ كيف لا يجري تعديل استعلام SELECT التالي (وهذا هو السلوك الافتراضي):

EXPLAIN SYNTAX
SELECT *
FROM
(
    SELECT number AS x
    FROM numbers(20)
) AS a
WHERE ((x >= 1) AND (x <= 5)) OR ((x >= 10) AND (x <= 15))
SETTINGS convert_query_to_cnf = false;

النتيجة هي:

┌─explain────────────────────────────────────────────────────────┐
│ SELECT x                                                       │
│ FROM                                                           │
│ (                                                              │
│     SELECT number AS x                                         │
│     FROM numbers(20)                                           │
│     WHERE ((x >= 1) AND (x <= 5)) OR ((x >= 10) AND (x <= 15)) │
│ ) AS a                                                         │
│ WHERE ((x >= 1) AND (x <= 5)) OR ((x >= 10) AND (x <= 15))     │
│ SETTINGS convert_query_to_cnf = 0                              │
└────────────────────────────────────────────────────────────────┘

لنضبط convert_query_to_cnf على true ونرَ ما الذي سيتغيّر:

EXPLAIN SYNTAX
SELECT *
FROM
(
    SELECT number AS x
    FROM numbers(20)
) AS a
WHERE ((x >= 1) AND (x <= 5)) OR ((x >= 10) AND (x <= 15))
SETTINGS convert_query_to_cnf = true;

لاحظ أن عبارة WHERE أُعيدت كتابتها بصيغة CNF، لكن مجموعة النتائج متطابقة تمامًا - والمنطق البولياني لم يتغير:

┌─explain───────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ SELECT x                                                                                                              │
│ FROM                                                                                                                  │
│ (                                                                                                                     │
│     SELECT number AS x                                                                                                │
│     FROM numbers(20)                                                                                                  │
│     WHERE ((x <= 15) OR (x <= 5)) AND ((x <= 15) OR (x >= 1)) AND ((x >= 10) OR (x <= 5)) AND ((x >= 10) OR (x >= 1)) │
│ ) AS a                                                                                                                │
│ WHERE ((x >= 10) OR (x >= 1)) AND ((x >= 10) OR (x <= 5)) AND ((x <= 15) OR (x >= 1)) AND ((x <= 15) OR (x <= 5))     │
│ SETTINGS convert_query_to_cnf = 1                                                                                     │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

القيم الممكنة: true, false

correlated_subqueries_default_join_kind

يتحكم في نوع عمليات JOIN في خطة الاستعلام بعد فك الارتباط. القيمة الافتراضية هي right، ما يعني أن الخطة بعد فك الارتباط ستتضمن عمليات RIGHT JOIN مع إدخال الاستعلام الفرعي على الجانب الأيمن. القيم الممكنة:

left - ستنتج عملية فك الارتباط عمليات LEFT JOIN، وسيظهر جدول الإدخال على الجانب الأيسر.
right - ستنتج عملية فك الارتباط عمليات RIGHT JOIN، وسيظهر جدول الإدخال على الجانب الأيمن.

correlated_subqueries_substitute_equivalent_expressions

استخدم تعبيرات التصفية لاستنباط التعبيرات المكافئة واستبدالها بها بدلًا من إنشاء CROSS JOIN.

correlated_subqueries_use_in_memory_buffer

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

count_distinct_implementation

يحدّد أيًّا من دوال uniq* يجب استخدامه لتنفيذ صيغة COUNT(DISTINCT …). القيم الممكنة:

count_distinct_optimization

تحويل count distinct إلى استعلام فرعي مع group by

count_matches_stop_at_empty_match

توقّف عن العدّ بمجرد أن يطابق النمط طولًا صفريًا في الدالة countMatches.

create_if_not_exists

فعِّل IF NOT EXISTS لعبارة CREATE افتراضيًا. إذا تم تحديد هذا الإعداد أو IF NOT EXISTS وكان هناك جدول بالاسم المحدد موجودًا بالفعل، فلن يتم طرح أي استثناء.

create_index_ignore_unique

تجاهل الكلمة المفتاحية UNIQUE في CREATE UNIQUE INDEX. مخصص لاختبارات التوافق مع SQL.

create_replicated_merge_tree_fault_injection_probability

احتمال حقن عطل أثناء إنشاء الجدول بعد إنشاء البيانات الوصفية في ZooKeeper

create_table_empty_primary_key_by_default

السماح بإنشاء جداول *MergeTree بمفتاح أساسي فارغ عند عدم تحديد ORDER BY وPRIMARY KEY

cross_join_min_bytes_to_compress

الحد الأدنى لحجم الكتلة المطلوب لضغطها في CROSS JOIN. وتعني القيمة صفر تعطيل هذه العتبة. وتُضغط هذه الكتلة عند بلوغ أيٍّ من العتبتين (بحسب الصفوف أو البايتات).

cross_join_min_rows_to_compress

الحد الأدنى لعدد الصفوف المطلوب لضغط الكتلة في CROSS JOIN. تعني القيمة صفر تعطيل هذه العتبة. تُضغط هذه الكتلة عند الوصول إلى أيٍّ من العتبتين (بحسب الصفوف أو البايتات).

cross_to_inner_join_rewrite

استخدم inner join بدلًا من comma/cross join إذا كانت هناك تعبيرات ربط في قسم WHERE. القيم: 0 - بلا إعادة كتابة، 1 - يُطبَّق عند الإمكان على comma/cross، 2 - فرض إعادة كتابة جميع عمليات comma join، وcross join عند الإمكان

data_type_default_nullable

يجعل أنواع البيانات التي لا تحتوي على المعدِّلات الصريحة NULL or NOT NULL في تعريف العمود من النوع Nullable. القيم الممكنة:

1 — تُضبط أنواع البيانات في تعريفات الأعمدة على Nullable افتراضيًا.
0 — تُضبط أنواع البيانات في تعريفات الأعمدة على أنها غير Nullable افتراضيًا.

database_atomic_wait_for_drop_and_detach_synchronously

يضيف المُعدِّل SYNC إلى جميع استعلامات DROP وDETACH. القيم الممكنة:

0 — ستُنفَّذ الاستعلامات مع تأخير.
1 — ستُنفَّذ الاستعلامات من دون تأخير.

database_datalake_require_metadata_access

ما إذا كان سيتم طرح خطأ أم لا إذا لم تكن لدينا صلاحيات الوصول إلى البيانات الوصفية للجدول في محرك قاعدة البيانات DataLakeCatalog.

database_replicated_allow_explicit_uuid

0 - لا تسمح بالتحديد الصريح لـ UUID للجداول في قواعد بيانات Replicated. 1 - اسمح بذلك. 2 - اسمح بذلك، ولكن تجاهل UUID المحدَّد وأنشئ بدلًا منه واحدًا عشوائيًا.

database_replicated_allow_heavy_create

يسمح باستعلامات DDL طويلة التشغيل (CREATE AS SELECT و POPULATE) في محرك قاعدة البيانات Replicated. لاحظ أن ذلك قد يؤدي إلى حظر قائمة انتظار DDL لفترة طويلة.

database_replicated_allow_only_replicated_engine

يسمح بإنشاء جداول Replicated فقط في قاعدة بيانات تستخدم المحرك Replicated القيمة الافتراضية في Cloud: 1.

database_replicated_allow_replicated_engine_arguments

0 - عدم السماح بتحديد مسار ZooKeeper واسم النسخة المتماثلة صراحةً لِجداول *MergeTree في قواعد بيانات Replicated. 1 - السماح بذلك. 2 - السماح بذلك، مع تجاهل المسار المحدد واستخدام المسار الافتراضي بدلًا منه. 3 - السماح بذلك وعدم تسجيل تحذير.

database_replicated_always_detach_permanently

نفّذ DETACH TABLE كأنه DETACH TABLE PERMANENTLY إذا كان محرك قاعدة البيانات هو Replicated

database_replicated_enforce_synchronous_settings

يفرض الانتظار المتزامن لبعض الاستعلامات (انظر أيضًا: database_atomic_wait_for_drop_and_detach_synchronously و mutations_sync و alter_sync). لا يُنصح بتمكين هذه الإعدادات.

database_replicated_initial_query_timeout_sec

يحدّد المدة، بالثواني، التي ينبغي أن ينتظرها استعلام DDL الأولي حتى تعالج قاعدة بيانات Replicated عناصر قائمة انتظار DDL السابقة. القيم الممكنة:

عدد صحيح موجب.
0 — غير محدود.

database_shared_drop_table_delay_seconds

مدة التأخير، بالثواني، قبل إزالة الجدول المحذوف فعليًا من قاعدة بيانات Shared. يتيح ذلك استعادة الجدول خلال هذه المدة باستخدام عبارة UNDROP TABLE.

decimal_check_overflow

التحقق من تجاوز السعة في عمليات الحساب/المقارنة للأعداد العشرية

deduplicate_blocks_in_dependent_materialized_views

يُفعِّل أو يعطِّل فحص إزالة التكرار للعروض المُجسَّدة التي تتلقى البيانات من جداول Replicated*. القيم الممكنة: 0 — معطَّل. 1 — مفعَّل. عند التفعيل، يُجري ClickHouse إزالة تكرار للكتل في العروض المُجسَّدة التي تعتمد على جداول Replicated*. ويُعد هذا الإعداد مفيدًا لضمان عدم احتواء العروض المُجسَّدة على بيانات مكررة عند إعادة محاولة عملية الإدراج بسبب حدوث فشل. انظر أيضًا

معالجة NULL في عوامل التشغيل IN

deduplicate_insert

يُفعّل هذا الإعداد أو يعطّل إزالة تكرار الكتل لعبارة INSERT INTO (لجداول Replicated*). ويتجاوز هذا الإعداد كلاً من insert_deduplicate وasync_insert_deduplicate. ولهذا الإعداد ثلاث قيم ممكنة:

disable — تكون إزالة التكرار معطّلة لعبارة INSERT INTO.
enable — تكون إزالة التكرار مفعّلة لعبارة INSERT INTO.
backward_compatible_choice — تُفعَّل إزالة التكرار إذا كان insert_deduplicate أو async_insert_deduplicate مفعّلًا لنوع insert المحدد.

deduplicate_insert_select

يُمكّن هذا الإعداد أو يعطّل إزالة التكرار للكتل في INSERT SELECT (لجداول Replicated*). ويتجاوز insert_deduplicate و deduplicate_insert في استعلامات INSERT SELECT. ولهذا الإعداد أربع قيم ممكنة:

disable — يتم تعطيل إزالة التكرار لاستعلام INSERT SELECT.
force_enable — يتم تمكين إزالة التكرار لاستعلام INSERT SELECT. إذا لم تكن نتيجة SELECT مستقرة، يتم إطلاق استثناء.
enable_when_possible — يتم تمكين إزالة التكرار إذا كان insert_deduplicate مُمكّنًا وكانت نتيجة SELECT مستقرة، وإلا يتم تعطيله.
enable_even_for_bad_queries - يتم تمكين إزالة التكرار إذا كان insert_deduplicate مُمكّنًا. وإذا لم تكن نتيجة SELECT مستقرة، يُسجَّل تحذير، لكن يُنفَّذ الاستعلام مع إزالة التكرار. هذا الخيار مخصّص للتوافق مع الإصدارات السابقة. يُنصح باستخدام خيارات أخرى بدلًا منه لأنه قد يؤدي إلى نتائج غير متوقعة.

default_materialized_view_sql_security

يسمح بتحديد قيمة افتراضية لخيار SQL SECURITY عند إنشاء عرض مُجسَّد. مزيد من المعلومات حول SQL security. القيمة الافتراضية هي DEFINER.

default_max_bytes_in_join

الحد الأقصى لحجم الجدول في الجانب الأيمن إذا كان مطلوبًا فرض حدّ، ولكن لم يتم تعيين max_bytes_in_join.

default_normal_view_sql_security

يتيح تعيين الخيار الافتراضي SQL SECURITY عند إنشاء normal view. المزيد حول SQL security. القيمة الافتراضية هي INVOKER.

default_table_engine

محرّك الجدول الافتراضي المُستخدَم عند عدم تعيين ENGINE في عبارة CREATE. القيم الممكنة:

سلسلة تمثل أي اسم صالح لمحرّك جدول

القيمة الافتراضية في Cloud: SharedMergeTree. مثال استعلام:

SET default_table_engine = 'Log';

SELECT name, value, changed FROM system.settings WHERE name = 'default_table_engine';

النتيجة:

┌─name─────────────────┬─value─┬─changed─┐
│ default_table_engine │ Log   │       1 │
└──────────────────────┴───────┴─────────┘

في هذا المثال، سيستخدم أي جدول جديد لا يحدِّد Engine محرك الجدول Log: الاستعلام:

CREATE TABLE my_table (
    x UInt32,
    y UInt32
);

SHOW CREATE TABLE my_table;

النتيجة:

┌─statement────────────────────────────────────────────────────────────────┐
│ CREATE TABLE default.my_table
(
    `x` UInt32,
    `y` UInt32
)
ENGINE = Log
└──────────────────────────────────────────────────────────────────────────┘

default_temporary_table_engine

مثل default_table_engine، ولكن للجداول المؤقتة. في هذا المثال، سيستخدم أي جدول مؤقت جديد لا يحدّد Engine محرك الجدول Log: الاستعلام:

SET default_temporary_table_engine = 'Log';

CREATE TEMPORARY TABLE my_table (
    x UInt32,
    y UInt32
);

SHOW CREATE TEMPORARY TABLE my_table;

النتيجة:

┌─statement────────────────────────────────────────────────────────────────┐
│ CREATE TEMPORARY TABLE default.my_table
(
    `x` UInt32,
    `y` UInt32
)
ENGINE = Log
└──────────────────────────────────────────────────────────────────────────┘

default_view_definer

يتيح تعيين خيار DEFINER الافتراضي عند إنشاء عرض. المزيد عن SQL security. القيمة الافتراضية هي CURRENT_USER.

defer_partition_pruning_after_final

عند تمكينه (وهو الإعداد الافتراضي)، يتم تخطي partition pruning لاستعلامات FINAL على الجداول التي لا تكون أعمدة مفتاح partition فيها جزءًا من مفتاح الفرز. وهذا هو السلوك الآمن من ناحية الصحة الذي قُدِّم في 26.3: إذ قد يحتاج FINAL إلى إزالة تكرار الصفوف التي تشترك في المفتاح الأساسي لكنها موجودة في partitions مختلفة، كما أن partition pruning قد يستبعد مثل هذه الصفوف بصمت من مدخلات إزالة التكرار. عند تعطيله، يُطبَّق partition pruning حتى مع FINAL، مما يعيد سلوك ما قبل 26.3. ويمكن أن يكون هذا أسرع بكثير للاستعلامات التي تحتوي على شروط WHERE على عمود partition، لكنه يكون صحيحًا فقط عندما يتعذر وجود صفوف لها المفتاح الأساسي نفسه في partitions مختلفة — مثلًا، جداول سجلات الأحداث التي يُضبط فيها عمود partition وقت الإدراج ولا يتغير أبدًا. لا يؤثر هذا الإعداد إلا في الجداول المُقسَّمة التي لا تكون أعمدة مفتاح partition فيها متضمَّنة ضمن مفتاح الفرز؛ أما بالنسبة إلى الجداول الأخرى فيُطبَّق partition pruning دائمًا. القيم الممكنة:

0 — تطبيق partition pruning قبل FINAL (سلوك ما قبل 26.3، أسرع لكنه غير آمن في الحالة العامة).
1 — تأجيل partition pruning إلى ما بعد FINAL (الافتراضي، آمن من ناحية الصحة).

delta_lake_enable_engine_predicate

يُمكّن من تشذيب البيانات الداخلي في delta-kernel.

delta_lake_enable_expression_visitor_logging

يُمكّن سجلات مستوى Test لزائر تعبيرات DeltaLake. وقد تكون هذه السجلات مطوّلة للغاية حتى بالنسبة إلى تسجيلات الاختبار.

delta_lake_insert_max_bytes_in_data_file

يحدّد حدًّا بالبايتات لملف بيانات واحد يتم إدراجه في Delta Lake.

delta_lake_insert_max_rows_in_data_file

يحدّد الحد الأقصى لعدد الصفوف في ملف بيانات واحد مُدرَج في delta lake.

delta_lake_log_metadata

يتيح تسجيل ملفات البيانات الوصفية الخاصة بـ delta lake في جدول النظام.

delta_lake_reload_schema_for_consistency

إذا كان مُمكّنًا، فسيُعاد تحميل المخطط من البيانات الوصفية لـ DeltaLake قبل تنفيذ كل استعلام لضمان الاتساق بين المخطط المستخدم أثناء تحليل الاستعلام والمخطط المستخدم أثناء التنفيذ.

delta_lake_snapshot_end_version

إصدار النهاية للقطة Delta Lake المطلوب قراءتها. تعني القيمة -1 قراءة أحدث إصدار (والقيمة 0 إصدار لقطة صالح).

delta_lake_snapshot_start_version

إصدار البداية للقطة Delta Lake المراد قراءتها. وتعني القيمة -1 قراءة أحدث إصدار (والقيمة 0 إصدار لقطة صالح).

delta_lake_snapshot_version

إصدار لقطة delta lake المطلوب قراءتها. تعني القيمة -1 قراءة أحدث إصدار (والقيمة 0 هي إصدار لقطة صالح).

delta_lake_throw_on_engine_predicate_error

يؤدي إلى إطلاق استثناء عند حدوث خطأ أثناء تحليل شرط المسح في delta-kernel.

describe_compact_output

إذا كانت القيمة true، فسيقتصر ناتج استعلام DESCRIBE على أسماء الأعمدة وأنواعها فقط

describe_include_subcolumns

يتيح وصف الأعمدة الفرعية في استعلام DESCRIBE. على سبيل المثال، عناصر Tuple أو الأعمدة الفرعية لأنواع البيانات Map وNullable وArray. القيم الممكنة:

0 — لا تُضمَّن الأعمدة الفرعية في استعلامات DESCRIBE.
1 — تُضمَّن الأعمدة الفرعية في استعلامات DESCRIBE.

مثال راجع مثالًا على عبارة DESCRIBE.

describe_include_virtual_columns

إذا كانت القيمة true، فستتضمّن نتيجة استعلام DESCRIBE الأعمدة الظاهرية للجدول

الصيغة

الصيغة التي ستُستخدم لتحليل الاستعلام

dictionary_use_async_executor

شغّل مسار معالجة لقراءة مصدر القاموس باستخدام عدة خيوط تنفيذ. لا تدعمه إلا القواميس التي تستخدم مصدر CLICKHOUSE محليًا.

dictionary_validate_primary_key_type

التحقق من نوع المفتاح الأساسي للقواميس. افتراضيًا، يُحوَّل نوع id في التخطيطات البسيطة ضمنيًا إلى UInt64.

distinct_overflow_mode

يحدّد ما يحدث عند تجاوز كمية البيانات أحد الحدود. القيم الممكنة:

throw: طرح استثناء (الافتراضي).
break: إيقاف تنفيذ الاستعلام وإرجاع النتيجة الجزئية، كما لو كانت البيانات المصدر قد نفدت.

distributed_aggregation_memory_efficient

ما إذا كان وضع توفير الذاكرة في التجميع الموزّع مُمكّنًا.

distributed_background_insert_batch

الأسماء البديلة: distributed_directory_monitor_batch_inserts يُمكّن أو يعطّل إرسال البيانات المُدرجة على دفعات. عند تمكين الإرسال على دفعات، يحاول محرك الجداول Distributed إرسال عدة ملفات من البيانات المُدرجة في عملية واحدة بدلًا من إرسالها كلًّا على حدة. ويُحسّن الإرسال على دفعات أداء العنقود من خلال الاستفادة بشكل أفضل من موارد الخادم والشبكة. القيم الممكنة:

1 — مُمكَّن.
0 — مُعطَّل.

distributed_background_insert_max_sleep_time_ms

أسماء بديلة: distributed_directory_monitor_max_sleep_time_ms أقصى فاصل زمني لإرسال البيانات بواسطة محرك الجدول Distributed. يحدّ من الزيادة الأُسّية للفاصل الزمني المضبوط في إعداد distributed_background_insert_sleep_time_ms. القيم الممكنة:

عدد صحيح موجب من المللي ثانية.

distributed_background_insert_sleep_time_ms

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

عدد صحيح موجب من المللي ثانية.

distributed_background_insert_split_batch_on_failure

الأسماء البديلة: distributed_directory_monitor_split_batch_on_failure يُمكّن/يعطّل تقسيم الدُفعات عند حدوث فشل. قد يفشل أحيانًا إرسال دفعة معيّنة إلى الشظية البعيدة بسبب مسار معالجة معقّد لاحقًا (مثل MATERIALIZED VIEW مع GROUP BY) نتيجة الخطأ Memory limit exceeded أو أخطاء مشابهة. في هذه الحالة، لن تفيد إعادة المحاولة (وقد يؤدي ذلك إلى تعطيل عمليات الإرسال الموزّعة لهذا الجدول)، لكن إرسال ملفات تلك الدفعة واحدًا تلو الآخر قد ينجح في تنفيذ INSERT. لذلك، فإن ضبط هذا الإعداد على 1 سيعطّل التجميع لهذه الدُفعات (أي سيعطّل مؤقتًا distributed_background_insert_batch للدُفعات الفاشلة). القيم الممكنة:

1 — مُمكّن.
0 — معطّل.

يؤثر هذا الإعداد أيضًا في الدُفعات التالفة (التي قد تظهر بسبب توقّف غير طبيعي لـ server (الجهاز)، مع عدم استخدام fsync_after_insert/fsync_directories لمحرك الجداول Distributed).

يجب ألا تعتمد على التقسيم التلقائي للدُفعات، لأن ذلك قد يضر بالأداء.

distributed_background_insert_timeout

الأسماء البديلة: insert_distributed_timeout المهلة الزمنية لاستعلام الإدراج إلى Distributed. لا يُستخدم هذا الإعداد إلا عند تمكين insert_distributed_sync. وتعني القيمة صفر عدم وجود مهلة.

distributed_cache_alignment

لا يكون لهذا الإعداد أي تأثير إلا في ClickHouse Cloud. هذا إعداد مخصّص لأغراض الاختبار، فلا تغيّره.

distributed_cache_bypass_connection_pool

لا يكون له تأثير إلا في ClickHouse Cloud. يسمح بتجاوز مجمع اتصالات distributed cache

distributed_cache_connect_backoff_max_ms

لا يكون له تأثير إلا في ClickHouse Cloud. الحد الأقصى لمدة backoff، بالمللي ثانية، عند إنشاء اتصال بـ distributed cache.

distributed_cache_connect_backoff_min_ms

لا يكون له تأثير إلا في ClickHouse Cloud. الحد الأدنى لمدة التراجع بالمللي ثانية عند إنشاء اتصال distributed cache.

distributed_cache_connect_max_tries

لا يكون له تأثير إلا في ClickHouse Cloud. عدد محاولات الاتصال بـ distributed cache عند فشل الاتصال

distributed_cache_connect_timeout_ms

لا يكون له تأثير إلا في ClickHouse Cloud. مهلة الاتصال عند الاتصال بخادم distributed cache.

distributed_cache_credentials_refresh_period_seconds

لا يكون له تأثير إلا في ClickHouse Cloud. الفترة الزمنية لتحديث بيانات الاعتماد.

distributed_cache_data_packet_ack_window

لا يكون له تأثير إلا في ClickHouse Cloud. نافذة لإرسال ACK لتسلسل DataPacket ضمن طلب قراءة واحد لـ distributed cache

distributed_cache_discard_connection_if_unread_data

لا يكون له تأثير إلا في ClickHouse Cloud. تجاهل الاتصال إذا كانت هناك بيانات غير مقروءة.

distributed_cache_fetch_metrics_only_from_current_az

لا يكون له تأثير إلا في ClickHouse Cloud. يجلب المقاييس من منطقة التوافر الحالية فقط في system.distributed_cache_metrics و system.distributed_cache_events

distributed_cache_file_cache_name

لا يكون له تأثير إلا في ClickHouse Cloud. إعداد يُستخدم فقط في اختبارات CI: اسم ذاكرة التخزين المؤقت لنظام الملفات الذي سيُستخدم لـ distributed cache.

distributed_cache_log_mode

لا يكون لهذا الإعداد تأثير إلا في ClickHouse Cloud. وضع الكتابة في system.distributed_cache_log

distributed_cache_max_unacked_inflight_packets

لا يكون له تأثير إلا في ClickHouse Cloud. الحد الأقصى لعدد الحزم غير المؤكَّد استلامها قيد النقل في طلب قراءة واحد لـ distributed cache

distributed_cache_min_bytes_for_seek

لا يكون له تأثير إلا في ClickHouse Cloud. الحد الأدنى لعدد البايتات اللازمة لإجراء seek في distributed cache.

distributed_cache_pool_behaviour_on_limit

لا يكون له تأثير إلا في ClickHouse Cloud. يحدّد سلوك اتصال distributed cache عند بلوغ حدّ المجمّع

distributed_cache_prefer_bigger_buffer_size

لا يكون له تأثير إلا في ClickHouse Cloud. وهو مماثل لـ filesystem_cache_prefer_bigger_buffer_size، ولكن لـ distributed cache.

distributed_cache_read_only_from_current_az

لا يكون لهذا تأثير إلا في ClickHouse Cloud. يتيح القراءة فقط من منطقة التوافر الحالية. وإذا تم تعطيله، فستتم القراءة من جميع خوادم التخزين المؤقت في كل مناطق التوافر.

distributed_cache_read_request_max_tries

لا يكون له تأثير إلا في ClickHouse Cloud. عدد محاولات تنفيذ distributed cache read request عند فشله

distributed_cache_receive_response_wait_milliseconds

لا يكون له تأثير إلا في ClickHouse Cloud. مدة الانتظار، بالمللي ثانية، لتلقّي بيانات الطلب من distributed cache

distributed_cache_receive_timeout_milliseconds

لا يكون له تأثير إلا في ClickHouse Cloud. مدة الانتظار بالمللي ثانية لتلقّي أي نوع من الاستجابة من distributed cache القيمة الافتراضية في Cloud: 20000.

distributed_cache_receive_timeout_ms

لا يكون لهذا تأثير إلا في ClickHouse Cloud. هذه هي مهلة تلقّي البيانات من خادم distributed cache، بالمللي ثانية. وإذا لم يتم تلقّي أي بايتات خلال هذه المدة، فسيتم رفع استثناء.

distributed_cache_send_timeout_ms

لا يكون لهذا الإعداد تأثير إلا في ClickHouse Cloud. مهلة إرسال البيانات إلى خادم distributed cache، بالمللي ثانية. إذا احتاج العميل إلى إرسال بعض البيانات، لكنه لم يتمكن من إرسال أي بايتات خلال هذه المدة، يتم إطلاق استثناء.

distributed_cache_tcp_keep_alive_timeout_ms

لا يكون له تأثير إلا في ClickHouse Cloud. وهو الزمن، بالمللي ثانية، الذي يجب أن يبقى فيه الاتصال بخادم distributed cache في حالة خمول قبل أن يبدأ TCP بإرسال مجسات keepalive.

distributed_cache_throw_on_error

لا يكون لهذا الإعداد أي تأثير إلا في ClickHouse Cloud. أعِد إطلاق الاستثناء الذي يحدث أثناء الاتصال بـ distributed cache أو الاستثناء الوارد من distributed cache. وإلا فانتقل إلى تخطي distributed cache عند حدوث خطأ

distributed_cache_use_clients_cache_for_read

لا يكون له تأثير إلا في ClickHouse Cloud. استخدم ذاكرة التخزين المؤقت للعملاء لطلبات القراءة.

distributed_cache_use_clients_cache_for_write

لا يكون له تأثير إلا في ClickHouse Cloud. استخدم ذاكرة التخزين المؤقت للعملاء لطلبات الكتابة.

distributed_cache_wait_connection_from_pool_milliseconds

لا يكون لهذا تأثير إلا في ClickHouse Cloud. مدة الانتظار بالمللي ثانية للحصول على اتصال من مجمع الاتصالات إذا كانت distributed_cache_pool_behaviour_on_limit مضبوطة على wait

distributed_cache_write_request_max_tries

يؤثر فقط في ClickHouse Cloud. عدد محاولات تنفيذ طلب كتابة إلى distributed cache عند الإخفاق

distributed_connections_pool_size

الحد الأقصى لعدد الاتصالات المتزامنة مع الخوادم البعيدة للمعالجة الموزعة لجميع الاستعلامات على جدول Distributed واحد. نوصي بتعيين قيمة لا تقل عن عدد الخوادم في العنقود.

distributed_ddl_entry_format_version

إصدار التوافق لاستعلامات DDL الموزّع ‏(ON CLUSTER) الموزعة القيمة الافتراضية في Cloud: 6.

distributed_ddl_output_mode

يضبط تنسيق نتيجة استعلام DDL الموزّع. القيم الممكنة:

throw — يعيد مجموعة النتائج مع حالة تنفيذ الاستعلام على جميع المضيفين التي اكتمل عليها الاستعلام. إذا فشل الاستعلام على بعض المضيفين، فستُعاد إثارة أول استثناء. وإذا لم يكتمل الاستعلام بعد على بعض المضيفين وتم تجاوز distributed_ddl_task_timeout، فسيَطرح الاستثناء TIMEOUT_EXCEEDED.
none — مشابه لـ throw، لكن استعلام DDL الموزّع لا يعيد أي مجموعة نتائج.
null_status_on_timeout — يعيد NULL كحالة تنفيذ في بعض صفوف مجموعة النتائج بدلًا من طرح TIMEOUT_EXCEEDED إذا لم يكتمل الاستعلام على المضيفين المعنيين.
never_throw — لا يطرح TIMEOUT_EXCEEDED ولا يعيد طرح الاستثناءات إذا فشل الاستعلام على بعض المضيفين.
none_only_active - مشابه لـ none، لكنه لا ينتظر النسخ المتماثلة غير النشطة لقاعدة البيانات Replicated. ملاحظة: مع هذا الوضع، يستحيل معرفة أن الاستعلام لم يُنفَّذ على بعض النسخ المتماثلة وسيُنفَّذ في الخلفية.
null_status_on_timeout_only_active — مشابه لـ null_status_on_timeout، لكنه لا ينتظر النسخ المتماثلة غير النشطة لقاعدة البيانات Replicated
throw_only_active — مشابه لـ throw، لكنه لا ينتظر النسخ المتماثلة غير النشطة لقاعدة البيانات Replicated

القيمة الافتراضية في Cloud: none_only_active.

distributed_ddl_task_timeout

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

عدد صحيح موجب.
0 — وضع غير متزامن.
عدد صحيح سالب — مهلة غير محدودة.

distributed_foreground_insert

الأسماء البديلة: insert_distributed_sync يُمكّن أو يعطّل الإدراج المتزامن للبيانات في جدول Distributed. بشكل افتراضي، عند إدراج البيانات في جدول Distributed، يرسل خادم ClickHouse البيانات إلى عُقد العنقود في وضع الخلفية. وعند ضبط distributed_foreground_insert=1، تُعالَج البيانات بشكل متزامن، ولا تنجح عملية INSERT إلا بعد حفظ جميع البيانات على جميع الشظايا (مع وجود نسخة متماثلة واحدة على الأقل لكل شظية إذا كانت قيمة internal_replication هي true). القيم الممكنة:

0 — تُدرَج البيانات في وضع الخلفية.
1 — تُدرَج البيانات في الوضع المتزامن.

قيمة Cloud الافتراضية: 1. انظر أيضًا

distributed_group_by_no_merge

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

0 — معطّل (تتم المعالجة النهائية للاستعلام على العقدة البادئة).
1 - لا تدمج حالات التجميع من خوادم مختلفة أثناء المعالجة الموزعة للاستعلامات (تتم معالجة الاستعلام بالكامل على الجزء، وتقوم العقدة البادئة فقط بتمرير البيانات)، ويمكن استخدامه عندما يكون من المؤكد أن المفاتيح تختلف بين الأجزاء المختلفة.
2 - مثل 1، ولكن يطبّق ORDER BY وLIMIT على العقدة البادئة (وهذا غير ممكن عندما تتم معالجة الاستعلام بالكامل على العقدة البعيدة، كما في distributed_group_by_no_merge=1) (ويمكن استخدامه مع الاستعلامات التي تتضمن ORDER BY و/أو LIMIT).

مثال

SELECT *
FROM remote('127.0.0.{2,3}', system.one)
GROUP BY dummy
LIMIT 1
SETTINGS distributed_group_by_no_merge = 1
FORMAT PrettyCompactMonoBlock

┌─dummy─┐
│     0 │
│     0 │
└───────┘

SELECT *
FROM remote('127.0.0.{2,3}', system.one)
GROUP BY dummy
LIMIT 1
SETTINGS distributed_group_by_no_merge = 2
FORMAT PrettyCompactMonoBlock

┌─dummy─┐
│     0 │
└───────┘

distributed_index_analysis

سيُوزَّع تحليل الفهرس الموزّع عبر النسخ المتماثلة. وهو مفيد مع التخزين المشترك والكميات الضخمة من البيانات في العنقود. يستخدم النسخ المتماثلة من cluster_for_parallel_replicas. انظر أيضًا

distributed_index_analysis_for_non_shared_merge_tree

فعّل تحليل الفهرس الموزّع حتى للمحركات غير SharedMergeTree (محرك سحابي فقط).

distributed_index_analysis_only_on_coordinator

إذا كان ممكّنًا، فسيُجرى تحليل الفهرس الموزّع على المنسّق فقط. يمنع هذا ظهور استعلامات متولّدة من نوع O(N^2) عندما يحتوي الشرط على استعلامات فرعية (مثل IN (SELECT ...))، لأنه لولا ذلك لكانت كل نسخة متماثلة تابعة تُفعّل تحليل الفهرس الموزّع الخاص بها بشكل مستقل، لكنه يجعل تحليل الفهرس الموزّع أقل كفاءة إذا استُخدمت جداول كبيرة في الاستعلامات الفرعية.

distributed_insert_skip_read_only_replicas

يُمكّن تجاوز النسخ المتماثلة المخصّصة للقراءة فقط في طلبات INSERT إلى Distributed. القيم الممكنة:

0 — سيعمل INSERT كالمعتاد، وإذا وُجِّه إلى نسخة متماثلة للقراءة فقط فسيفشل
1 — ستتجاوز العقدة المبادِرة النسخ المتماثلة المخصّصة للقراءة فقط قبل إرسال البيانات إلى الشظايا.

distributed_plan_default_reader_bucket_count

العدد الافتراضي للمهام اللازمة للقراءة المتوازية في الاستعلام الموزّع. تُوزَّع المهام بين النسخ المتماثلة.

distributed_plan_default_shuffle_join_bucket_count

العدد الافتراضي لـ buckets في distributed shuffle-hash-join.

distributed_plan_execute_locally

نفّذ جميع مهام خطة الاستعلام الموزع محليًا. يفيد ذلك في الاختبار واستكشاف الأخطاء وإصلاحها.

distributed_plan_force_exchange_kind

يفرض النوع المحدد من عوامل Exchange بين مراحل الاستعلام الموزّع. القيم الممكنة:

” - لا تفرض أي نوع من عوامل Exchange، واترك المُحسِّن يختار،
‘Persisted’ - استخدم ملفات مؤقتة في تخزين الكائنات،
‘Streaming’ - بثّ بيانات Exchange عبر الشبكة.

distributed_plan_force_shuffle_aggregation

استخدم استراتيجية Shuffle للتجميع بدلًا من PartialAggregation + Merge في خطة الاستعلام الموزّع.

distributed_plan_max_rows_to_broadcast

الحد الأقصى لعدد الصفوف الذي يُستخدم عنده broadcast join بدلًا من shuffle join في خطة الاستعلام الموزعة.

distributed_plan_optimize_exchanges

يزيل عمليات التبادل غير الضرورية في خطة الاستعلام الموزعة. عطِّله لأغراض تصحيح الأخطاء.

distributed_plan_prefer_replicas_over_workers

قم بتسلسل خطة الاستعلام الموزّع لتنفيذها على النسخ المتماثلة.

distributed_product_mode

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

يُطبَّق فقط على الاستعلامات الفرعية من نوع IN وJOIN.
فقط إذا كان قسم FROM يستخدم جدولًا موزعًا يحتوي على أكثر من شظية واحدة.
إذا كان الاستعلام الفرعي يتناول جدولًا موزعًا يحتوي على أكثر من شظية واحدة.
لا يُستخدم مع دالة remote الجدولية.

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

deny — القيمة الافتراضية. يمنع استخدام هذه الأنواع من الاستعلامات الفرعية (ويُرجع الاستثناء “Double-distributed in/JOIN subqueries is denied”).
local — يستبدل قاعدة البيانات والجدول في الاستعلام الفرعي بالنظيرين المحليين على خادم الوجهة (شظية)، مع الإبقاء على IN/JOIN العاديَّين.
global — يستبدل استعلام IN/JOIN بـ GLOBAL IN/GLOBAL JOIN.
allow — يسمح باستخدام هذه الأنواع من الاستعلامات الفرعية.

distributed_push_down_limit

يُمكّن أو يعطّل تطبيق LIMIT على كل شظية على حدة. يساعد ذلك على تجنّب ما يلي:

إرسال صفوف إضافية عبر الشبكة؛
معالجة الصفوف التي تتجاوز الحد على العقدة المُبادِئة.

اعتبارًا من الإصدار 21.9، لم يعد بالإمكان الحصول على نتائج غير دقيقة، لأن distributed_push_down_limit لا يغيّر تنفيذ الاستعلام إلا إذا تحقق شرط واحد على الأقل من الشروط التالية:

distributed_group_by_no_merge > 0.
لا يحتوي الاستعلام على GROUP BY/DISTINCT/LIMIT BY، لكنه يحتوي على ORDER BY/LIMIT.
يحتوي الاستعلام على GROUP BY/DISTINCT/LIMIT BY مع ORDER BY/LIMIT، و:
- يكون optimize_skip_unused_shards مُمكّنًا.
- يكون optimize_distributed_group_by_sharding_key مُمكّنًا.

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

0 — معطّل.
1 — مُمكّن.

انظر أيضًا:

distributed_group_by_no_merge
optimize_skip_unused_shards
optimize_distributed_group_by_sharding_key

distributed_replica_error_cap

النوع: عدد صحيح غير موقّع
القيمة الافتراضية: 1000

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

load_balancing
محرك الجدول Distributed
distributed_replica_error_half_life
distributed_replica_max_ignored_errors

distributed_replica_error_half_life

النوع: ثوانٍ
القيمة الافتراضية: 60 ثانية

يتحكم هذا الإعداد في مدى سرعة تصفير الأخطاء في الجداول الموزعة. إذا كانت إحدى النسخ المتماثلة غير متاحة لبعض الوقت، وتراكمت لها 5 أخطاء، وتم تعيين distributed_replica_error_half_life إلى ثانية واحدة، فستُعتبر هذه النسخة المتماثلة سليمة بعد 3 ثوانٍ من وقوع آخر خطأ. انظر أيضًا:

load_balancing
محرك الجدول Distributed
distributed_replica_error_cap
distributed_replica_max_ignored_errors

distributed_replica_max_ignored_errors

النوع: عدد صحيح غير موقّع
القيمة الافتراضية: 0

عدد الأخطاء التي سيجري تجاهلها عند اختيار النسخ المتماثلة (وفقًا لخوارزمية load_balancing). انظر أيضًا:

load_balancing
محرك الجدول Distributed
distributed_replica_error_cap
distributed_replica_error_half_life

do_not_merge_across_partitions_select_final

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

dynamic_disk_allow_from_env

يسمح باستخدام عمليات الاستبدال from_env في تكوين القرص الديناميكي (أي في وسائط الدالة disk()). وهو معطّل افتراضيًا لمنع المستخدمين من قراءة متغيرات بيئة اعتباطية عند تعريف تخزين الجدول.”

dynamic_disk_allow_from_zk

السماح باستخدام استبدالات from_zk في تكوين القرص الديناميكي (أي في وسيطات الدالة disk()). معطّل افتراضيًا.

dynamic_disk_allow_include

يتيح استخدام include في تكوين القرص الديناميكي (أي في وسيطات الدالة disk()). وهو معطّل افتراضيًا.

dynamic_throw_on_type_mismatch

عند تطبيق دالة على عمود Dynamic باستخدام التنفيذ الافتراضي، يحدّد هذا الإعداد ما يحدث للصفوف التي يكون نوعها الفعلي غير متوافق مع الدالة:

true (الافتراضي) — طرح استثناء.
false — إرجاع NULL لهذه الصفوف بدلًا من ذلك.

empty_result_for_aggregation_by_constant_keys_on_empty_set

إرجاع نتيجة فارغة عند إجراء التجميع حسب مفاتيح ثابتة على مجموعة فارغة.

empty_result_for_aggregation_by_empty_set

إرجاع نتيجة فارغة عند تنفيذ التجميع بدون مفاتيح على مجموعة فارغة.

enable_adaptive_memory_spill_scheduler

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

enable_add_distinct_to_in_subqueries

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

enable_automatic_decision_for_merging_across_partitions_for_final

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

enable_blob_storage_log

يكتب معلومات عن عمليات blob storage في جدول system.blob_storage_log

enable_blob_storage_log_for_read_operations

اكتب معلومات حول عمليات قراءة blob storage في جدول system.blob_storage_log. يتطلب أيضًا تفعيل enable_blob_storage_log.

enable_early_constant_folding

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

enable_extended_results_for_datetime_functions

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

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

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

Function	`enable_extended_results_for_datetime_functions = 0`	`enable_extended_results_for_datetime_functions = 1`
`toStartOfYear`	يعيد `Date` أو `DateTime`	يُرجع `Date`/`DateTime` عند إدخال `Date`/`DateTime` يُرجع `Date32`/`DateTime64` عند إدخال `Date32`/`DateTime64`
`toStartOfISOYear`	تُرجِع `Date` أو `DateTime`	يعيد `Date`/`DateTime` عند إدخال `Date`/`DateTime` يعيد `Date32`/`DateTime64` عند إدخال `Date32`/`DateTime64`
`toStartOfQuarter`	تُرجِع `Date` أو `DateTime`	تعيد `Date`/`DateTime` عند إدخال `Date`/`DateTime` تعيد `Date32`/`DateTime64` عند إدخال `Date32`/`DateTime64`
`toStartOfMonth`	يُرجع `Date` أو `DateTime`	تعيد `Date`/`DateTime` عند إدخال `Date`/`DateTime` تعيد `Date32`/`DateTime64` عند إدخال `Date32`/`DateTime64`
`toStartOfWeek`	تُرجِع `Date` أو `DateTime`	يعيد `Date`/`DateTime` عند تمرير قيمة من النوع `Date`/`DateTime` يعيد `Date32`/`DateTime64` عند تمرير قيمة من النوع `Date32`/`DateTime64`
`toLastDayOfWeek`	يُرجع `Date` أو `DateTime`	تُرجِع `Date`/`DateTime` عند إدخال `Date`/`DateTime` تُرجِع `Date32`/`DateTime64` عند إدخال `Date32`/`DateTime64`
`toLastDayOfMonth`	تُرجِع `Date` أو `DateTime`	يعيد `Date`/`DateTime` عند إدخال `Date`/`DateTime` يعيد `Date32`/`DateTime64` عند إدخال `Date32`/`DateTime64`
`toMonday`	يُرجِع `Date` أو `DateTime`	تعيد `Date`/`DateTime` عند إدخال `Date`/`DateTime` تعيد `Date32`/`DateTime64` عند إدخال `Date32`/`DateTime64`
`toStartOfDay`	يعيد `DateTime` ملاحظة: تكون النتائج غير صحيحة للقيم خارج النطاق 1970-2149	يعيد `DateTime` عند إدخال `Date`/`DateTime` ويعيد `DateTime64` عند إدخال `Date32`/`DateTime64`
`toStartOfHour`	يعيد `DateTime` ملاحظة: تكون النتائج غير صحيحة للقيم خارج نطاق 1970-2149.	يعيد `DateTime` عند إدخال `Date`/`DateTime` ويعيد `DateTime64` عند إدخال `Date32`/`DateTime64`
`toStartOfFifteenMinutes`	يعيد `DateTime` ملاحظة: تكون النتائج غير صحيحة للقيم خارج النطاق 1970-2149	تعيد `DateTime` عند إدخال `Date`/`DateTime` وتعيد `DateTime64` عند إدخال `Date32`/`DateTime64`
`toStartOfTenMinutes`	يُرجع `DateTime` ملاحظة: نتائج غير صحيحة للقيم الواقعة خارج النطاق 1970-2149	يُرجع `DateTime` عند إدخال `Date`/`DateTime` ويُرجع `DateTime64` عند إدخال `Date32`/`DateTime64`
`toStartOfFiveMinutes`	يعيد `DateTime` ملاحظة: تكون النتائج غير صحيحة للقيم خارج النطاق 1970-2149	تُرجِع `DateTime` لمدخلات `Date`/`DateTime` وتُرجِع `DateTime64` لمدخلات `Date32`/`DateTime64`
`toStartOfMinute`	يعيد `DateTime` ملاحظة: قد تكون النتائج غير صحيحة للقيم خارج النطاق 1970-2149	يعيد `DateTime` عند إدخال `Date`/`DateTime` ويعيد `DateTime64` عند إدخال `Date32`/`DateTime64`
`timeSlot`	يعيد `DateTime` ملاحظة: تكون النتائج غير صحيحة للقيم الواقعة خارج النطاق 1970-2149	يعيد `DateTime` عند إدخال `Date`/`DateTime` يعيد `DateTime64` عند إدخال `Date32`/`DateTime64`

enable_filesystem_cache

استخدم التخزين المؤقت لنظام الملفات البعيد. لا يؤدي هذا الإعداد إلى تشغيل/إيقاف التخزين المؤقت للأقراص (إذ يجب تنفيذ ذلك عبر إعدادات القرص)، لكنه يتيح تجاوز التخزين المؤقت لبعض الاستعلامات عند الحاجة.

enable_filesystem_cache_log

يتيح تسجيل سجل التخزين المؤقت لنظام الملفات لكل استعلام

enable_filesystem_cache_on_write_operations

يُفعِّل أو يعطِّل ذاكرة التخزين المؤقت write-through. إذا ضُبطت القيمة على false، فسيتم تعطيل ذاكرة التخزين المؤقت write-through لعمليات الكتابة. وإذا ضُبطت على true، فسيتم تفعيل ذاكرة التخزين المؤقت write-through طالما أن cache_on_write_operations مفعّل في قسم disk configuration الخاص بـ cache disk ضمن config الخادم. راجع “استخدام ذاكرة التخزين المؤقت المحلية” لمزيد من التفاصيل. القيمة الافتراضية في Cloud: 1.

enable_filesystem_read_prefetches_log

سجّل في system.filesystem‏ prefetch_log أثناء تنفيذ الاستعلام. يجب استخدامه للاختبار أو debugging فقط، ولا يُنصح بتفعيله افتراضيًا

enable_full_text_index

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

enable_global_with_statement

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

enable_hdfs_pread

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

enable_http_compression

يُفعِّل ضغط البيانات في الاستجابة لطلب HTTP أو يعطِّله. لمزيد من المعلومات، اطّلع على وصف واجهة HTTP. القيم الممكنة:

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

enable_identifier_resolve_cache

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

enable_job_stack_trace

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

enable_join_fixed_hash_table_conversion

تمكين تحويل جدول التجزئة إلى مصفوفة مسطحة لعمليات JOIN عندما يكون المفتاح عددًا صحيحًا واحدًا ضمن نطاق قيم صغير.

enable_join_runtime_filters

تصفية الجانب الأيسر استنادًا إلى مجموعة مفاتيح JOIN المُجمَّعة من الجانب الأيمن أثناء التشغيل.

enable_join_transitive_predicates

يستنتج شروط الربط الانتقالية بالمساواة من شروط الربط الحالية. على سبيل المثال، إذا كان لدينا A.x = B.x و B.x = C.x، فستُضاف عبارة شرطية مُولَّدة A.x = C.x لكي يتمكن مُحسِّن ترتيب الربط من النظر في خطط مباشرة من النوع (A JOIN C).

enable_lazy_columns_replication

يُمكّن النسخ المتماثل الكسول للأعمدة في JOIN و ARRAY JOIN، مما يساعد على تجنّب النسخ غير الضروري للصفوف نفسها عدة مرات في الذاكرة.

enable_lightweight_delete

الأسماء البديلة: allow_experimental_lightweight_delete تمكين طفرات DELETE خفيفة الوزن لجداول MergeTree.

enable_lightweight_update

الأسماء البديلة: allow_experimental_lightweight_update يسمح باستخدام التحديثات الخفيفة.

enable_materialized_cte

يُفعّل تعبيرات الجدول المشتركة المُجسَّدة، ويُفضَّل على enable_global_with_statement

enable_memory_bound_merging_of_aggregation_results

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

enable_multiple_prewhere_read_steps

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

enable_named_columns_in_function_tuple

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

enable_optimize_predicate_expression

يُفعّل تمرير شروط التصفية في استعلامات SELECT. قد يؤدي تمرير شروط التصفية إلى تقليل حركة مرور الشبكة بشكل كبير في الاستعلامات الموزعة. القيم الممكنة:

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

الاستخدام انظر إلى الاستعلامات التالية:

SELECT count() FROM test_table WHERE date = '2018-10-10'
SELECT count() FROM (SELECT * FROM test_table) WHERE date = '2018-10-10'

إذا كانت القيمة enable_optimize_predicate_expression = 1، فسيكون زمن تنفيذ هذين الاستعلامين متساويًا لأن ClickHouse يطبّق WHERE على الاستعلام الفرعي أثناء معالجته. إذا كانت القيمة enable_optimize_predicate_expression = 0، فسيكون زمن تنفيذ الاستعلام الثاني أطول بكثير لأن عبارة WHERE تُطبَّق على جميع البيانات بعد اكتمال الاستعلام الفرعي.

enable_optimize_predicate_expression_to_final_subquery

يسمح بدفع شرط التصفية إلى الاستعلام الفرعي FINAL.

enable_order_by_all

يُمكّن أو يعطّل الترتيب باستخدام صيغة 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 │
└────┴────┴─────┘

enable_parallel_blocks_marshalling

يؤثر هذا فقط في الاستعلامات الموزعة. إذا كان مُمكّنًا، فستُسلسَل الكتل/يُلغى تسلسلها وتُضغط/يُفك ضغطها على خيوط خط المعالجة (أي بدرجة توازٍ أعلى من الافتراضي) قبل إرسالها إلى العقدة البادئة/بعده.

enable_parsing_to_custom_serialization

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

enable_positional_arguments

يُمكّن أو يعطّل دعم الوسائط الموضعية في عبارات GROUP BY وLIMIT BY وORDER BY. القيم الممكنة:

0 — لا يتم دعم الوسائط الموضعية.
1 — يتم دعم الوسائط الموضعية: يمكن استخدام أرقام الأعمدة بدلًا من أسماء الأعمدة.

مثال الاستعلام:

CREATE TABLE positional_arguments(one Int, two Int, three Int) ENGINE=Memory();

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

SELECT * FROM positional_arguments ORDER BY 2,3;

النتيجة:

┌─one─┬─two─┬─three─┐
│  30 │  10 │   20  │
│  20 │  20 │   10  │
│  10 │  20 │   30  │
└─────┴─────┴───────┘

enable_positional_arguments_for_projections

يُفعِّل هذا الإعداد دعم الوسائط الموضعية في تعريفات PROJECTION أو يعطّله. راجع أيضًا الإعداد enable_positional_arguments.

هذا إعداد متقدم، ولا ينبغي تغييره إذا كنت لا تزال في بداية استخدام ClickHouse.

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

0 — الوسائط الموضعية غير مدعومة.
1 — الوسائط الموضعية مدعومة: يمكن استخدام أرقام الأعمدة بدلًا من أسماء الأعمدة.

enable_producing_buckets_out_of_order_in_aggregation

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

enable_reads_from_query_cache

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

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

enable_s3_requests_logging

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

enable_scalar_subquery_optimization

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

enable_scopes_for_with_statement

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

enable_sharding_aggregator

يمكّن تحسين GROUP BY المجزأ الذي يوزّع الصفوف على الخيوط باستخدام hash لمفتاح التجميع، بحيث يجمّع كل خيط مجموعة فرعية مستقلة من المفاتيح من دون مرحلة دمج. يكون ذلك فعّالًا للمفاتيح ذات الكاردينالية العالية مع البيانات الموزعة بالتساوي، لكنه قد يتأثر سلبًا عند وجود توزيعات شديدة الانحراف للمفاتيح أو استعلامات تتضمن عددًا قليلًا جدًا من المفاتيح المميزة. القيم الممكنة:

0 — تحسين التجميع المجزأ معطّل.
1 — تحسين التجميع المجزأ مفعّل.

enable_shared_storage_snapshot_in_query

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

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

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

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

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

0 - معطّل
1 - مُمكّن

enable_sharing_sets_for_mutations

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

enable_software_prefetch_in_aggregation

تمكين استخدام الجلب المسبق البرمجي في التجميع

enable_software_prefetch_in_join

تمكين استخدام الجلب المسبق البرمجي في مرحلة الفحص في hash join لإخفاء زمن الوصول إلى الذاكرة في جداول hash الكبيرة.

enable_streaming_queries

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

enable_time_time64_type

الأسماء البديلة: allow_experimental_time_time64_type يسمح بإنشاء نوعَي البيانات Time وTime64.

enable_unaligned_array_join

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

enable_url_encoding

يسمح بتمكين/تعطيل ترميز وفك ترميز المسار في uri في جداول محرك URL. يكون معطّلًا افتراضيًا.

enable_vertical_final

إذا كان مُمكّنًا، فأزل الصفوف المكررة أثناء FINAL من خلال وسم الصفوف بأنها محذوفة ثم تصفيتها لاحقًا بدلًا من دمجها

enable_writes_to_query_cache

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

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

enforce_strict_identifier_format

عند التمكين، لا يُسمح إلا بالمُعرّفات التي تحتوي على أحرف وأرقام وشرطات سفلية.

engine_file_allow_create_multiple_files

يُمكّن أو يعطّل إنشاء ملف جديد مع كل عملية insert في جداول محرك File إذا كان format يتضمن suffix (JSON، ORC، Parquet، إلخ). عند التمكين، يُنشأ ملف جديد مع كل عملية insert باسم يتبع هذا pattern: data.Parquet -> data.1.Parquet -> data.2.Parquet، وهكذا. القيم الممكنة:

0 — تقوم query ‏INSERT بإلحاق data جديدة بنهاية الملف.
1 — تقوم query ‏INSERT بإنشاء ملف جديد.

engine_file_empty_if_not_exists

يسمح باختيار البيانات من جدول بالمحرك File حتى في حال عدم وجود ملف. القيم الممكنة:

0 — SELECT يرفع استثناءً.
1 — SELECT يعيد نتيجة فارغة.

engine_file_skip_empty_files

يُفعّل أو يُعطّل تخطي الملفات الفارغة في جداول محرك File. القيم الممكنة:

0 — يُطلق SELECT استثناءً إذا كان الملف الفارغ غير متوافق مع التنسيق المطلوب.
1 — يعيد SELECT نتيجة فارغة عند وجود ملف فارغ.

engine_file_truncate_on_insert

يُفعّل أو يعطّل تنفيذ truncate قبل insert في جداول محرك File. القيم الممكنة:

0 — يُلحق استعلام INSERT البيانات الجديدة بنهاية الملف.
1 — يستبدل استعلام INSERT المحتوى الحالي للملف بالبيانات الجديدة.

engine_url_skip_empty_files

يتيح تفعيل أو تعطيل تخطي الملفات الفارغة في جداول محرك URL. القيم الممكنة:

0 — يُطلق SELECT استثناءً إذا كان الملف الفارغ غير متوافق مع التنسيق المطلوب.
1 — يعيد SELECT نتيجة فارغة للملف الفارغ.

exact_rows_before_limit

عند تمكين هذا الإعداد، سيوفّر ClickHouse قيمة دقيقة لإحصائية rows_before_limit_at_least، ولكن مقابل الاضطرار إلى قراءة البيانات قبل تطبيق الحد بالكامل

except_default_mode

يحدّد الوضع الافتراضي في استعلام EXCEPT. القيم الممكنة: سلسلة فارغة، و’ALL’، و’DISTINCT’. إذا كانت فارغة، فسيؤدي الاستعلام من دون وضع إلى إطلاق استثناء.

exclude_materialize_skip_indexes_on_insert

يستبعد فهارس التخطي المحددة من الإنشاء والتخزين أثناء عمليات INSERT. وستظل فهارس التخطي المستبعَدة تُنشأ وتُخزَّن أثناء عمليات الدمج أو عبر استعلام MATERIALIZE INDEX صريح. لا يكون لهذا أي تأثير إذا كانت materialize_skip_indexes_on_insert تساوي false. مثال:

CREATE TABLE tab
(
    a UInt64,
    b UInt64,
    INDEX idx_a a TYPE minmax,
    INDEX idx_b b TYPE set(3)
)
ENGINE = MergeTree ORDER BY tuple();

SET exclude_materialize_skip_indexes_on_insert='idx_a'; -- idx_a will be not be updated upon insert
--SET exclude_materialize_skip_indexes_on_insert='idx_a, idx_b'; -- neither index would be updated on insert

INSERT INTO tab SELECT number, number / 50 FROM numbers(100); -- only idx_b is updated

-- since it is a session setting it can be set on a per-query level
INSERT INTO tab SELECT number, number / 50 FROM numbers(100, 100) SETTINGS exclude_materialize_skip_indexes_on_insert='idx_b';

ALTER TABLE tab MATERIALIZE INDEX idx_a; -- this query can be used to explicitly materialize the index

SET exclude_materialize_skip_indexes_on_insert = DEFAULT; -- reset setting to default

execute_exists_as_scalar_subquery

نفِّذ الاستعلامات الفرعية EXISTS غير المرتبطة كاستعلامات فرعية قيمية. وكما في الاستعلامات الفرعية القيمية، تُستخدَم ذاكرة التخزين المؤقت ويُطبَّق طيّ الثوابت على النتيجة. القيمة الافتراضية في Cloud: 0.

external_storage_connect_timeout_sec

مهلة الاتصال بالثواني. وهو مدعوم حاليًا لـ MySQL فقط

external_storage_max_read_bytes

يحدّد الحد الأقصى لعدد البايتات عندما يتعيّن على جدول يستخدم محركًا خارجيًا تفريغ بيانات السجل التاريخي. وهو مدعوم حاليًا فقط لمحرك جدول MySQL ومحرك قاعدة البيانات والقاموس. إذا كانت القيمة تساوي 0، فسيتم تعطيل هذا الإعداد

external_storage_max_read_rows

يحدِّد الحد الأقصى لعدد الصفوف عندما يقوم جدول ذو محرك خارجي بتفريغ بيانات السجل التاريخي. وهو مدعوم حاليًا فقط لمحرك جدول MySQL ومحرك قاعدة البيانات والقاموس. إذا كانت القيمة تساوي 0، فسيتم تعطيل هذا الإعداد

external_storage_rw_timeout_sec

مهلة القراءة/الكتابة بالثواني. وهي مدعومة حاليًا فقط في MySQL

external_table_functions_use_nulls

يحدّد كيفية استخدام الدوال الجدولية mysql وpostgresql وodbc للأعمدة Nullable. القيم الممكنة:

0 — تستخدم الدالة الجدولية الأعمدة Nullable بشكل صريح.
1 — تستخدم الدالة الجدولية الأعمدة Nullable بشكل ضمني.

الاستخدام إذا ضُبط هذا الإعداد على 0، فلن تُنشئ الدالة الجدولية أعمدة Nullable، وستُدرِج القيم الافتراضية بدلًا من NULL. وينطبق ذلك أيضًا على قيم NULL داخل المصفوفات.

external_table_strict_query

إذا ضُبط على true، يُحظر تحويل التعبير إلى عامل تصفية محلي في الاستعلامات على الجداول الخارجية.

extract_key_value_pairs_max_pairs_per_row

الأسماء البديلة: extract_kvp_max_pairs_per_row الحد الأقصى لعدد الأزواج التي يمكن أن تُنتجها الدالة extractKeyValuePairs. يُستخدم كإجراء احترازي لتجنّب استهلاك قدر كبير جدًا من الذاكرة.

extremes

ما إذا كان سيتم احتساب القيم المتطرفة (القيم الدنيا والعليا في أعمدة نتيجة استعلام). يقبل 0 أو 1. والقيمة الافتراضية هي 0 (معطّل). لمزيد من المعلومات، راجع قسم “القيم المتطرفة”.

fallback_to_stale_replicas_for_distributed_queries

يفرض تنفيذ الاستعلام على نسخة متماثلة قديمة إذا لم تكن البيانات المحدَّثة متاحة. راجع النسخ المتماثل. يختار ClickHouse النسخة المتماثلة القديمة الأكثر ملاءمة من بين النسخ المتماثلة القديمة للجدول. يُستخدم عند تنفيذ SELECT من جدول موزّع يشير إلى جداول متماثلة. القيمة الافتراضية: 1 (مُمكّن).

file_like_engine_default_partition_strategy

استراتيجية التقسيم الافتراضية للمحركات الشبيهة بالملفات.

filesystem_cache_allow_background_download

السماح لذاكرة التخزين المؤقت لنظام الملفات بوضع تنزيلات الخلفية في قائمة الانتظار للبيانات المقروءة من التخزين البعيد. عطّل هذا الخيار لإبقاء التنزيلات في المقدمة للاستعلام/الجلسة الحالية.

filesystem_cache_boundary_alignment

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

filesystem_cache_enable_background_download_during_fetch

ليس له تأثير إلا في ClickHouse Cloud. مدة الانتظار لقفل ذاكرة التخزين المؤقت من أجل حجز مساحة في ذاكرة التخزين المؤقت لنظام الملفات

filesystem_cache_enable_background_download_for_metadata_files_in_packed_storage

لا يكون لهذا الإعداد تأثير إلا في ClickHouse Cloud. مدة الانتظار للحصول على قفل ذاكرة التخزين المؤقت لحجز مساحة في ذاكرة التخزين المؤقت لنظام الملفات

filesystem_cache_max_download_size

الحد الأقصى لحجم ذاكرة التخزين المؤقت لنظام الملفات البعيد الذي يمكن لاستعلام واحد تنزيله

filesystem_cache_name

اسم ذاكرة التخزين المؤقت لنظام الملفات المستخدمة مع محركات الجداول عديمة الحالة أو بحيرات البيانات

filesystem_cache_prefer_bigger_buffer_size

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

filesystem_cache_reserve_space_wait_lock_timeout_milliseconds

مدة الانتظار للحصول على قفل ذاكرة التخزين المؤقت لحجز مساحة في ذاكرة التخزين المؤقت لنظام الملفات

filesystem_cache_segments_batch_size

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

filesystem_cache_skip_download_if_exceeds_per_query_cache_write_limit

الأسماء البديلة: skip_download_if_exceeds_query_cache تخطّي التنزيل من نظام الملفات البعيد إذا تجاوز حجم ذاكرة التخزين المؤقت للاستعلامات

filesystem_prefetch_max_memory_usage

الحد الأقصى لاستهلاك الذاكرة لعمليات الجلب المسبق. القيمة الافتراضية في Cloud: 10% من إجمالي الذاكرة.

filesystem_prefetch_step_bytes

قيمة خطوة الجلب المسبق بالبايت. تشير القيمة صفر إلى auto — أي سيُستنتج تلقائيًا حجم خطوة الجلب المسبق الأمثل تقريبًا، لكنه قد لا يكون الأفضل تمامًا. قد تختلف القيمة الفعلية بسبب الإعداد filesystem_prefetch_min_bytes_for_single_read_task

filesystem_prefetch_step_marks

خطوة الجلب المسبق بوحدة العلامات. تعني القيمة صفر auto، أي سيُحدَّد تلقائيًا حجم خطوة الجلب المسبق الأنسب تقريبًا، لكنه قد لا يكون الأفضل بنسبة 100%. وقد تختلف القيمة الفعلية بسبب الإعداد filesystem_prefetch_min_bytes_for_single_read_task

filesystem_prefetches_limit

الحد الأقصى لعدد عمليات الجلب المسبق. تعني القيمة صفر عدم وجود حد أقصى. ويُوصى باستخدام الإعداد filesystem_prefetches_max_memory_usage بدلاً من ذلك إذا كنت تريد تقييد عدد عمليات الجلب المسبق

final

يطبّق تلقائيًا المُعدِّل FINAL على جميع الجداول في الاستعلام التي يمكن تطبيق FINAL عليها، بما في ذلك الجداول المستخدمة في عمليات join، والجداول في الاستعلامات الفرعية، والجداول الموزعة. القيم الممكنة:

0 - معطّل
1 - مُمكّن

مثال:

CREATE TABLE test
(
    key Int64,
    some String
)
ENGINE = ReplacingMergeTree
ORDER BY key;

INSERT INTO test FORMAT Values (1, 'first');
INSERT INTO test FORMAT Values (1, 'second');

SELECT * FROM test;
┌─key─┬─some───┐
│   1 │ second │
└─────┴────────┘
┌─key─┬─some──┐
│   1 │ first │
└─────┴───────┘

SELECT * FROM test SETTINGS final = 1;
┌─key─┬─some───┐
│   1 │ second │
└─────┴────────┘

SET final = 1;
SELECT * FROM test;
┌─key─┬─some───┐
│   1 │ second │
└─────┴────────┘

finalize_projection_parts_synchronously

عند التمكين، يتم إتمام أجزاء الإسقاط بشكل متزامن أثناء INSERT، ما يقلل ذروة استخدام الذاكرة مقابل خفض توازي الرفع إلى S3. بشكل افتراضي، يظل تدفق الإخراج لكل إسقاط نشطًا إلى أن يكتمل إتمام الجزء بالكامل (بما في ذلك جميع الإسقاطات)، ما يتيح تداخل عمليات الرفع إلى S3، لكنه يزيد ذروة استخدام الذاكرة بما يتناسب مع عدد الإسقاطات. لا يؤثر هذا الإعداد إلا في مسار INSERT؛ أما merge وmutation فيُتمّان الإسقاطات بشكل متزامن بالفعل.

flatten_nested

يضبط تنسيق البيانات لأعمدة Nested. القيم الممكنة:

1 — يُسطَّح عمود Nested إلى مصفوفات منفصلة.
0 — يبقى عمود Nested كمصفوفة واحدة من Tuple.

الاستخدام إذا ضُبط هذا الإعداد على 0، يمكن استخدام أي مستوى من التداخل. أمثلة الاستعلام:

SET flatten_nested = 1;
CREATE TABLE t_nest (`n` Nested(a UInt32, b UInt32)) ENGINE = MergeTree ORDER BY tuple();

SHOW CREATE TABLE t_nest;

النتيجة:

┌─statement───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ CREATE TABLE default.t_nest
(
    `n.a` Array(UInt32),
    `n.b` Array(UInt32)
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS index_granularity = 8192 │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

الاستعلام:

SET flatten_nested = 0;

CREATE TABLE t_nest (`n` Nested(a UInt32, b UInt32)) ENGINE = MergeTree ORDER BY tuple();

SHOW CREATE TABLE t_nest;

النتيجة:

┌─statement──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ CREATE TABLE default.t_nest
(
    `n` Nested(a UInt32, b UInt32)
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS index_granularity = 8192 │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

force_aggregate_partitions_independently

يفرض استخدام هذا التحسين عندما يكون ذلك ممكنًا، حتى إذا قررت الآليات الاستدلالية عدم استخدامه

force_aggregation_in_order

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

force_data_skipping_indices

يعطّل تنفيذ الاستعلام إذا لم تُستخدَم فهارس تخطي البيانات المحددة. ضع في اعتبارك المثال التالي:

CREATE TABLE data
(
    key Int,
    d1 Int,
    d1_null Nullable(Int),
    INDEX d1_idx d1 TYPE minmax GRANULARITY 1,
    INDEX d1_null_idx assumeNotNull(d1_null) TYPE minmax GRANULARITY 1
)
Engine=MergeTree()
ORDER BY key;

SELECT * FROM data_01515;
SELECT * FROM data_01515 SETTINGS force_data_skipping_indices=''; -- query will produce CANNOT_PARSE_TEXT error.
SELECT * FROM data_01515 SETTINGS force_data_skipping_indices='d1_idx'; -- query will produce INDEX_NOT_USED error.
SELECT * FROM data_01515 WHERE d1 = 0 SETTINGS force_data_skipping_indices='d1_idx'; -- Ok.
SELECT * FROM data_01515 WHERE d1 = 0 SETTINGS force_data_skipping_indices='`d1_idx`'; -- Ok (example of full featured parser).
SELECT * FROM data_01515 WHERE d1 = 0 SETTINGS force_data_skipping_indices='`d1_idx`, d1_null_idx'; -- query will produce INDEX_NOT_USED error, since d1_null_idx is not used.
SELECT * FROM data_01515 WHERE d1 = 0 AND assumeNotNull(d1_null) = 0 SETTINGS force_data_skipping_indices='`d1_idx`, d1_null_idx'; -- Ok.

force_grouping_standard_compatibility

اجعل الدالة GROUPING تُرجع 1 عندما لا تُستخدم الوسيطة كمفتاح للتجميع

force_index_by_date

يعطّل تنفيذ الاستعلام إذا تعذّر استخدام الفهرس استنادًا إلى التاريخ. يعمل مع الجداول من عائلة MergeTree. إذا كانت force_index_by_date=1، يتحقّق ClickHouse مما إذا كان الاستعلام يتضمّن شرطًا على مفتاح التاريخ يمكن استخدامه لتقييد نطاقات البيانات. وإذا لم يكن هناك شرط مناسب، فإنه يُطلق استثناءً. ومع ذلك، فهو لا يتحقّق مما إذا كان هذا الشرط يقلّل كمية البيانات المطلوب قراءتها. على سبيل المثال، يُعدّ الشرط Date != ' 2000-01-01 ' مقبولًا حتى عندما يطابق جميع البيانات في الجدول (أي إن تشغيل الاستعلام يتطلّب فحصًا كاملًا). لمزيد من المعلومات حول نطاقات البيانات في جداول MergeTree، راجع MergeTree.

force_optimize_projection

يُمكّن أو يعطّل الاستخدام الإلزامي لـprojections في استعلامات SELECT عند تمكين تحسين الإسقاطات (راجع الإعداد optimize_use_projections). القيم الممكنة:

0 — تحسين الإسقاطات ليس إلزاميًا.
1 — تحسين الإسقاطات إلزامي.

force_optimize_projection_name

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

سلسلة نصية: اسم الإسقاط المستخدم في الاستعلام

force_optimize_skip_unused_shards

يُفعِّل أو يُعطِّل تنفيذ الاستعلام إذا كان optimize_skip_unused_shards مُمكّنًا ولم يكن من الممكن تخطي الشاردات غير المستخدمة. وإذا تعذّر التخطي وكان هذا الإعداد مُمكّنًا، فسيُرفَع استثناء. القيم الممكنة:

0 — معطّل. لا يرفع ClickHouse استثناءً.
1 — مُمكّن. يُعطَّل تنفيذ الاستعلام فقط إذا كان للجدول مفتاح تقسيم إلى شاردات.
2 — مُمكّن. يُعطَّل تنفيذ الاستعلام سواء أكان مفتاح التقسيم إلى شاردات معرّفًا للجدول أم لا.

force_optimize_skip_unused_shards_nesting

يتحكم في force_optimize_skip_unused_shards — وبالتالي لا يزال يتطلب تفعيل force_optimize_skip_unused_shards — وذلك بحسب مستوى التداخل في الاستعلام الموزع (أي في الحالة التي يكون لديك فيها جدول Distributed يستعلم من جدول Distributed آخر). القيم الممكنة:

0 - معطّل، ويعمل force_optimize_skip_unused_shards دائمًا.
1 — يفعّل force_optimize_skip_unused_shards للمستوى الأول فقط.
2 — يفعّل force_optimize_skip_unused_shards حتى المستوى الثاني.

force_primary_key

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

force_remove_data_recursively_on_drop

يزيل البيانات بشكل تكراري عند تنفيذ استعلام DROP. يتجنب الخطأ ‘Directory not empty’، لكنه قد يزيل البيانات المفصولة بصمت

formatdatetime_e_with_space_padding

يعرض محدِّد التنسيق ‘%e’ في الدالة ‘formatDateTime’ الأيام المكوّنة من رقم واحد مسبوقة بمسافة، مثل ’ 2’ بدلًا من ‘2’.

formatdatetime_f_prints_scale_number_of_digits

يعرض محدِّد التنسيق ‘%f’ في الدالة ‘formatDateTime’ عددًا من الخانات يساوي قيمة scale فقط في DateTime64 بدلًا من 6 خانات ثابتة.

formatdatetime_f_prints_single_zero

يعرض محدِّد التنسيق ‘%f’ في الدالة ‘formatDateTime’ صفراً واحداً بدلاً من ستة أصفار إذا كانت القيمة المنسّقة لا تحتوي على كسور من الثانية.

formatdatetime_format_without_leading_zeros

تعرض محددات التنسيق ‘%c’ و’%l’ و’%k’ في الدالة formatDateTime الأشهر والساعات من دون أصفار بادئة.

formatdatetime_parsedatetime_m_is_month_name

يؤدي محدِّد التنسيق ‘%M’ في الدالتين ‘formatDateTime’ و ‘parseDateTime’ إلى طباعة/تحليل اسم الشهر بدلًا من الدقائق.

fsync_metadata

يُفعِّل أو يعطِّل fsync عند كتابة ملفات .sql. وهو مُفعَّل افتراضيًا. من المنطقي تعطيله إذا كان لدى الخادم ملايين الجداول الصغيرة التي تُنشأ وتُحذف باستمرار.

function_base58_max_input_size

الحد الأقصى لحجم قيمة إدخال واحدة، بالبايت، للدوال base58Encode وbase58Decode وtryBase58Decode. يكون تحويل base58 العام تربيعيًا بالنسبة إلى طول الإدخال، لذلك قد تستغرق قيمة كبيرة واحدة وقتًا طويلًا جدًا في التنفيذ. صُمم base58 للبيانات القصيرة (المفاتيح، وقيم التجزئة، والعناوين)، لذا فإن القيمة الافتراضية البالغة 10 كيلوبايت تُعد عتبة أمان سخية. تُطلق base58Encode وbase58Decode الخطأ TOO_LARGE_STRING_SIZE عند الإدخالات الأكبر، بينما تُرجع tryBase58Decode سلسلة فارغة. تؤدي القيمة 0 إلى تعطيل هذا القيد (وكان هذا هو السلوك قبل تقديم هذا الإعداد). ولا تتأثر دوال base32 وbase64 الخطية.

function_date_trunc_return_type_behavior

يسمح هذا الإعداد بتغيير سلوك نوع ناتج الدالة dateTrunc. القيم الممكنة:

0 - عندما تكون الوسيطة الثانية DateTime64/Date32، يكون نوع الإرجاع DateTime64/Date32 بغضّ النظر عن وحدة الوقت في الوسيطة الأولى.
1 - بالنسبة إلى Date32، تكون النتيجة دائمًا Date. وبالنسبة إلى DateTime64، تكون النتيجة DateTime لوحدات الوقت second وما أعلى.

function_implementation

اختر تنفيذ الدالة لهدف أو Variant محدد (تجريبي). وإذا تُرك فارغًا، فسيتم تفعيلها جميعًا.

function_json_value_return_type_allow_complex

يحدّد ما إذا كان مسموحًا بإرجاع نوع معقّد (مثل: struct وarray وmap) للدالة json_value.

SELECT JSON_VALUE('{"hello":{"world":"!"}}', '$.hello') settings function_json_value_return_type_allow_complex=true

┌─JSON_VALUE('{"hello":{"world":"!"}}', '$.hello')─┐
│ {"world":"!"}                                    │
└──────────────────────────────────────────────────┘

1 row in set. Elapsed: 0.001 sec.

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

true — يُسمح به.
false — لا يُسمح به.

function_json_value_return_type_allow_nullable

يتحكم في ما إذا كان يُسمح بإرجاع NULL عندما لا تكون هناك قيمة موجودة للدالة JSON_VALUE.

SELECT JSON_VALUE('{"hello":"world"}', '$.b') settings function_json_value_return_type_allow_nullable=true;

┌─JSON_VALUE('{"hello":"world"}', '$.b')─┐
│ ᴺᵁᴸᴸ                                   │
└────────────────────────────────────────┘

1 row in set. Elapsed: 0.001 sec.

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

true — السماح.
false — عدم السماح.

function_locate_has_mysql_compatible_argument_order

يتحكم هذا الإعداد في ترتيب الوسيطات في الدالة locate. القيم الممكنة:

0 — تقبل الدالة locate الوسيطات (haystack, needle[, start_pos]).
1 — تقبل الدالة locate الوسيطات (needle, haystack, [, start_pos]) (سلوك متوافق مع MySQL)

function_range_max_elements_in_block

يحدّد حدّ الأمان لحجم البيانات الناتج عن الدالة range. ويعرّف الحد الأقصى لعدد القيم التي تُنشئها الدالة في كل كتلة بيانات (إجمالي أحجام المصفوفات لكل صف في الكتلة). القيم الممكنة:

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

انظر أيضًا

max_block_size
min_insert_block_size_rows

function_sleep_max_microseconds_per_block

الحد الأقصى لعدد الميكروثواني المسموح للدالة sleep بالسكون خلالها لكل block. وإذا استدعاها مستخدم بقيمة أكبر، فسيؤدي ذلك إلى استثناء. وهذا حد أمان.

سلوك function_visible_width_behavior

إصدار سلوك visibleWidth. 0 - يحسب عدد code points فقط؛ 1 - يحسب المحارف ذات العرض الصفري والمحارف المُركَّبة بشكل صحيح، ويحسب المحارف كاملة العرض على أنها محرفان، ويقدّر عرض tab، ويحسب محارف الحذف.

functions_h3_default_if_invalid

إذا كانت القيمة false، فستُطلق دوال h3، مثل h3CellAreaM2، استثناءً إذا كان الإدخال غير صالح. وإذا كانت القيمة true، فستُرجع 0 أو القيمة الافتراضية.

geo_distance_returns_float64_on_float64_arguments

إذا كانت الوسيطات الأربع للدوال geoDistance وgreatCircleDistance وgreatCircleAngle جميعها من النوع Float64، فأعِد قيمة من النوع Float64 واستخدم دقةً مزدوجة في العمليات الحسابية الداخلية. في الإصدارات السابقة من ClickHouse، كانت هذه الدوال تُعيد دائمًا Float32.

geotoh3_argument_order

تقبل الدالة ‘geoToH3’ ‎(lon, lat)‎ إذا كان الإعداد ‘lon_lat’، و‎(lat, lon)‎ إذا كان الإعداد ‘lat_lon’.

glob_expansion_max_elements

الحد الأقصى لعدد العناوين المسموح بها (للتخزين الخارجي، ودوال الجدول، وما إلى ذلك).

grace_hash_join_initial_buckets

العدد الأولي لتقسيمات grace hash join

grace_hash_join_max_buckets

الحد الأقصى لعدد التقسيمات في grace hash join

group_by_overflow_mode

يحدّد ما يحدث عندما يتجاوز عدد المفاتيح الفريدة للتجميع الحدّ المسموح:

throw: إثارة استثناء
break: إيقاف تنفيذ الاستعلام وإرجاع النتيجة الجزئية
any: متابعة التجميع للمفاتيح التي دخلت إلى المجموعة، لكن من دون إضافة مفاتيح جديدة إليها.

يتيح لك استخدام القيمة any تشغيل تقريب لـ GROUP BY. وتعتمد جودة هذا التقريب على الطبيعة الإحصائية للبيانات.

group_by_two_level_threshold

ابتداءً من أي عدد من المفاتيح يبدأ التجميع على مستويين. 0 - لم تُضبط العتبة.

group_by_two_level_threshold_bytes

ابتداءً من أي حجم لحالة التجميع، محسوبًا بالبايت، يبدأ استخدام التجميع على مستويين. 0 - يعني أن العتبة غير معيّنة. يُستخدم التجميع على مستويين عند تفعيل عتبة واحدة على الأقل من هذه العتبات.

group_by_use_nulls

يغيّر هذا الإعداد الطريقة التي يتعامل بها بند GROUP BY مع أنواع مفاتيح التجميع. عند استخدام المحددات ROLLUP أو CUBE أو GROUPING SETS، قد لا تُستخدم بعض مفاتيح التجميع في إنشاء بعض صفوف النتائج. وتُملأ أعمدة هذه المفاتيح في الصفوف المقابلة إما بالقيمة الافتراضية أو بـ NULL وفقًا لهذا الإعداد. القيم الممكنة:

0 — تُستخدم القيمة الافتراضية لنوع مفتاح التجميع لملء القيم المفقودة.
1 — ينفّذ ClickHouse ‏GROUP BY بالطريقة نفسها التي ينص عليها معيار SQL. وتُحوَّل أنواع مفاتيح التجميع إلى Nullable. وتُملأ أعمدة مفاتيح التجميع المقابلة بـ NULL في الصفوف التي لم تُستخدم فيها هذه المفاتيح.

انظر أيضًا:

بند GROUP BY

h3togeo_lon_lat_result_order

تعيد الدالة ‘h3ToGeo’ ‎(lon, lat) إذا كانت القيمة true، وإلا فستعيد ‎(lat, lon).

handshake_timeout_ms

مهلة الانتظار بالمللي ثانية لتلقّي حزمة Hello من النسخ المتماثلة أثناء عملية المصافحة.

hdfs_create_new_file_on_insert

يُمكّن أو يعطّل إنشاء ملف جديد مع كل عملية إدراج في جداول محرك HDFS. إذا كان هذا الخيار مُمكّنًا، فسيُنشأ مع كل عملية إدراج ملف HDFS جديد باسم يتبع نمطًا مشابهًا لما يلي: الاسم الأولي: data.Parquet.gz -> data.1.Parquet.gz -> data.2.Parquet.gz، وهكذا. القيم الممكنة:

0 — يُلحِق استعلام INSERT البيانات الجديدة بنهاية الملف.
1 — ينشئ استعلام INSERT ملفًا جديدًا.

hdfs_ignore_file_doesnt_exist

تجاهل عدم وجود الملف إذا لم يكن موجودًا عند قراءة مفاتيح معيّنة. القيم الممكنة:

1 — يعيد SELECT نتيجة فارغة.
0 — يُثير SELECT استثناءً.

hdfs_replication

يمكن تحديد عامل التكرار الفعلي عند إنشاء ملف HDFS.

hdfs_skip_empty_files

يؤدي إلى تفعيل أو تعطيل تخطي الملفات الفارغة في جداول محرك HDFS. القيم الممكنة:

0 — يُطلق SELECT استثناءً إذا لم يكن الملف الفارغ متوافقًا مع التنسيق المطلوب.
1 — يعرض SELECT نتيجة فارغة لملف فارغ.

hdfs_throw_on_zero_files_match

أثِر خطأً إذا لم تُطابَق أي ملفات وفقًا لقواعد توسيع glob. القيم الممكنة:

1 — SELECT يُثير استثناءً.
0 — SELECT يعيد نتيجة فارغة.

hdfs_truncate_on_insert

يُفعِّل أو يعطِّل اقتطاع الملف قبل عملية الإدراج في جداول محرك HDFS. وإذا كان معطّلًا، فسيتم طرح استثناء عند محاولة الإدراج إذا كان الملف موجودًا بالفعل في HDFS. القيم الممكنة:

0 — يُلحِق استعلام INSERT البيانات الجديدة بنهاية الملف.
1 — يستبدل استعلام INSERT المحتوى الحالي للملف بالبيانات الجديدة.

hedged_connection_timeout_ms

مهلة الاتصال اللازمة لإنشاء اتصال مع النسخة المتماثلة للطلبات المحوّطة

highlight_max_matches_per_row

يحدّد الحد الأقصى لعدد مطابقات الإبراز لكل صف في الدالة highlight. استخدمه للحماية من الاستهلاك المفرط للذاكرة عند إبراز الأنماط شديدة التكرار في النصوص الكبيرة. القيم الممكنة:

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

hnsw_candidate_list_size_for_search

حجم قائمة المرشحين الديناميكية عند البحث في index تشابه المتجهات، ويُعرف أيضًا باسم ‘ef_search’.

hsts_max_age

مدة انتهاء صلاحية HSTS. تعني القيمة 0 تعطيل HSTS.

http_connection_timeout

مهلة اتصال HTTP (بالثواني). القيم الممكنة:

أي عدد صحيح موجب.
0 - مُعطَّل (مهلة لا نهائية).

http_headers_progress_interval_ms

لا تُرسل رؤوس HTTP ‏X-ClickHouse-Progress بمعدل يزيد على مرة واحدة خلال كل فاصل زمني محدد.

http_headers_read_timeout

الحد الأقصى للوقت، بالثواني، لقراءة جميع رؤوس طلب HTTP. هذا حد زمني إجمالي لمرحلة تحليل الرؤوس بالكامل، وليس مهلة لكل عملية قراءة على حدة. ويوفر حماية من هجمات على نمط slowloris، حيث يرسل العميل بيانات الرؤوس ببطء للإبقاء على الاتصالات مفتوحة.

http_make_head_request

يتيح الإعداد http_make_head_request تنفيذ طلب HEAD أثناء قراءة البيانات عبر HTTP لاسترجاع معلومات عن الملف المطلوب قراءته، مثل حجمه. ونظرًا إلى أنه مفعّل افتراضيًا، فقد يكون من المستحسن تعطيل هذا الإعداد في الحالات التي لا يدعم فيها الخادم طلبات HEAD.

http_max_field_name_size

الحد الأقصى لطول اسم الحقل في رؤوس طلب HTTP ومعلمات الاستعلام وبيانات النموذج.

http_max_field_value_size

الحد الأقصى لطول قيمة الحقل في رؤوس طلب HTTP ومعلمات الاستعلام وبيانات النموذج.

http_max_fields

الحد الأقصى لعدد الحقول في رؤوس طلب HTTP ومعلمات الاستعلام وبيانات النموذج.

http_max_multipart_form_data_size

الحد الأقصى لحجم محتوى multipart/form-data. لا يمكن تحليل هذا الإعداد من معلمات URL، ويجب تعيينه في ملف تعريف المستخدم. لاحظ أن المحتوى يُحلَّل وتُنشأ الجداول الخارجية في الذاكرة قبل بدء تنفيذ الاستعلام. وهذا هو الحد الوحيد الذي يؤثر في تلك المرحلة (أما الحدود القصوى لاستخدام الذاكرة ووقت التنفيذ فلا يكون لها أي تأثير أثناء قراءة بيانات نموذج HTTP).

http_max_request_header_size

الحد الأقصى للحجم الإجمالي لجميع رؤوس طلب HTTP (بما في ذلك الأسماء والقيم) بالبايت.

http_max_request_param_data_size

الحد الأقصى لحجم بيانات الطلب المستخدمة كمعلَمة استعلام في طلبات HTTP المعرَّفة مسبقًا.

http_max_tries

الحد الأقصى لعدد محاولات القراءة عبر HTTP.

http_max_uri_size

يحدّد الحد الأقصى لطول URI لطلب HTTP. القيم الممكنة:

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

http_native_compression_disable_checksumming_on_decompress

يُمكّن أو يعطّل التحقق من المجموع الاختباري عند فك ضغط بيانات HTTP POST القادمة من العميل. يُستخدم فقط مع تنسيق الضغط الأصلي في ClickHouse (ولا يُستخدم مع gzip أو deflate). لمزيد من المعلومات، راجع وصف واجهة HTTP. القيم الممكنة:

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

http_receive_timeout

مهلة استقبال HTTP (بالثواني). القيم المحتملة:

أي عدد صحيح موجب.
0 - معطّل (مهلة غير محدودة).

http_response_buffer_size

عدد البايتات التي تُخزَّن مؤقتًا في ذاكرة الخادم قبل إرسال استجابة HTTP إلى العميل أو كتابتها إلى القرص (عند تمكين http_wait_end_of_query).

http_response_headers

يسمح هذا بإضافة رؤوس HTTP أو استبدالها، والتي سيُرجعها الخادم في الاستجابة مع نتيجة استعلام ناجحة. ولا يؤثر هذا إلا على واجهة HTTP. إذا كان الرأس مضبوطًا بالفعل افتراضيًا، فستستبدله القيمة المقدَّمة. وإذا لم يكن الرأس مضبوطًا افتراضيًا، فسيُضاف إلى قائمة الرؤوس. أما الرؤوس التي يضبطها الخادم افتراضيًا ولم يستبدلها هذا الإعداد، فستبقى كما هي. يتيح لك هذا الإعداد تعيين رأس إلى قيمة ثابتة. ولا توجد حاليًا طريقة لتعيين رأس إلى قيمة محسوبة ديناميكيًا. لا يجوز أن تحتوي الأسماء أو القيم على محارف تحكم ASCII. إذا كنت تنفّذ تطبيق UI يتيح للمستخدمين تعديل الإعدادات، ويتخذ في الوقت نفسه قرارات استنادًا إلى الرؤوس المُعادة، فمن المستحسن تقييد هذا الإعداد إلى readonly. مثال: SET http_response_headers = '{"Content-Type": "image/png"}'

http_retry_initial_backoff_ms

الحد الأدنى لزمن التراجع التدريجي بالمللي ثانية عند إعادة محاولة القراءة عبر http

http_retry_max_backoff_ms

الحد الأقصى لمدة التراجع التدريجي، بالملي ثانية، عند إعادة محاولة القراءة عبر http

http_send_timeout

مهلة إرسال HTTP (بالثواني). القيم الممكنة:

أي عدد صحيح موجب.
0 - معطّل (مهلة لا نهائية).

ينطبق هذا فقط على ملف تعريف default. يلزم إعادة تشغيل الخادم لكي تدخل التغييرات حيّز التنفيذ.

http_skip_not_found_url_for_globs

تخطَّ عناوين URL لأنماط glob عند حدوث الخطأ HTTP_NOT_FOUND

http_wait_end_of_query

فعّل التخزين المؤقت لاستجابة HTTP على جانب الخادم.

http_write_exception_in_output_format

يُكتب الاستثناء بتنسيق الإخراج لإنتاج مخرجات صالحة. يعمل مع تنسيقات JSON وXML.

http_zlib_compression_level

يحدّد مستوى ضغط البيانات في الاستجابة لطلب HTTP إذا كان enable_http_compression = 1. القيم الممكنة: الأرقام من 1 إلى 9.

iceberg_compaction_data_cleanup

المدة التي ستُحذف بعدها البيانات.

iceberg_compaction_delay_bias

الحد الأدنى لمدة التأخير بين عمليتَي دمج في الخلفية.

iceberg_data_file_size_lower_threshold_compaction

العتبة الدنيا لملفات البيانات الخاصة بعملية الدمج في Iceberg.

iceberg_data_file_size_upper_threshold_compaction

الحدّ الأعلى لحجم ملفات البيانات الخاصة بعملية الدمج في Iceberg.

iceberg_delete_data_on_drop

ما إذا كان ينبغي حذف جميع ملفات Iceberg عند تنفيذ DROP أم لا.

iceberg_expire_default_max_ref_age_ms

القيمة الافتراضية لخاصية جدول Iceberg history.expire.max-ref-age-ms التي يستخدمها expire_snapshots عند عدم وجود هذه الخاصية.

iceberg_expire_default_max_snapshot_age_ms

القيمة الافتراضية لخاصية جدول Iceberg history.expire.max-snapshot-age-ms التي يستخدمها expire_snapshots عند عدم وجود هذه الخاصية.

iceberg_expire_default_min_snapshots_to_keep

القيمة الافتراضية لخاصية جدول Iceberg history.expire.min-snapshots-to-keep التي يستخدمها expire_snapshots عند عدم وجود هذه الخاصية.

iceberg_insert_max_bytes_in_data_file

الحد الأقصى لعدد البايتات في ملف بيانات Parquet الخاص بـ Iceberg أثناء عملية الإدراج.

iceberg_insert_max_partitions

الحد الأقصى المسموح به لعدد الأقسام في عملية insert واحدة ضمن محرك جدول Iceberg.

iceberg_insert_max_rows_in_data_file

الحد الأقصى لعدد الصفوف في ملف بيانات Parquet لـ Iceberg أثناء عملية الإدراج.

iceberg_max_number_datafiles_to_compact

عتبة دمج ملفات البيانات في Iceberg.

iceberg_metadata_compression_method

طريقة ضغط ملف .metadata.json.

iceberg_metadata_log_level

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

none - لا يوجد سجل للبيانات الوصفية.
metadata - ملف metadata.json الجذر.
manifest_list_metadata - كل ما سبق + البيانات الوصفية من manifest list بتنسيق avro المطابقة لـ لقطة.
manifest_list_entry - كل ما سبق + إدخالات manifest list بتنسيق avro.
manifest_file_metadata - كل ما سبق + البيانات الوصفية من manifest files بتنسيق avro التي تم اجتيازها.
manifest_file_entry - كل ما سبق + إدخالات manifest files بتنسيق avro التي تم اجتيازها.

iceberg_metadata_staleness_ms

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

iceberg_orphan_files_older_than_seconds

الحدّ العمري الافتراضي، بالثواني، لإزالة الملفات اليتيمة في جداول Iceberg. لا تُعدّ الملفات الأحدث من هذا الحدّ ملفاتٍ يتيمة. يُستخدم هذا الإعداد عند حذف الوسيط older_than من استدعاء الإجراء remove_orphan_files(). القيمة الافتراضية هي 259200 (3 أيام).

iceberg_snapshot_id

استعلم عن جدول Iceberg باستخدام معرّف اللقطة المحدّد.

iceberg_timestamp_ms

نفِّذ استعلامًا على جدول Iceberg باستخدام اللقطة التي كانت سارية عند طابع زمني محدد.

idle_connection_timeout

مهلة لإغلاق اتصالات TCP غير النشطة بعد انقضاء عدد الثواني المحدد. القيم الممكنة:

عدد صحيح موجب (0 - إغلاق فوري بعد 0 ثانية).

ignore_cold_parts_seconds

لا يكون لهذا الإعداد تأثير إلا في ClickHouse Cloud. استبعد أجزاء البيانات الجديدة من استعلامات SELECT إلى أن تُحمَّل مسبقًا في الذاكرة (راجع cache_populated_by_fetch) أو إلى أن يبلغ عمرها هذا العدد من الثواني. وذلك فقط لمحركَي Replicated-/SharedMergeTree.

ignore_data_skipping_indices

يتجاهل فهارس تخطي البيانات المحددة إذا كان الاستعلام يستخدمها. تأمل المثال التالي:

CREATE TABLE data
(
    key Int,
    x Int,
    y Int,
    INDEX x_idx x TYPE minmax GRANULARITY 1,
    INDEX y_idx y TYPE minmax GRANULARITY 1,
    INDEX xy_idx (x,y) TYPE minmax GRANULARITY 1
)
Engine=MergeTree()
ORDER BY key;

INSERT INTO data VALUES (1, 2, 3);

SELECT * FROM data;
SELECT * FROM data SETTINGS ignore_data_skipping_indices=''; -- query will produce CANNOT_PARSE_TEXT error.
SELECT * FROM data SETTINGS ignore_data_skipping_indices='x_idx'; -- Ok.
SELECT * FROM data SETTINGS ignore_data_skipping_indices='na_idx'; -- Ok.

SELECT * FROM data WHERE x = 1 AND y = 1 SETTINGS ignore_data_skipping_indices='xy_idx',force_data_skipping_indices='xy_idx' ; -- query will produce INDEX_NOT_USED error, since xy_idx is explicitly ignored.
SELECT * FROM data WHERE x = 1 AND y = 2 SETTINGS ignore_data_skipping_indices='xy_idx';

الاستعلام دون تجاهل أي فهارس:

EXPLAIN indexes = 1 SELECT * FROM data WHERE x = 1 AND y = 2;

Expression ((Projection + Before ORDER BY))
  Filter (WHERE)
    ReadFromMergeTree (default.data)
    Indexes:
      PrimaryKey
        Condition: true
        Parts: 1/1
        Granules: 1/1
      Skip
        Name: x_idx
        Description: minmax GRANULARITY 1
        Parts: 0/1
        Granules: 0/1
      Skip
        Name: y_idx
        Description: minmax GRANULARITY 1
        Parts: 0/0
        Granules: 0/0
      Skip
        Name: xy_idx
        Description: minmax GRANULARITY 1
        Parts: 0/0
        Granules: 0/0

عند تجاهل الفهرس xy_idx:

EXPLAIN indexes = 1 SELECT * FROM data WHERE x = 1 AND y = 2 SETTINGS ignore_data_skipping_indices='xy_idx';

Expression ((Projection + Before ORDER BY))
  Filter (WHERE)
    ReadFromMergeTree (default.data)
    Indexes:
      PrimaryKey
        Condition: true
        Parts: 1/1
        Granules: 1/1
      Skip
        Name: x_idx
        Description: minmax GRANULARITY 1
        Parts: 0/1
        Granules: 0/1
      Skip
        Name: y_idx
        Description: minmax GRANULARITY 1
        Parts: 0/0
        Granules: 0/0

يعمل مع الجداول من عائلة MergeTree.

ignore_drop_queries_probability

إذا كان مفعّلًا، فسيتجاهل الخادم جميع استعلامات DROP TABLE وفق الاحتمالية المحددة (وبالنسبة إلى المحركين Memory وJOIN، سيستبدل DROP بـ TRUNCATE). يُستخدم ذلك لأغراض الاختبار

ignore_format_null_for_explain

إذا كان مُمكّنًا، فسيُتجاهل FORMAT Null في استعلامات EXPLAIN وسيُستخدم بدلًا منه تنسيق الإخراج الافتراضي. إذا كان معطّلًا، فلن تُنتج استعلامات EXPLAIN التي تتضمن FORMAT Null أي مخرجات (وهو سلوك متوافق مع الإصدارات السابقة).

ignore_materialized_views_with_dropped_target_table

تجاهل العروض المادية التي حُذف جدولها الهدف عند الدفع إلى العروض

ignore_on_cluster_for_replicated_access_entities_queries

تجاهل عبارة ON CLUSTER في استعلامات إدارة كيانات الوصول المُكرَّرة.

ignore_on_cluster_for_replicated_database

تجاهل دائمًا عبارة ON CLUSTER في استعلامات DDL مع قواعد بيانات من نوع Replicated.

ignore_on_cluster_for_replicated_named_collections_queries

تجاهل عبارة ON CLUSTER في استعلامات إدارة المجموعات المسماة المكررة.

ignore_on_cluster_for_replicated_udf_queries

تجاهل عبارة ON CLUSTER في استعلامات إدارة UDF المكرّرة.

implicit_select

اسمح بكتابة استعلامات SELECT بسيطة من دون الكلمة المفتاحية SELECT في البداية، مما يسهّل استخدامها بأسلوب الآلة الحاسبة؛ فعلى سبيل المثال، يصبح 1 + 2 استعلامًا صالحًا. في clickhouse-local يكون هذا الخيار مفعّلًا افتراضيًا، ويمكن تعطيله صراحةً.

implicit_table_at_top_level

إذا لم تكن قيمته فارغة، فستقرأ الاستعلامات التي لا تحتوي على FROM في المستوى الأعلى من هذا الجدول بدلًا من system.one. يُستخدم هذا في clickhouse-local لمعالجة بيانات الإدخال. يمكن للمستخدم تعيين هذا الإعداد صراحةً، لكنه ليس مخصّصًا لهذا النوع من الاستخدام. لا تتأثر الاستعلامات الفرعية بهذا الإعداد (سواء كانت استعلامات فرعية scalar أو FROM أو IN). تُعامل عبارات SELECT في المستوى الأعلى ضمن سلاسل UNION وINTERSECT وEXCEPT معاملة موحّدة، وتتأثر بهذا الإعداد بغض النظر عن تجميعها بين قوسين. لم يُحدَّد كيف يؤثر هذا الإعداد في طرق العرض والاستعلامات الموزعة. يقبل هذا الإعداد اسم جدول (وعندها يُحدَّد الجدول انطلاقًا من قاعدة البيانات الحالية) أو اسمًا مؤهلًا بالصيغة ‘database.table’. يجب أن يكون كلٌّ من اسمي قاعدة البيانات والجدول من دون علامات اقتباس — ولا يُسمح إلا بالمُعرِّفات البسيطة.

implicit_transaction

إذا كان مفعّلًا ولم يكن الاستعلام ضمن معاملة بالفعل، فسيُنفَّذ الاستعلام ضمن معاملة كاملة (begin + commit أو rollback)

inject_random_order_for_select_without_order_by

إذا كان مُمكّنًا، فسيُحقن ‘ORDER BY rand()’ في استعلامات SELECT التي لا تتضمن بند ORDER BY. يُطبَّق فقط عندما يكون عمق الاستعلام الفرعي = 0. ولا تتأثر الاستعلامات الفرعية وعبارات INSERT INTO … SELECT. إذا كانت البنية ذات المستوى الأعلى هي UNION، فسيُحقن ‘ORDER BY rand()’ في جميع الفروع بشكل مستقل. لا يكون مفيدًا إلا للاختبار والتطوير (إذ إن غياب ORDER BY يُعد مصدرًا لنتائج استعلام غير حتمية).

insert_allow_materialized_columns

إذا كان هذا الإعداد مُمكّنًا، فسيُسمح بالأعمدة المُجسَّدة في INSERT.

insert_deduplicate

يُمكّن أو يعطّل إزالة تكرار الكتل لعملية INSERT (لجداول Replicated*). القيم الممكنة:

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

افتراضيًا، تُزال تكرارات الكتل المُدرجة في الجداول المكررة بواسطة عبارة INSERT (انظر تكرار البيانات). بالنسبة إلى الجداول المكررة، يُزال التكرار افتراضيًا فقط لأول 100 كتلة من أحدث الكتل في كل قسم (انظر replicated_deduplication_window، replicated_deduplication_window_seconds). بالنسبة إلى الجداول غير المكررة، انظر non_replicated_deduplication_window.

insert_deduplication_token

يتيح هذا الإعداد للمستخدم تحديد آلية إزالة التكرار الخاصة به في MergeTree/ReplicatedMergeTree. فعلى سبيل المثال، من خلال تحديد قيمة فريدة لهذا الإعداد في كل تعليمة INSERT، يمكن للمستخدم تجنب إزالة تكرار البيانات المُدرجة نفسها. القيم الممكنة:

أي سلسلة نصية

لا يُستخدم insert_deduplication_token في إزالة التكرار إلا عندما لا يكون فارغًا. بالنسبة إلى الجداول المكررة، افتراضيًا لا تُزال التكرارات إلا من أحدث 100 عملية insert لكل قسم (راجع replicated_deduplication_window، replicated_deduplication_window_seconds). أما بالنسبة إلى not replicated tables، فراجع non_replicated_deduplication_window.

يعمل insert_deduplication_token على مستوى قسم (تمامًا مثل checksum الخاصة بـ insert_deduplication). ويمكن لعدة أقسام أن تحمل القيمة نفسها لـ insert_deduplication_token.

مثال:

CREATE TABLE test_table
( A Int64 )
ENGINE = MergeTree
ORDER BY A
SETTINGS non_replicated_deduplication_window = 100;

INSERT INTO test_table SETTINGS insert_deduplication_token = 'test' VALUES (1);

-- the next insert won't be deduplicated because insert_deduplication_token is different
INSERT INTO test_table SETTINGS insert_deduplication_token = 'test1' VALUES (1);

-- the next insert will be deduplicated because insert_deduplication_token
-- is the same as one of the previous
INSERT INTO test_table SETTINGS insert_deduplication_token = 'test' VALUES (2);

SELECT * FROM test_table

┌─A─┐
│ 1 │
└───┘
┌─A─┐
│ 1 │
└───┘

insert_keeper_fault_injection_probability

الاحتمال التقريبي لفشل طلب Keeper أثناء insert. يجب أن تكون القيمة ضمن النطاق [0.0f, 1.0f]

insert_keeper_fault_injection_seed

0 - البذرة العشوائية، وإلا فتُستخدم قيمة الإعداد

insert_keeper_max_retries

يضبط هذا الإعداد الحد الأقصى لعدد مرات إعادة المحاولة لطلبات ClickHouse Keeper (أو ZooKeeper) أثناء الإدراج في MergeTree المكرّر. ولا تُؤخذ في الحسبان لإعادة المحاولة إلا طلبات Keeper التي فشلت بسبب خطأ في الشبكة، أو انتهاء مهلة جلسة Keeper، أو انتهاء مهلة الطلب. Possible values:

عدد صحيح موجب.
0 — تكون إعادة المحاولة معطّلة

Cloud default value: 20. تتم إعادة المحاولة لطلبات Keeper بعد مهلة زمنية معينة. وتتحكم في هذه المهلة الإعدادات التالية: insert_keeper_retry_initial_backoff_ms, insert_keeper_retry_max_backoff_ms. تتم أول إعادة محاولة بعد المهلة المحددة في insert_keeper_retry_initial_backoff_ms. أما المهل اللاحقة فسيُحسب طولها كما يلي:

timeout = min(insert_keeper_retry_max_backoff_ms, latest_timeout * 2)

على سبيل المثال، إذا كانت insert_keeper_retry_initial_backoff_ms=100 وinsert_keeper_retry_max_backoff_ms=10000 وinsert_keeper_max_retries=8، فستكون مدد المهلة 100, 200, 400, 800, 1600, 3200, 6400, 10000. وبالإضافة إلى تحمّل الأعطال، تهدف إعادات المحاولة إلى توفير تجربة استخدام أفضل، إذ تتيح تجنّب إرجاع خطأ أثناء تنفيذ INSERT إذا أُعيد تشغيل Keeper، على سبيل المثال بسبب ترقية.

insert_keeper_retry_initial_backoff_ms

مهلة الانتظار الأولية (بالملي ثانية) قبل إعادة محاولة طلب Keeper فشل أثناء تنفيذ استعلام INSERT القيم الممكنة:

عدد صحيح موجب.
0 — لا توجد مهلة انتظار

insert_keeper_retry_max_backoff_ms

الحد الأقصى للمهلة الزمنية (بالملي ثانية) لإعادة محاولة طلب Keeper تعذّر أثناء تنفيذ استعلام INSERT القيم الممكنة:

عدد صحيح موجب.
0 — المهلة الزمنية القصوى غير مقيّدة

insert_null_as_default

يُفعِّل هذا الإعداد أو يعطّل إدراج القيم الافتراضية بدلًا من NULL في الأعمدة ذات نوع البيانات غير Nullable. إذا كان نوع العمود غير Nullable وكان هذا الإعداد معطّلًا، فإن إدراج NULL يتسبب في حدوث استثناء. أما إذا كان نوع العمود Nullable، فتُدرج قيم NULL كما هي بغض النظر عن هذا الإعداد. ينطبق هذا الإعداد على استعلامات INSERT … SELECT. لاحظ أن الاستعلامات الفرعية SELECT يمكن ربطها باستخدام البند UNION ALL. القيم الممكنة:

0 — يتسبب إدراج NULL في عمود غير Nullable في حدوث استثناء.
1 — تُدرج القيمة الافتراضية للعمود بدلًا من NULL.

insert_quorum

لا ينطبق هذا الإعداد على SharedMergeTree، راجع اتساق SharedMergeTree لمزيد من المعلومات.

يُمكّن الكتابة بالنصاب.

إذا كان insert_quorum < 2، تكون الكتابة بالنصاب معطّلة.
إذا كان insert_quorum >= 2، تكون الكتابة بالنصاب مفعّلة.
إذا كان insert_quorum = 'auto'، فاستخدم عدد الأغلبية (number_of_replicas / 2 + 1) بوصفه قيمة النصاب.

الكتابة بالنصاب لا تنجح عملية INSERT إلا عندما يتمكن ClickHouse من كتابة البيانات بنجاح إلى insert_quorum من النسخ المتماثلة خلال insert_quorum_timeout. وإذا لم يصل عدد النسخ المتماثلة التي نجحت الكتابة إليها إلى insert_quorum لأي سبب، فتُعدّ عملية الكتابة فاشلة، وسيحذف ClickHouse الـ كتلة المُدرَج من جميع النسخ المتماثلة التي كُتبت إليها البيانات بالفعل. عندما يكون insert_quorum_parallel معطّلًا، تكون جميع النسخ المتماثلة ضمن النصاب متسقة، أي إنها تحتوي على بيانات جميع استعلامات INSERT السابقة (أي يكون تسلسل INSERT خطيًا). وعند قراءة البيانات المكتوبة باستخدام insert_quorum مع تعطيل insert_quorum_parallel، يمكنك تفعيل الاتساق التسلسلي لاستعلامات SELECT باستخدام select_sequential_consistency. يُصدر ClickHouse استثناءً في الحالات التالية:

إذا كان عدد النسخ المتماثلة المتاحة وقت تنفيذ الاستعلام أقل من insert_quorum.
عندما يكون insert_quorum_parallel معطّلًا وتُجرى محاولة لكتابة البيانات قبل أن يكون الـ كتلة السابق قد أُدرج بعد في insert_quorum من النسخ المتماثلة. وقد يحدث هذا إذا حاول المستخدم تنفيذ استعلام INSERT آخر على الجدول نفسه قبل اكتمال الاستعلام السابق الذي يستخدم insert_quorum.

انظر أيضًا:

insert_quorum_timeout
insert_quorum_parallel
select_sequential_consistency

insert_quorum_parallel

لا ينطبق هذا الإعداد على SharedMergeTree، راجع SharedMergeTree consistency لمزيد من المعلومات.

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

0 — معطّل.
1 — مُمكّن.

انظر أيضًا:

insert_quorum
insert_quorum_timeout
select_sequential_consistency

insert_quorum_timeout

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

insert_quorum
insert_quorum_parallel
select_sequential_consistency

insert_shard_id

إذا لم تكن القيمة 0، فإنها تحدد الشارد في جدول Distributed الذي ستُدرج فيه البيانات بشكل متزامن. إذا كانت قيمة insert_shard_id غير صحيحة، فسيُطلق الخادم استثناءً. للحصول على عدد الشاردات في requested_cluster، يمكنك التحقق من إعدادات الخادم أو استخدام هذا الاستعلام:

SELECT uniq(shard_num) FROM system.clusters WHERE cluster = 'requested_cluster';

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

0 — معطّل.
أي رقم من 1 إلى shards_num للجدول Distributed المقابل.

مثال الاستعلام:

CREATE TABLE x AS system.numbers ENGINE = MergeTree ORDER BY number;
CREATE TABLE x_dist AS x ENGINE = Distributed('test_cluster_two_shards_localhost', currentDatabase(), x);
INSERT INTO x_dist SELECT * FROM numbers(5) SETTINGS insert_shard_id = 1;
SELECT * FROM x_dist ORDER BY number ASC;

النتيجة:

┌─number─┐
│      0 │
│      0 │
│      1 │
│      1 │
│      2 │
│      2 │
│      3 │
│      3 │
│      4 │
│      4 │
└────────┘

interactive_delay

الفاصل الزمني، بالميكروثانية، للتحقق مما إذا كان تنفيذ الطلب قد أُلغي ولإرسال معلومات التقدّم.

intersect_default_mode

يحدد الوضع الافتراضي في استعلام INTERSECT. القيم الممكنة: سلسلة فارغة، ‘ALL’، ‘DISTINCT’. إذا كانت فارغة، فسيؤدي الاستعلام بدون وضع إلى طرح استثناء.

jemalloc_collect_profile_samples_in_trace_log

يجمع عينات التخصيص وإلغاء التخصيص الخاصة بـ jemalloc في سجل التتبّع.

jemalloc_enable_profiler

يُفعِّل Profiler الخاص بـ jemalloc للاستعلام. سيأخذ jemalloc عينات من التخصيصات وجميع عمليات إلغاء التخصيص المرتبطة بالتخصيصات التي أُخذت منها عينات. يمكن تفريغ بيانات Profiler باستخدام SYSTEM JEMALLOC FLUSH PROFILE، ويمكن استخدام ذلك لتحليل التخصيصات. يمكن أيضًا تخزين العينات في system.trace_log باستخدام الإعداد jemalloc_collect_global_profile_samples_in_trace_log أو إعداد الاستعلام jemalloc_collect_profile_samples_in_trace_log. راجع تحليل التخصيصات

jemalloc_profile_text_collapsed_use_count

عند استخدام صيغة الإخراج ‘collapsed’ لملف heap profile في jemalloc، يُجرى التجميع حسب عدد التخصيصات بدلًا من البايتات. وعندما تكون القيمة false (الافتراضية)، يُوزَن كل مكدس بحسب البايتات الحية؛ وعندما تكون true، يُوزَن بحسب عدد التخصيصات الحية.

jemalloc_profile_text_output_format

تنسيق الإخراج لملف heap profile الخاص بـ jemalloc في جدول system.jemalloc_profile_text. يمكن أن يكون: ‘raw’ (ملف تعريف خام)، أو ‘symbolized’ (تنسيق jeprof مع الرموز)، أو ‘collapsed’ (تنسيق FlameGraph).

jemalloc_profile_text_symbolize_with_inline

ما إذا كان يجب تضمين الإطارات المضمّنة عند إجراء symbolization لـ heap profile في jemalloc. عند التمكين، تُضمَّن الإطارات المضمّنة، مما قد يبطئ عملية symbolization بشكل كبير؛ وعند التعطيل، يتم تخطيها. يؤثر ذلك فقط في تنسيقات الإخراج ‘symbolized’ و ‘collapsed’.

join_algorithm

يحدّد خوارزمية JOIN المستخدمة. يمكن تحديد عدة خوارزميات، ويُختار منها ما هو مناسب للاستعلام المعني وفقًا لـ kind/صرامة وtable engine. القيم الممكنة:

grace_hash

تُستخدم Grace hash join. توفّر Grace hash خيار خوارزمية يتيح تنفيذ joins معقّدة بكفاءة عالية مع الحد من استهلاك الذاكرة. في المرحلة الأولى من grace join، يُقرأ الجدول الأيمن ويُقسَّم إلى N buckets بحسب hash value الخاصة بـ key columns (وتكون N في البداية هي grace_hash_join_initial_buckets). ويُنفَّذ ذلك بطريقة تضمن إمكانية معالجة كل bucket بصورة مستقلة. تُضاف rows من bucket الأول إلى hash table في الذاكرة، بينما تُحفَظ buckets الأخرى على disk. وإذا نما hash table متجاوزًا memory limit (على سبيل المثال كما هو محدد بواسطة max_bytes_in_join)، فسيُزاد عدد buckets وكذلك bucket المخصّص لكل row. وتُفرَّغ أي rows لا تنتمي إلى bucket الحالي وتُعاد إعادة إسنادها. يدعم INNER/LEFT/RIGHT/FULL ALL/ANY JOIN.

hash

تُستخدم Hash join algorithm. وهي أكثر التنفيذات عمومية، إذ تدعم جميع تركيبات kind وصرامة، بالإضافة إلى عدة join keys مدمجة باستخدام OR في قسم JOIN ON. عند استخدام خوارزمية hash، يُحمَّل الجزء الأيمن من JOIN إلى RAM.

parallel_hash

شكل مختلف من hash join يقسّم البيانات إلى buckets ويبني عدة hashtables بدلًا من جدول واحد بالتوازي لتسريع هذه العملية. عند استخدام خوارزمية parallel_hash، يُحمَّل الجزء الأيمن من JOIN إلى RAM.

partial_merge

شكل مختلف من sort-merge algorithm، حيث يُفرَز الجدول الأيمن بالكامل فقط. لا يُدعَم RIGHT JOIN وFULL JOIN إلا مع صرامة من النوع ALL (SEMI وANTI وANY وASOF غير مدعومة). عند استخدام خوارزمية partial_merge، يقوم ClickHouse بفرز البيانات وتفريغها إلى disk. تختلف خوارزمية partial_merge في ClickHouse قليلًا عن التنفيذ التقليدي. أولًا، يفرز ClickHouse الجدول الأيمن حسب join keys على شكل blocks، ويُنشئ min-max index للـ blocks المرتبة. ثم يفرز أجزاءً من الجدول الأيسر حسب join key ويُجري join عليها مع الجدول الأيمن. ويُستخدم min-max index أيضًا لتخطي blocks غير اللازمة من الجدول الأيمن.

direct

تُجري خوارزمية direct (المعروفة أيضًا باسم nested loop) عملية lookup في الجدول الأيمن باستخدام rows من الجدول الأيسر بوصفها keys. وهي مدعومة من storages خاصة مثل Dictionary وEmbeddedRocksDB وMergeTree tables. بالنسبة إلى MergeTree tables، تدفع الخوارزمية مرشحات join key مباشرةً إلى storage layer. ويمكن أن يكون ذلك أكثر كفاءة عندما يمكن للمفتاح استخدام primary key index الخاص بالجدول في عمليات lookup، وإلا فإنها تُجري full scans للجدول الأيمن لكل left table block. يدعم INNER وLEFT joins، كما يدعم فقط مفاتيح join قائمة على المساواة لعمود واحد ومن دون شروط أخرى.

auto

عند ضبطها على auto، تتم تجربة hash join أولًا، ثم تُبدَّل الخوارزمية أثناء التنفيذ إلى خوارزمية أخرى إذا جرى تجاوز memory limit.

full_sorting_merge

تُستخدم Sort-merge algorithm مع فرز كامل للجداول المنضمّة قبل تنفيذ join.

prefer_partial_merge

يحاول ClickHouse دائمًا استخدام partial_merge join إن أمكن، وإلا فإنه يستخدم hash. هذا الخيار Deprecated، وهو مماثل لـ partial_merge,hash.

default (deprecated)

قيمة قديمة، يُرجى عدم استخدامها بعد الآن. وهي مماثلة لـ direct,hash، أي محاولة استخدام direct join ثم hash join (بهذا الترتيب).

join_any_take_last_row

يغيّر سلوك عمليات JOIN ذات الصرامة ANY.

ينطبق هذا الإعداد فقط على عمليات JOIN مع جداول محرك Join.

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

0 — إذا كان الجدول الأيمن يحتوي على أكثر من صف مطابق واحد، فسيُضم أول صف يتم العثور عليه فقط.
1 — إذا كان الجدول الأيمن يحتوي على أكثر من صف مطابق واحد، فسيُضم آخر صف يتم العثور عليه فقط.

انظر أيضًا:

join_default_strictness

يضبط الصرامة الافتراضية لـ عبارات JOIN. القيم الممكنة:

ALL — إذا كان الجدول الأيمن يحتوي على عدة صفوف متطابقة، يُنشئ ClickHouse الجداء الديكارتي من الصفوف المتطابقة. هذا هو سلوك JOIN المعتاد في SQL القياسية.
ANY — إذا كان الجدول الأيمن يحتوي على عدة صفوف متطابقة، فلا يُضمّ إلا أول صف يتم العثور عليه. وإذا كان الجدول الأيمن يحتوي على صف متطابق واحد فقط، فستكون نتائج ANY وALL متطابقة.
ASOF — لربط التسلسلات التي تكون المطابقة فيها غير مؤكدة.
Empty string — إذا لم يتم تحديد ALL أو ANY في الاستعلام، فسيُصدر ClickHouse استثناءً.

join_on_disk_max_files_to_merge

يحدّ من عدد الملفات المسموح به للفرز المتوازي في عمليات MergeJoin عند تنفيذها على القرص. كلما زادت قيمة هذا الإعداد، زاد استخدام RAM وقلّت الحاجة إلى عمليات الإدخال/الإخراج على القرص. القيم الممكنة:

أي عدد صحيح موجب يبدأ من 2.

join_output_by_rowlist_perkey_rows_threshold

الحد الأدنى لمتوسط عدد الصفوف لكل مفتاح في الجدول الأيمن لتحديد ما إذا كان سيتم الإخراج باستخدام قائمة الصفوف في hash join.

join_overflow_mode

يحدّد هذا الإعداد الإجراء الذي ينفّذه ClickHouse عندما تصل عملية join إلى أيٍّ من الحدود التالية:

لا يُراعى هذا الإعداد إلا مع قيم join_algorithm من النوعين hash وparallel_hash. أما الخوارزميات الأخرى (على سبيل المثال، partial_merge وgrace_hash وauto) فتتعامل مع هذه الحدود بطريقة مختلفة — مثل الكتابة إلى القرص، أو إعادة التقسيم، أو تبديل الاستراتيجية — راجع join_algorithm. القيم الممكنة:

THROW — يُطلق ClickHouse استثناءً ويوقف الاستعلام.
BREAK — يوقف ClickHouse الاستعلام ولا يُطلق استثناءً.

القيمة الافتراضية: THROW. راجع أيضًا

join_runtime_bloom_filter_bytes

حجم مرشح bloom، بالبايتات، المستخدم كمرشح وقت التشغيل لعملية JOIN (راجع الإعداد enable_join_runtime_filters).

join_runtime_bloom_filter_hash_functions

عدد دوال التجزئة في مرشح bloom المستخدم كـ مرشح وقت التشغيل لعملية JOIN (راجع الإعداد enable_join_runtime_filters).

join_runtime_bloom_filter_max_ratio_of_set_bits

إذا تجاوز عدد البتات المضبوطة في مرشح Bloom وقت التشغيل هذه النسبة، فسيُعطَّل المرشح بالكامل لتقليل الحمل الإضافي.

join_runtime_filter_blocks_to_skip_before_reenabling

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

join_runtime_filter_exact_values_limit

الحد الأقصى لعدد العناصر في مرشّح وقت التشغيل التي تُخزَّن كما هي في مجموعة. عند تجاوز هذه العتبة، يتم التحويل إلى مرشح bloom.

join_runtime_filter_from_fixed_hash_table

عندما يُحوَّل جانب البناء في hash join إلى FixedHashMap (راجع enable_join_fixed_hash_table_conversion)، استخدم خريطة التجزئة هذه مباشرةً كمرشح وقت التشغيل.

join_runtime_filter_pass_ratio_threshold_for_disabling

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

join_to_sort_maximum_table_rows

الحد الأقصى لعدد الصفوف في الجدول الأيمن لتحديد ما إذا كان ينبغي إعادة ترتيب الجدول الأيمن حسب المفتاح في حالة left or inner join.

join_to_sort_minimum_perkey_rows

الحد الأدنى لمتوسط عدد الصفوف لكل مفتاح في الجدول الأيمن لتحديد ما إذا كان ينبغي إعادة ترتيب الجدول الأيمن حسب المفتاح في LEFT JOIN أو INNER JOIN. يضمن هذا الإعداد عدم تطبيق هذا التحسين على مفاتيح الجداول المتناثرة

join_use_nulls

يحدّد هذا الإعداد سلوك JOIN. عند دمج الجداول، قد تظهر خلايا فارغة. ويقوم ClickHouse بملئها بطرق مختلفة وفقًا لهذا الإعداد. القيم الممكنة:

0 — تُملأ الخلايا الفارغة بالقيمة الافتراضية لنوع الحقل المقابل.
1 — يتصرف JOIN بالطريقة نفسها المتّبعة في SQL القياسي. ويُحوَّل نوع الحقل المقابل إلى Nullable، وتُملأ الخلايا الفارغة بـ NULL.

joined_block_split_single_row

يسمح بتقسيم نتيجة hash join إلى أجزاء بحسب الصفوف المرتبطة بصف واحد من الجدول الأيسر. قد يقلل ذلك من استخدام الذاكرة عندما يكون هناك صف له عدد كبير من المطابقات في الجدول الأيمن، لكنه قد يزيد من استخدام CPU. لاحظ أن max_joined_block_size_rows != 0 شرط إلزامي لكي يكون لهذا الإعداد أي تأثير. كما يساعد max_joined_block_size_bytes مع هذا الإعداد على تجنب الاستخدام المفرط للذاكرة في حالات البيانات غير المتوازنة، حيث تحتوي بعض الصفوف الكبيرة على عدد كبير من المطابقات في الجدول الأيمن.

joined_subquery_requires_alias

يفرض استخدام أسماء مستعارة للاستعلامات الفرعية في عمليات join ولدوال الجداول لضمان تأهيل الأسماء بشكل صحيح.

kafka_disable_num_consumers_limit

يعطّل الحد المفروض على kafka_num_consumers والمعتمد على عدد نوى CPU المتاحة.

kafka_max_wait_ms

مدة الانتظار، بالمللي ثانية، لقراءة الرسائل من Kafka قبل إعادة المحاولة. القيم الممكنة:

عدد صحيح موجب.
0 — مهلة غير محدودة.

انظر أيضًا:

Apache Kafka

keeper_map_strict_mode

يفرض عمليات تحقّق إضافية أثناء تنفيذ العمليات على KeeperMap. على سبيل المثال، يُطلِق استثناءً عند تنفيذ insert لمفتاح موجود مسبقًا

keeper_max_retries

الحد الأقصى لمرات إعادة المحاولة لعمليات Keeper العامة

keeper_retry_initial_backoff_ms

مهلة التراجع الأولي لعمليات Keeper العامة

keeper_retry_max_backoff_ms

أقصى مهلة تراجع لعمليات Keeper العامة

least_greatest_legacy_null_behavior

إذا كان مُمكّنًا، تُرجِع الدالتان ‘least’ و ‘greatest’ القيمة NULL إذا كانت إحدى وسيطاتهما NULL.

legacy_column_name_of_tuple_literal

استخدم جميع أسماء عناصر قيم Tuple الحرفية الكبيرة في أسماء الأعمدة بدلًا من التجزئة. هذا الإعداد موجود فقط لأسباب التوافق. ومن المنطقي ضبطه على ‘true’ أثناء إجراء تحديث متدرج للعنقود من إصدار أقل من 21.7 إلى إصدار أعلى.

lightweight_delete_mode

وضع لاستعلام التحديث الداخلي الذي يُنفَّذ كجزء من الحذف خفيف الوزن. القيم الممكنة:

alter_update - شغّل استعلام ALTER UPDATE الذي ينشئ mutation كثيفة الوزن.
lightweight_update - شغّل تحديثًا خفيف الوزن إن أمكن، وإلا فشغّل ALTER UPDATE.
lightweight_update_force - شغّل تحديثًا خفيف الوزن إن أمكن، وإلا فارفع استثناءً.

lightweight_deletes_sync

مماثل لـ mutations_sync، لكنه يتحكم فقط في تنفيذ عمليات الحذف الخفيف. القيم الممكنة:

القيمة	الوصف
`0`	تُنفَّذ عمليات mutation بشكل غير متزامن.
`1`	ينتظر الاستعلام حتى تكتمل عمليات الحذف الخفيف على الخادم الحالي.
`2`	ينتظر الاستعلام حتى تكتمل عمليات الحذف الخفيف على جميع النسخ المتماثلة (إن وُجدت).
`3`	ينتظر الاستعلام اكتمالها على النسخ المتماثلة النشطة فقط. وهو مدعوم فقط لـ `SharedMergeTree`. أما بالنسبة إلى `ReplicatedMergeTree`، فيتصرف بالطريقة نفسها كما في `mutations_sync = 2`.

انظر أيضًا

القيمة الافتراضية في Cloud: 1.

limit

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

0 — عدد الصفوف غير مقيّد.
عدد صحيح موجب.

load_balancing

يحدّد خوارزمية اختيار النسخ المتماثلة المستخدمة في معالجة الاستعلامات الموزعة. يدعم ClickHouse خوارزميات اختيار النسخ المتماثلة التالية:

Random (افتراضيًا)
Nearest hostname
Hostname levenshtein distance
Hostname longest common prefix
Hostname longest common suffix
In order
First or random
Round robin

انظر أيضًا:

distributed_replica_max_ignored_errors

Random (الإعداد الافتراضي)

load_balancing = random

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

أقرب اسم مضيف

load_balancing = nearest_hostname

يُحتسب عدد الأخطاء لكل نسخة متماثلة. وكل 5 دقائق، يُقسَّم عدد الأخطاء قسمةً صحيحة على 2. وبذلك، يُحتسب عدد الأخطاء لفترة زمنية حديثة مع تنعيم أُسّي. إذا كانت هناك نسخة متماثلة واحدة ذات أقل عدد من الأخطاء (أي إن الأخطاء وقعت مؤخرًا على النسخ المتماثلة الأخرى)، يُرسَل الاستعلام إليها. وإذا وُجدت عدة نسخ متماثلة لها أقل عدد من الأخطاء نفسه، يُرسَل الاستعلام إلى النسخة المتماثلة التي يكون اسم المضيف الخاص بها الأكثر تشابهًا مع اسم مضيف الخادم في ملف الإعدادات (بحسب عدد الأحرف المختلفة في المواضع نفسها، حتى الحد الأدنى لطول اسمي المضيفين). فعلى سبيل المثال، يختلف example01-01-1 و example01-01-2 في موضع واحد، بينما يختلف example01-01-1 و example01-02-2 في موضعين. قد تبدو هذه الطريقة بدائية، لكنها لا تتطلب بيانات خارجية عن طوبولوجيا الشبكة، كما أنها لا تقارن عناوين IP، وهو ما سيكون معقدًا في حالة عناوين IPv6 لدينا. وبذلك، إذا كانت هناك نسخ متماثلة متكافئة، فستُفضَّل الأقرب من حيث الاسم. ويمكننا أيضًا افتراض أنه عند إرسال استعلام إلى الخادم نفسه، وفي حال عدم وجود حالات فشل، فإن الاستعلام الموزع سيتجه أيضًا إلى الخوادم نفسها. لذلك، حتى إذا وُضعت بيانات مختلفة على النسخ المتماثلة، فسيُرجع الاستعلام في الغالب النتائج نفسها.

مسافة ليفنشتاين لاسم المضيف

load_balancing = hostname_levenshtein_distance

تمامًا مثل nearest_hostname، لكنه يقارن اسم المضيف بناءً على مسافة Levenshtein. على سبيل المثال:

example-clickhouse-0-0 ample-clickhouse-0-0
1

example-clickhouse-0-0 example-clickhouse-1-10
2

example-clickhouse-0-0 example-clickhouse-12-0
3

أطول بادئة مشتركة لاسم المضيف

load_balancing = hostname_longest_common_prefix

تمامًا مثل nearest_hostname، لكن تُفضَّل النسخة المتماثلة التي يتشارك اسم مضيفها أطول بادئة مشتركة مع اسم المضيف المحلي (فكلما زاد طول البادئة المشتركة، ارتفعت الأولوية). وخلافًا لـ nearest_hostname، الذي يحسب الأحرف المختلفة حرفًا بحرف بحسب مواضعها، فإن هذه الاستراتيجية لا تلتبس عليها أسماء المضيفين التي تختلف أطوال مقاطعها الرقمية. على سبيل المثال، بالنسبة إلى اسم المضيف المحلي sfe301:

sfe301 sde301
1

sfe301 sfe10101
3

sfe301 sde505
1

هنا يُفضَّل sfe10101 لأنه يشترك مع sfe301 في أطول بادئة مشتركة (sfe، بطول 3). تُختار النسخ المتماثلة التي لها الطول نفسه للبادئة المشتركة عشوائيًا. وعلى وجه الخصوص، عندما لا تشترك أي نسخة متماثلة في أي بادئة مع اسم المضيف المحلي (أي تكون جميع أطوال البادئة المشتركة صفرًا)، تعمل هذه الاستراتيجية تمامًا مثل random.

أطول لاحقة مشتركة لاسم المضيف

load_balancing = hostname_longest_common_suffix

تمامًا مثل hostname_longest_common_prefix، لكن تُقارَن أطول لاحقة مشتركة بدلًا من البادئة. ويكون هذا مفيدًا عندما تكون هوية مركز البيانات مُشفَّرة في لاحقة اسم المضيف. على سبيل المثال، بالنسبة إلى اسم المضيف المحلي et46gtghn.qc.localdomain:

et46gtghn.qc.localdomain tr676ddgh.td.localdomain
12

et46gtghn.qc.localdomain ab999.qc.localdomain
15

هنا يُفضَّل ab999.qc.localdomain لأنه يطابق أطول لاحقة مشتركة (.qc.localdomain، بطول 15) مع et46gtghn.qc.localdomain. تُختار النُسخ المتماثلة ذات اللاحقة المشتركة المتساوية في الطول عشوائيًا. وعلى وجه الخصوص، عندما لا تتشارك أي نسخة متماثلة أي لاحقة مع اسم المضيف المحلي (أي عندما تكون جميع أطوال اللواحق المشتركة صفرًا)، فإن هذه الاستراتيجية تعمل تمامًا مثل random.

حسب الترتيب

load_balancing = in_order

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

الأول أو العشوائي

load_balancing = first_or_random

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

التناوب الدوري

load_balancing = round_robin

تستخدم هذه الخوارزمية سياسة التناوب عبر النسخ المتماثلة التي لها العدد نفسه من الأخطاء (لا تُؤخذ في الحسبان إلا الاستعلامات التي تستخدم سياسة round_robin).

load_balancing_first_offset

إلى أي نسخة متماثلة يُفضَّل إرسال الاستعلام عند استخدام استراتيجية موازنة الحمل FIRST_OR_RANDOM.

load_marks_asynchronously

تحميل علامات MergeTree بصورة غير متزامنة القيمة الافتراضية في Cloud: 1.

local_filesystem_read_method

طريقة قراءة البيانات من نظام الملفات المحلي، وهي إحدى الطرق التالية: read، pread، mmap، io_uring، pread_threadpool. الطريقة ‘io_uring’ تجريبية، ولا تعمل مع Log وTinyLog وStripeLog وFile وSet وJoin، ولا مع الجداول الأخرى ذات الملفات القابلة للإلحاق عند وجود عمليات قراءة وكتابة متزامنة. إذا قرأت مقالات مختلفة عن ‘io_uring’ على الإنترنت، فلا تنخدع بها. فهي ليست طريقة أفضل لقراءة الملفات، إلا في حالة وجود عدد كبير من طلبات IO الصغيرة، وهذا ليس هو الحال في ClickHouse. ولا توجد أي أسباب تدعو إلى تمكين ‘io_uring’.

local_filesystem_read_prefetch

يُستخدم الجلب المسبق عند قراءة البيانات من نظام الملفات المحلي.

lock_acquire_timeout

يحدّد عدد الثواني التي ينتظرها طلب القفل قبل أن يفشل. تُستخدم مهلة القفل للحماية من حالات الجمود أثناء تنفيذ عمليات القراءة/الكتابة على الجداول. وعند انتهاء المهلة وفشل طلب القفل، يطرح خادم ClickHouse الاستثناء “Locking attempt timed out! Possible deadlock avoided. Client should retry.” مع رمز الخطأ DEADLOCK_AVOIDED. القيم الممكنة:

عدد صحيح موجب (بالثواني).
0 — لا توجد مهلة للقفل.

log_comment

يحدّد قيمة الحقل log_comment في جدول system.query_log، وكذلك نص التعليق في سجل الخادم. يمكن استخدامه لتحسين سهولة قراءة سجلات الخادم. بالإضافة إلى ذلك، يساعد في تحديد الاستعلامات المرتبطة بالاختبار من system.query_log بعد تشغيل clickhouse-test. القيم الممكنة:

أي سلسلة نصية لا يزيد طولها عن max_query_size. إذا تم تجاوز max_query_size، فإن الخادم يُطلق استثناءً.

مثال الاستعلام:

SET log_comment = 'log_comment test', log_queries = 1;
SELECT 1;
SYSTEM FLUSH LOGS;
SELECT type, query FROM system.query_log WHERE log_comment = 'log_comment test' AND event_date >= yesterday() ORDER BY event_time DESC LIMIT 2;

النتيجة:

┌─type────────┬─query─────┐
│ QueryStart  │ SELECT 1; │
│ QueryFinish │ SELECT 1; │
└─────────────┴───────────┘

log_formatted_queries

يتيح تسجيل الاستعلامات المنسَّقة في جدول النظام system.query_log (ويعبّئ العمود formatted_query في system.query_log). القيم الممكنة:

0 — لا تُسجَّل الاستعلامات المنسَّقة في جدول النظام.
1 — تُسجَّل الاستعلامات المنسَّقة في جدول النظام.

log_processors_profiles

يكتب الوقت الذي قضاه المعالج أثناء التنفيذ/انتظار البيانات في الجدول system.processors_profile_log. انظر أيضًا:

log_profile_events

يسجّل إحصاءات أداء الاستعلام في query_log وquery_thread_log وquery_views_log.

log_queries

إعداد لتسجيل الاستعلامات. تُسجَّل الاستعلامات المُرسلة إلى ClickHouse باستخدام هذا الإعداد وفقًا للقواعد المحددة في معلَمة تكوين الخادم query_log. مثال:

log_queries=1

log_queries_cut_to_length

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

log_queries_min_query_duration_ms

إذا كان هذا الإعداد مفعّلًا (بقيمة غير صفرية)، فلن تُسَّجل الاستعلامات التي تكون أسرع من القيمة المحددة فيه (يمكنك اعتباره بمثابة long_query_time في MySQL Slow Query Log)، وهذا يعني عمليًا أنك لن تجدها في الجداول التالية:

system.query_log
system.query_thread_log

لن تُسجَّل إلا الاستعلامات من النوع التالي:

QUERY_FINISH
EXCEPTION_WHILE_PROCESSING
النوع: مللي ثانية
القيمة الافتراضية: 0 (أي استعلام)

log_queries_min_type

النوع الأدنى الذي سيتم تسجيله في query_log. القيم الممكنة:

QUERY_START (=1)
QUERY_FINISH (=2)
EXCEPTION_BEFORE_START (=3)
EXCEPTION_WHILE_PROCESSING (=4)

يمكن استخدامه لتقييد الكيانات التي ستُسجَّل في query_log؛ فإذا كنت مهتمًا بالأخطاء فقط، يمكنك استخدام EXCEPTION_WHILE_PROCESSING:

log_queries_min_type='EXCEPTION_WHILE_PROCESSING'

log_queries_probability

يسمح للمستخدم بتسجيل عيّنة فقط من الاستعلامات في جداول النظام query_log وquery_thread_log وquery_views_log، بحيث تُختار عشوائيًا وفق الاحتمال المحدد. ويساعد ذلك على تقليل الحمل عند وجود عدد كبير من الاستعلامات في الثانية. القيم الممكنة:

0 — لا تُسجَّل الاستعلامات في جداول النظام.
عدد موجب بفاصلة عائمة ضمن النطاق [0..1]. على سبيل المثال، إذا كانت قيمة الإعداد 0.5، فسيُسجَّل نحو نصف الاستعلامات في جداول النظام.
1 — تُسجَّل جميع الاستعلامات في جداول النظام.

log_query_settings

يسجّل إعدادات الاستعلام في query_log وفي سجل span الخاص بـ OpenTelemetry.

log_query_threads

إعداد لتسجيل خيوط تنفيذ الاستعلامات. تُسجَّل خيوط تنفيذ الاستعلامات في جدول system.query_thread_log. لا يسري هذا الإعداد إلا عندما تكون قيمة log_queries هي true. وتُسجَّل خيوط تنفيذ الاستعلامات التي يشغّلها ClickHouse باستخدام هذا الإعداد وفقًا للقواعد المحددة في مَعلَمة تهيئة الخادم query_thread_log. القيم الممكنة:

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

مثال

log_query_threads=1

log_query_views

إعداد تسجيل عروض الاستعلامات. عندما يكون للاستعلام الذي ينفّذه ClickHouse، مع تفعيل هذا الإعداد، عروض مرتبطة (العروض المادية أو العروض الحية)، تُسجَّل هذه العروض في مَعلمة تهيئة الخادم query_views_log. مثال:

log_query_views=1

low_cardinality_allow_in_native_format

يسمح هذا الإعداد باستخدام نوع البيانات LowCardinality مع تنسيق Native أو يقيّد ذلك. إذا كان استخدام LowCardinality مقيّدًا، فإن ClickHouse server يحوّل أعمدة LowCardinality إلى أعمدة عادية في استعلامات SELECT، ويحوّل الأعمدة العادية إلى أعمدة LowCardinality في استعلامات INSERT. يكون هذا الإعداد مطلوبًا بشكل أساسي لبرامج client التابعة لجهات خارجية التي لا تدعم نوع البيانات LowCardinality. القيم الممكنة:

1 — استخدام LowCardinality غير مقيّد.
0 — استخدام LowCardinality مقيّد.

low_cardinality_max_dictionary_size

يحدّد الحد الأقصى لحجم القاموس العام المشترك، بعدد الصفوف، لنوع البيانات LowCardinality الذي يمكن كتابته إلى نظام ملفات التخزين. يمنع هذا الإعداد حدوث مشكلات في RAM في حال نمو القاموس بلا حدود. وتكتب ClickHouse جميع البيانات التي يتعذر ترميزها بسبب تقييد الحد الأقصى لحجم القاموس بالطريقة العادية. القيم الممكنة:

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

low_cardinality_use_single_dictionary_for_part

يؤدي إلى تشغيل أو إيقاف استخدام قاموس واحد لجزء البيانات. بشكل افتراضي، يراقب خادم ClickHouse حجم القواميس، وإذا تجاوز أحدها سعته، يبدأ الخادم في كتابة القاموس التالي. ولمنع إنشاء عدة قواميس، اضبط low_cardinality_use_single_dictionary_for_part = 1. القيم الممكنة:

1 — يُمنع إنشاء عدة قواميس لجزء البيانات.
0 — لا يُمنع إنشاء عدة قواميس لجزء البيانات.

low_priority_query_wait_time_ms

عند استخدام آلية تحديد أولوية الاستعلامات (راجع الإعداد priority)، تنتظر الاستعلامات منخفضة الأولوية حتى تنتهي الاستعلامات ذات الأولوية الأعلى. يحدّد هذا الإعداد مدة الانتظار.

make_distributed_plan

إنشاء خطة للاستعلامات الموزعة.

materialize_skip_indexes_on_insert

يحدّد ما إذا كانت عمليات INSERT تُنشئ فهارس التجاوز وتُخزّنها. وإذا كان هذا الخيار معطّلًا، فلن تُنشأ فهارس التجاوز ولن تُخزَّن إلا أثناء عمليات الدمج أو عبر MATERIALIZE INDEX بشكل صريح. انظر أيضًا exclude_materialize_skip_indexes_on_insert.

materialize_statistics_on_insert

ما إذا كانت عمليات INSERT تُنشئ الإحصاءات وتُدرجها. إذا كان هذا الخيار معطّلًا، فستُنشأ الإحصاءات وتُخزَّن أثناء عمليات الدمج أو عبر تنفيذ MATERIALIZE STATISTICS صراحةً

materialize_ttl_after_modify

تطبيق TTL على البيانات القديمة بعد تنفيذ استعلام ALTER MODIFY TTL

materialized_views_ignore_errors

إذا كان مفعّلًا، فتُسجَّل الاستثناءات التي تحدث أثناء دفع البيانات إلى عرض مادي تابع (في SELECT الخاص به أو في sink الجدول الداخلي) على أنها تحذير، وتنجح عبارة INSERT. وإذا كان معطّلًا (وهو الوضع الافتراضي)، فسينتقل هذا الاستثناء وتفشل عبارة INSERT. يتحكم هذا الإعداد في الإبلاغ عن الأخطاء فقط. فهو لا يتسبب في التراجع عن الكتابة إلى الجدول المصدر، ولا يضمن ما إذا كانت الكتلة الأصلية قد تم commit لها بالفعل إلى الجدول المصدر عند حدوث خطأ في pipeline لعرض تابع. وعند تعطيله (وهو الوضع الافتراضي)، تفشل INSERT عند حدوث خطأ في عرض — أعد المحاولة باستخدام إزالة تكرار الإدراج (insert_deduplicate, deduplicate_blocks_in_dependent_materialized_views) لضمان التسليم مرة واحدة بالضبط إلى الجدول المصدر وجميع العروض التابعة. وعند تفعيله، تُبلّغ INSERT عن النجاح رغم التسليم الجزئي إلى العروض التي حدث فيها فشل والسلاسل اللاحقة التابعة لها؛ استخدم هذا فقط عندما يجب ألا تُحجَب عمليات الكتابة إلى الجدول المصدر بسبب مشكلات في جانب العرض (على سبيل المثال، جداول system.*_log). راجع وثائق CREATE VIEW للاطلاع على الدلالات الكاملة.

materialized_views_squash_parallel_inserts

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

max_analyze_depth

الحد الأقصى لعدد عمليات التحليل التي يُجريها المفسّر.

max_ast_depth

الحد الأقصى لعمق تداخل الشجرة النحوية للاستعلام. وإذا تم تجاوزه، يُرفَع استثناء.

في الوقت الحالي، لا يُتحقَّق من ذلك أثناء التحليل، بل فقط بعد تحليل الاستعلام. وهذا يعني أنه يمكن إنشاء شجرة نحوية عميقة جدًا أثناء التحليل، لكن الاستعلام سيفشل.

max_ast_elements

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

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

max_autoincrement_series

الحد الأقصى لعدد السلاسل التي تنشئها الدالة generateSerialID. وبما أن كل سلسلة تمثل عقدة في Keeper، يُوصى بألا يتجاوز عددها بضعة ملايين.

max_backup_bandwidth

الحد الأقصى لسرعة القراءة، بالبايت في الثانية، لنسخة احتياطية معيّنة على الخادم. تعني القيمة صفر عدم وجود حد.

max_block_size

في ClickHouse، تُعالَج البيانات على شكل كتل، وهي مجموعات من أجزاء الأعمدة. وتكون دورات المعالجة الداخلية لكتلة واحدة فعّالة، لكن توجد تكاليف ملحوظة عند معالجة كل كتلة. يشير الإعداد max_block_size إلى الحد الأقصى الموصى به لعدد الصفوف التي ينبغي تضمينها في كتلة واحدة عند تحميل البيانات من الجداول. ولا تُحمَّل كتل بحجم max_block_size دائمًا من الجدول: فإذا قرر ClickHouse أن هناك حاجة إلى استرجاع بيانات أقل، فستُعالَج كتلة أصغر. يجب ألا يكون حجم الكتلة صغيرًا جدًا لتجنّب التكاليف الملحوظة عند معالجة كل كتلة. كما يجب ألا يكون كبيرًا جدًا لضمان تنفيذ الاستعلامات التي تحتوي على عبارة LIMIT بسرعة بعد معالجة الكتلة الأولى. عند ضبط max_block_size، ينبغي أن يكون الهدف هو تجنّب استهلاك قدر كبير من الذاكرة عند استخراج عدد كبير من الأعمدة باستخدام عدة خيوط، مع الحفاظ على قدرٍ ما على الأقل من محلية ذاكرة التخزين المؤقت.

max_bytes_before_external_group_by

القيمة الافتراضية في Cloud: نصف مقدار الذاكرة لكل نسخة متماثلة. يُفعّل أو يعطّل تنفيذ عبارات GROUP BY باستخدام الذاكرة الخارجية. (راجع GROUP BY in external memory) القيم الممكنة:

الحد الأقصى لحجم RAM (بالبايت) الذي يمكن أن تستخدمه عملية GROUP BY واحدة.
0 — تعطيل GROUP BY في الذاكرة الخارجية.

إذا تجاوز استخدام الذاكرة أثناء عمليات GROUP BY هذه العتبة (بالبايت)، فسيتم تفعيل وضع «التجميع الخارجي» (كتابة البيانات المؤقتة إلى القرص).القيمة الموصى بها هي نصف ذاكرة النظام المتاحة.

max_bytes_before_external_join

إذا ضُبطت على قيمة غير صفرية وكان join_algorithm هو hash أو parallel_hash أو default أو auto، فسيتم تحويل hash join تلقائيًا إلى grace hash join لتمكين التفريغ إلى القرص عندما تتجاوز البيانات الموجودة في الجانب الأيمن هذا العدد من البايتات. وعند ضبطها على 0 (الافتراضي)، تُعطَّل عتبة البايت المطلقة هذه، لكن قد يظل التفريغ التلقائي يحدث عبر max_bytes_ratio_before_external_join (الذي تكون قيمته الافتراضية 0.5)؛ اضبط كليهما على 0 لتعطيل التفريغ التلقائي بالكامل. ويمنع ذلك تحسين read in order through join.

max_bytes_before_external_sort

القيمة الافتراضية في Cloud: نصف مقدار الذاكرة لكل نسخة متماثلة. يؤدي إلى تمكين أو تعطيل تنفيذ عبارات ORDER BY في الذاكرة الخارجية. راجع تفاصيل تنفيذ ORDER BY إذا تجاوز استخدام الذاكرة أثناء عملية ORDER BY هذه العتبة، محسوبًا بالبايتات، فسيتم تفعيل وضع “الفرز الخارجي” (كتابة البيانات إلى القرص). القيم الممكنة:

الحد الأقصى لحجم RAM (بالبايتات) الذي يمكن أن تستخدمه عملية ORDER BY واحدة. القيمة الموصى بها هي نصف ذاكرة النظام المتاحة
0 — تعطيل ORDER BY في الذاكرة الخارجية.

max_bytes_before_remerge_sort

في حالة استخدام ORDER BY مع LIMIT، عندما يتجاوز استخدام الذاكرة العتبة المحددة، تُنفَّذ خطوات إضافية لدمج الكتل قبل الدمج النهائي للاحتفاظ فقط بأعلى عدد LIMIT من الصفوف.

max_bytes_for_lazy_final

الحد الأقصى لعدد البايتات في المجموعة من أجل تحسين FINAL الكسول. وإذا تم تجاوزه، فسيجري الرجوع إلى FINAL العادي.

max_bytes_in_distinct

الحد الأقصى لعدد البايتات الخاصة بالحالة (بالبايتات غير المضغوطة) في الذاكرة، والتي يستخدمها جدول التجزئة عند استخدام DISTINCT.

max_bytes_in_join

الحد الأقصى للحجم بالبايت لبنية البيانات الموجودة على الجانب الأيمن (وعادةً ما تكون جدول تجزئة) المستخدَمة عند ربط الجداول. ينطبق هذا الإعداد على عمليات SELECT … JOIN وعلى محرك الجدول Join. إذا كان الاستعلام يحتوي على عدة عمليات JOIN، فإن ClickHouse يتحقق من هذا الإعداد لكل نتيجة وسيطة. وعند بلوغ الحد، يعتمد الإجراء على join_algorithm المختار — راجع ذلك الإعداد لمعرفة السلوك الخاص بكل خوارزمية (spill، أو إعادة التقسيم، أو التبديل، أو throw/break وفقًا لـ join_overflow_mode). القيم الممكنة:

عدد صحيح موجب.
0 — يتم تعطيل التحكم في الذاكرة.

max_bytes_in_set

الحد الأقصى لعدد البايتات (من البيانات غير المضغوطة) التي تستخدمها مجموعة في جملة IN التي أُنشئت من استعلام فرعي.

max_bytes_ratio_before_external_group_by

النسبة من الذاكرة المتاحة المسموح باستخدامها مع GROUP BY. وعند بلوغ هذا الحد، تُستخدم الذاكرة الخارجية للتجميع. على سبيل المثال، إذا ضُبطت على 0.6، فسيسمح GROUP BY باستخدام 60% من الذاكرة المتاحة (server/user/merges) في بداية التنفيذ، وبعد ذلك سيبدأ باستخدام التجميع الخارجي.

max_bytes_ratio_before_external_join

نسبة الذاكرة المتاحة المسموح باستخدامها لـ JOIN. وعند الوصول إليها، سيُحوَّل hash join إلى grace hash join لتفريغ بيانات الجانب الأيمن إلى القرص. على سبيل المثال، إذا ضُبطت على 0.6، فسيسمح JOIN باستخدام 60% من الذاكرة المتاحة (لـ server/user/merges) لجدول التجزئة الخاص بالجانب الأيمن في بداية التنفيذ؛ وبعد ذلك يبدأ التفريغ إلى القرص. إذا كان كلٌّ من max_bytes_before_external_join وmax_bytes_ratio_before_external_join مضبوطَين، فستُستخدم عتبة النتيجة الأصغر. وإذا كانت النسبة 0، فلن يُطبَّق إلا الإعداد المطلق. لا يكون له تأثير إلا عندما تكون قيمة join_algorithm هي hash أو parallel_hash أو default أو auto، وعندما يكون مسار بيانات مؤقت مُهيّأً.

max_bytes_ratio_before_external_sort

هي نسبة الذاكرة المتاحة المسموح باستخدامها مع ORDER BY. وعند بلوغها، يُستخدم الفرز الخارجي. على سبيل المثال، إذا ضُبطت على 0.6، فسيسمح ORDER BY باستخدام 60% من الذاكرة المتاحة (على مستوى server/user/merges) في بداية التنفيذ، وبعد ذلك سيبدأ باستخدام الفرز الخارجي. لاحظ أن max_bytes_before_external_sort يظل مُطبَّقًا، ولن يتم التفريغ إلى القرص إلا إذا كانت كتلة الفرز أكبر من max_bytes_before_external_sort.

max_bytes_to_read

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

max_bytes_to_read_leaf

الحد الأقصى لعدد البايتات (من البيانات غير المضغوطة) التي يمكن قراءتها من جدول محلي على عقدة طرفية عند تنفيذ استعلام موزع. ومع أن الاستعلامات الموزعة قد ترسل عدة استعلامات فرعية إلى كل shard ‏(leaf)، فلن يُتحقق من هذا الحد إلا في مرحلة القراءة على العقد الطرفية، وسيُتجاهل في مرحلة دمج النتائج على العقدة الجذرية. على سبيل المثال، يتكون الـ cluster من shardين، ويحتوي كل shard على جدول فيه 100 بايت من البيانات. إن استعلامًا موزعًا من المفترض أن يقرأ جميع البيانات من كلا الجدولين مع الإعداد max_bytes_to_read=150 سيفشل لأن الإجمالي سيكون 200 بايت. أما الاستعلام الذي يستخدم max_bytes_to_read_leaf=150 فسينجح لأن العقد الطرفية ستقرأ 100 بايت كحد أقصى. يُتحقق من هذا القيد لكل chunk من البيانات تتم معالجته.

هذا الإعداد غير مستقر مع prefer_localhost_replica=1.

max_bytes_to_sort

الحد الأقصى لعدد البايتات قبل الفرز. إذا استلزم تنفيذ عملية ORDER BY معالجة كمية من البايتات غير المضغوطة تتجاوز المقدار المحدد، فسيُحدَّد السلوك وفقًا للإعداد sort_overflow_mode، والذي يكون مضبوطًا افتراضيًا على throw.

max_bytes_to_transfer

الحد الأقصى لعدد البايتات (البيانات غير المضغوطة) التي يمكن تمريرها إلى خادم بعيد أو حفظها في جدول مؤقت عند تنفيذ قسم GLOBAL IN/JOIN.

max_columns_to_read

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

هذا الإعداد مفيد لمنع الاستعلامات المعقدة أكثر من اللازم.

تعني القيمة 0 عدم وجود حد.

max_compress_block_size

الحد الأقصى لحجم كتل البيانات غير المضغوطة قبل ضغطها عند الكتابة إلى جدول. القيمة الافتراضية هي 1,048,576 ‏(1 MiB). ويؤدي تحديد حجم كتلة أصغر، بشكل عام، إلى انخفاض طفيف في نسبة الضغط، مع زيادة طفيفة في سرعة الضغط وفك الضغط بسبب محلية ذاكرة التخزين المؤقت، إضافةً إلى تقليل استهلاك الذاكرة.

هذا إعداد مخصّص للمستخدمين الخبراء، ولا ينبغي تغييره إذا كنت لا تزال في بداية استخدام ClickHouse.

لا تخلط بين الكتل المستخدمة للضغط (جزء من الذاكرة يتكوّن من بايتات) والكتل المستخدمة في معالجة الاستعلامات (مجموعة من الصفوف من جدول).

max_concurrent_queries_for_all_users

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

عدد صحيح موجب.
0 — بلا حد.

مثال

<max_concurrent_queries_for_all_users>99</max_concurrent_queries_for_all_users>

راجع أيضًا

max_concurrent_queries

القيمة الافتراضية في Cloud: 1000.

max_concurrent_queries_for_user

الحد الأقصى لعدد الاستعلامات التي تُعالَج في الوقت نفسه لكل مستخدم. القيم الممكنة:

عدد صحيح موجب.
0 — بدون حد.

مثال

<max_concurrent_queries_for_user>5</max_concurrent_queries_for_user>

max_consume_snapshots

الحد الأقصى لعدد لقطات Paimon التي يمكن استهلاكها في كل قراءة تزايدية. 0 تعني عدم وجود حد.

max_distributed_connections

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

max_distributed_depth

يحدّد الحد الأقصى لعمق الاستعلامات التكرارية لجداول Distributed. إذا تم تجاوز هذه القيمة، يرفع الخادم استثناءً. القيم الممكنة:

عدد صحيح موجب.
0 — عمق غير محدود.

max_download_buffer_size

الحد الأقصى لحجم المخزن المؤقت للتنزيل المتوازي (مثلًا لمحرك URL) لكل خيط تنفيذ.

max_download_threads

الحد الأقصى لعدد سلاسل التنفيذ لتنزيل البيانات (مثلًا لمحرك URL).

max_estimated_execution_time

الحد الأقصى للوقت التقديري لتنفيذ الاستعلام، بالثواني. ويُتحقَّق منه عند كل كتلة بيانات عند انقضاء timeout_before_checking_execution_speed.

max_execution_speed

الحد الأقصى لعدد صفوف التنفيذ في الثانية. يُتحقَّق من ذلك عند كل كتلة بيانات عند انتهاء مهلة timeout_before_checking_execution_speed. إذا كانت سرعة التنفيذ مرتفعة، فستُخفَّض.

max_execution_speed_bytes

الحد الأقصى لعدد بايتات التنفيذ في الثانية. يُتحقَّق منه عند كل كتلة بيانات عند انتهاء timeout_before_checking_execution_speed. إذا كانت سرعة التنفيذ مرتفعة، فستُخفَّض.

max_execution_time

الحد الأقصى لوقت تنفيذ الاستعلام، بالثواني. قد يكون فهم المعلَمة max_execution_time مربكًا بعض الشيء. فهي تعمل بالاستناد إلى الاستيفاء وفقًا لسرعة تنفيذ الاستعلام الحالية (ويُتحكَّم في هذا السلوك بواسطة timeout_before_checking_execution_speed). سيقوم ClickHouse بإيقاف الاستعلام إذا تجاوز وقت التنفيذ المقدَّر قيمة max_execution_time المحددة. افتراضيًا، تُضبط timeout_before_checking_execution_speed على 10 ثوانٍ. وهذا يعني أنه بعد مرور 10 ثوانٍ على تنفيذ الاستعلام، سيبدأ ClickHouse في تقدير إجمالي وقت التنفيذ. فإذا كانت max_execution_time، على سبيل المثال، مضبوطة على 3600 ثانية (ساعة واحدة)، فسينهي ClickHouse الاستعلام إذا تجاوز الوقت المقدَّر هذا الحد البالغ 3600 ثانية. وإذا ضبطت timeout_before_checking_execution_speed على 0، فسيستخدم ClickHouse الوقت الفعلي أساسًا لـ max_execution_time. إذا تجاوز وقت تشغيل الاستعلام عدد الثواني المحدد، فسيتحدد السلوك بواسطة timeout_overflow_mode، والتي تُضبط افتراضيًا على throw.

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

max_execution_time_leaf

مشابه من حيث المعنى لـ max_execution_time، لكنه يُطبَّق فقط على العقد الطرفية في الاستعلامات الموزعة أو البعيدة. على سبيل المثال، إذا أردنا تقييد وقت التنفيذ على عقدة طرفية إلى 10s، ولكن من دون أي حد على العقدة الأولية، فبدلًا من وضع max_execution_time في إعدادات الاستعلام الفرعي المتداخل:

SELECT count()
FROM cluster(cluster, view(SELECT * FROM t SETTINGS max_execution_time = 10));

يمكننا استخدام max_execution_time_leaf ضمن إعدادات الاستعلام:

SELECT count()
FROM cluster(cluster, view(SELECT * FROM t)) SETTINGS max_execution_time_leaf = 10;

max_expanded_ast_elements

الحد الأقصى لحجم شجرة البنية النحوية للاستعلام، من حيث عدد العُقد، بعد توسيع الأسماء المستعارة وعلامة النجمة.

max_fetch_partition_retries_count

عدد مرات إعادة المحاولة عند جلب partition من مضيف آخر.

max_final_threads

يحدّد الحد الأقصى لعدد خيوط التنفيذ المتوازية لمرحلة قراءة البيانات في استعلام SELECT مع المُعدِّل FINAL. القيم الممكنة:

عدد صحيح موجب.
0 أو 1 — معطّل. تُنفَّذ استعلامات SELECT باستخدام خيط تنفيذ واحد.

max_http_get_redirects

الحد الأقصى لعدد قفزات إعادة التوجيه المسموح بها لطلبات HTTP GET. يضمن ذلك تطبيق تدابير أمان إضافية لمنع خادم خبيث من إعادة توجيه طلباتك إلى خدمات غير متوقعة.\n\nتحدث هذه الحالة عندما يعيد خادم خارجي التوجيه إلى عنوان آخر، لكن هذا العنوان يبدو داخليًا ضمن البنية التحتية للشركة. وعند إرسال طلب HTTP إلى خادم داخلي، قد تتمكن من طلب واجهة برمجة تطبيقات داخلية من الشبكة الداخلية، متجاوزًا المصادقة، أو حتى إجراء استعلامات على خدمات أخرى مثل Redis أو Memcached. إذا لم تكن لديك بنية تحتية داخلية (بما في ذلك أي شيء يعمل على localhost)، أو كنت تثق بالخادم، فمن الآمن السماح بإعادات التوجيه. ومع ذلك، ضع في اعتبارك أنه إذا كان الـ URL يستخدم HTTP بدلًا من HTTPS، فسيتعين عليك الوثوق ليس فقط بالخادم البعيد، بل أيضًا بمزوّد خدمة الإنترنت لديك وبكل شبكة تقع بينكما. القيمة الافتراضية في Cloud: 10.

max_hyperscan_regexp_length

يحدّد الحد الأقصى لطول كل تعبير نمطي في دوال hyperscan multi-match. القيم الممكنة:

عدد صحيح موجب.
0 - الطول غير محدود.

مثال الاستعلام:

SELECT multiMatchAny('abcd', ['ab','bcd','c','d']) SETTINGS max_hyperscan_regexp_length = 3;

النتيجة:

┌─multiMatchAny('abcd', ['ab', 'bcd', 'c', 'd'])─┐
│                                              1 │
└────────────────────────────────────────────────┘

الاستعلام:

SELECT multiMatchAny('abcd', ['ab','bcd','c','d']) SETTINGS max_hyperscan_regexp_length = 2;

النتيجة:

Exception: Regexp length too large.

انظر أيضًا

max_hyperscan_regexp_total_length

max_hyperscan_regexp_total_length

يحدِّد الحد الأقصى لإجمالي أطوال جميع التعبيرات النمطية في كل hyperscan multi-match function. القيم الممكنة:

عدد صحيح موجب.
0 - الطول غير مقيَّد.

مثال الاستعلام:

SELECT multiMatchAny('abcd', ['a','b','c','d']) SETTINGS max_hyperscan_regexp_total_length = 5;

النتيجة:

┌─multiMatchAny('abcd', ['a', 'b', 'c', 'd'])─┐
│                                           1 │
└─────────────────────────────────────────────┘

الاستعلام:

SELECT multiMatchAny('abcd', ['ab','bc','c','d']) SETTINGS max_hyperscan_regexp_total_length = 5;

النتيجة:

Exception: Total regexp lengths too large.

انظر أيضًا

max_hyperscan_regexp_length

max_insert_block_size

الأسماء البديلة: max_insert_block_size_rows الحد الأقصى لحجم الكتل (من حيث عدد الصفوف) التي يتم تشكيلها لإدراجها في جدول. يتحكم هذا الإعداد في تشكيل الكتل ضمن سياقين:

تحليل التنسيقات: عندما يحلل الخادم تنسيقات الإدخال المعتمدة على الصفوف (مثل CSV وTSV وJSONEachRow وغيرها) من أي واجهة (HTTP، أو clickhouse-client مع البيانات المضمّنة inline، أو gRPC، أو PostgreSQL wire protocol)، يتم إصدار الكتل عند:
- الوصول إلى كلٍّ من min_insert_block_size_rows وmin_insert_block_size_bytes معًا، OR
- الوصول إلى أيٍّ من max_insert_block_size_rows أو max_insert_block_size_bytes
ملاحظة: عند استخدام clickhouse-client أو clickhouse-local للقراءة من ملف، يتولى العميل نفسه تحليل البيانات، ويُطبَّق هذا الإعداد من جهة العميل.
عمليات INSERT: أثناء استعلامات INSERT وعندما تتدفق البيانات عبر العروض المادية، يعتمد سلوك هذا الإعداد على use_strict_insert_block_limits:
- عند التمكين: يتم إصدار الكتل عندما:
  - الحدود الدنيا (AND): يتم الوصول إلى كلٍّ من min_insert_block_size_rows وmin_insert_block_size_bytes معًا
  - الحدود القصوى (OR): يتم الوصول إلى أيٍّ من max_insert_block_size_rows أو max_insert_block_size_bytes
- عند التعطيل: يتم إصدار الكتل عند الوصول إلى min_insert_block_size_rows أو min_insert_block_size_bytes. ولا يتم فرض إعدادات max_insert_block_size.

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

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

max_insert_block_size_bytes

الحد الأقصى لحجم الكتل (بالبايتات) التي يجري تكوينها للإدراج في جدول. يعمل هذا الإعداد مع max_insert_block_size_rows، ويتحكمان معًا في تكوين الكتل في السياق نفسه. راجع max_insert_block_size_rows للحصول على معلومات تفصيلية حول وقت وكيفية تطبيق هذه الإعدادات. القيم الممكنة:

عدد صحيح موجب.
0 — لا يشارك الإعداد في تكوين الكتل.

max_insert_delayed_streams_for_parallel_write

الحد الأقصى لعدد التدفقات (الأعمدة) التي يُؤجَّل عندها التفريغ النهائي للجزء. القيمة الافتراضية: تلقائي (100 إذا كانت طبقة التخزين الأساسية تدعم الكتابة المتوازية، مثل S3، وتكون معطَّلة بخلاف ذلك) القيمة الافتراضية في Cloud: 50.

max_insert_threads

الحد الأقصى لعدد الخيوط المستخدمة لتنفيذ الاستعلام INSERT SELECT. القيم الممكنة:

0 (أو 1) — ‏INSERT SELECT بدون تنفيذ متوازٍ.
عدد صحيح موجب أكبر من 1.

القيمة الافتراضية في Cloud:

1 للعُقد التي تحتوي على ذاكرة بحجم 8 GiB
2 للعُقد التي تحتوي على ذاكرة بحجم 16 GiB
4 للعُقد الأكبر

لا يكون لـ INSERT SELECT المتوازي تأثير إلا إذا كان جزء SELECT يُنفَّذ على التوازي. راجع إعداد max_threads. ستؤدي القيم الأعلى إلى زيادة استخدام الذاكرة.

max_insert_threads_min_free_memory_per_thread

مماثل لـ max_threads_min_free_memory_per_thread، لكنه يُطبَّق على max_insert_threads بدلًا من max_threads. تكون القيمة الافتراضية أعلى لأن مسارات معالجة insert تحتفظ عادةً بمخازن مؤقتة أكبر لكل خيط (أجزاء MergeTree وكتل الضغط) مقارنةً بمسارات القراءة. إذا كانت كمية الذاكرة الحرة أقل من حاصل ضرب max_insert_threads في هذه القيمة، فسيُخفَّض max_insert_threads بما يتناسب مع ذلك، على ألا يقل عن 1. اضبطه على 0 لتعطيل هذا القيد.

max_joined_block_size_bytes

الحد الأقصى لحجم الكتلة، بالبايت، لنتيجة JOIN (إذا كانت خوارزمية JOIN تدعم ذلك). وتعني القيمة 0 عدم وجود حد.

max_joined_block_size_rows

الحد الأقصى لحجم الكتلة لنتيجة JOIN (إذا كانت خوارزمية JOIN تدعم ذلك). وتعني القيمة 0 عدم وجود حد.

max_limit_for_vector_search_queries

لا يمكن لاستعلامات SELECT التي تحتوي على LIMIT أكبر من هذا الإعداد استخدام فهارس تشابه المتجهات. يساعد ذلك على منع تجاوز سعة الذاكرة في فهارس تشابه المتجهات.

max_local_read_bandwidth

الحد الأقصى لمعدل القراءة المحلية بالبايت في الثانية.

max_local_write_bandwidth

السرعة القصوى لعمليات الكتابة المحلية، بالبايت في الثانية.

max_memory_usage

القيمة الافتراضية في Cloud: تعتمد على مقدار RAM في النسخة المتماثلة. الحد الأقصى لمقدار RAM الذي يمكن استخدامه لتشغيل استعلام على خادم واحد. وتعني القيمة 0 عدم وجود حد. لا يأخذ هذا الإعداد في الحسبان حجم الذاكرة المتاحة أو الحجم الإجمالي للذاكرة على الجهاز. وينطبق هذا التقييد على استعلام واحد ضمن خادم واحد. يمكنك استخدام SHOW PROCESSLIST لمعرفة استهلاك الذاكرة الحالي لكل استعلام. ويتم تتبّع ذروة استهلاك الذاكرة لكل استعلام وكتابتها في السجل. لا يتم تتبّع استخدام الذاكرة بالكامل لحالات الدوال التجميعية التالية من الوسيطات String وArray:

min
max
any
anyLast
argMin
argMax

كما يُقيَّد استهلاك الذاكرة أيضًا بواسطة المعلمتين max_memory_usage_for_user وmax_server_memory_usage.

max_memory_usage_for_user

الحد الأقصى لذاكرة RAM المسموح باستخدامها لتشغيل استعلامات المستخدم على خادم واحد. ويعني الصفر عدم وجود حد. بشكل افتراضي، لا يكون هذا المقدار مقيّدًا (max_memory_usage_for_user = 0). راجع أيضًا وصف max_memory_usage. على سبيل المثال، إذا أردت ضبط max_memory_usage_for_user على 1000 بايت لمستخدم باسم clickhouse_read، يمكنك استخدام عبارة statement

ALTER USER clickhouse_read SETTINGS max_memory_usage_for_user = 1000;

يمكنك التحقق من نجاح ذلك عبر تسجيل الخروج من عميلك، ثم تسجيل الدخول مجددًا، ثم استخدام الدالة getSetting:

SELECT getSetting('max_memory_usage_for_user');

max_network_bandwidth

يحدّ من سرعة نقل البيانات عبر الشبكة بالبايت في الثانية. ينطبق هذا الإعداد على كل استعلام. القيم الممكنة:

عدد صحيح موجب.
0 — يكون التحكم في عرض النطاق الترددي معطّلًا.

max_network_bandwidth_for_all_users

يحدّ من سرعة تبادل البيانات عبر الشبكة، بالبايت في الثانية. ينطبق هذا الإعداد على جميع الاستعلامات التي تعمل بالتزامن على الخادم. القيم الممكنة:

عدد صحيح موجب.
0 — يكون التحكم في سرعة نقل البيانات معطّلًا.

max_network_bandwidth_for_user

يحدّ من سرعة نقل البيانات عبر الشبكة بالبايت في الثانية. ينطبق هذا الإعداد على جميع الاستعلامات التي ينفذها مستخدم واحد بالتزامن. القيم الممكنة:

عدد صحيح موجب.
0 — يكون التحكّم في سرعة نقل البيانات معطّلًا.

max_network_bytes

يحدّد حجم البيانات (بالبايت) التي يتم استقبالها أو إرسالها عبر الشبكة عند تنفيذ استعلام. ينطبق هذا الإعداد على كل استعلام على حدة. القيم الممكنة:

عدد صحيح موجب.
0 — يكون التحكّم في حجم البيانات معطّلًا.

max_number_of_partitions_for_independent_aggregation

الحد الأقصى لعدد التقسيمات في الجدول لتطبيق التحسي

max_os_cpu_wait_time_ratio_to_throw

أقصى نسبة بين وقت انتظار CPU في نظام التشغيل (المقياس OSCPUWaitMicroseconds) ووقت الانشغال (المقياس OSCPUVirtualTimeMicroseconds) التي يُعتد بها لرفض الاستعلامات. ويُستخدم الاستيفاء الخطي بين الحدين الأدنى والأقصى لهذه النسبة لحساب الاحتمال؛ ويبلغ الاحتمال 1 عند هذه القيمة.

max_parallel_replicas

الحد الأقصى لعدد النسخ المتماثلة لكل شريحة عند تنفيذ استعلام. القيم الممكنة:

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

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

المعالجة المتوازية باستخدام مفتاح `SAMPLE`

قد تتم معالجة الاستعلام بشكل أسرع إذا نُفِّذ على عدة خوادم بالتوازي. لكن قد يتدهور أداء الاستعلام في الحالات التالية:

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

المعالجة المتوازية باستخدام parallel_replicas_custom_key

هذا الإعداد مفيد لأي جدول مُنسَّخ.

max_parser_backtracks

الحد الأقصى للتراجع في المُحلِّل (عدد المرات التي يجرّب فيها بدائل مختلفة أثناء عملية التحليل التنازلي التعاودي).

max_parser_depth

يحدّد الحد الأقصى لعمق الاستدعاء التعاودي في محلّل النزول التعاودي، ويتيح التحكّم في حجم المكدّس. القيم الممكنة:

عدد صحيح موجب.
0 — عمق الاستدعاء التعاودي غير محدود.

max_parsing_threads

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

max_partition_size_to_drop

قيد على إسقاط الأقسام أثناء تنفيذ الاستعلام. تعني القيمة 0 أنه يمكنك إسقاط الأقسام دون أي قيود. Cloud default value: 1 تيرابايت.

يحلّ إعداد الاستعلام هذا محل إعداد الخادم المكافئ له، راجع max_partition_size_to_drop

max_partitions_per_insert_block

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

عدد صحيح موجب.
0 — عدد غير محدود من الأقسام.

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

“عدد الأقسام كبير جدًا بالنسبة إلى كتلة INSERT واحدة (عدد الأقسام partitions_count، والحد هو ” + toString(max_partitions) + ”). يتم التحكم في هذا الحد بواسطة الإعداد ‘max_partitions_per_insert_block’. يُعد العدد الكبير من الأقسام من المفاهيم الخاطئة الشائعة. وسيؤدي ذلك إلى تأثير سلبي حاد على الأداء، بما في ذلك بطء تشغيل server، وبطء استعلامات INSERT وبطء استعلامات SELECT. العدد الإجمالي الموصى به للأقسام في table هو أقل من 1000..10000. يرجى ملاحظة أن partitioning ليس مخصصًا لتسريع استعلامات SELECT (يكفي order by key لجعل الاستعلامات النطاقية سريعة). الأقسام مخصصة لمعالجة البيانات (DROP PARTITION، إلخ).”

هذا الإعداد هو safety threshold لأن استخدام عدد كبير من الأقسام يُعد من المفاهيم الخاطئة الشائعة.

max_partitions_to_read

يحدّد الحد الأقصى لعدد الأقسام التي يمكن الوصول إليها في استعلام واحد. يمكن تجاوز قيمة الإعداد المحددة عند إنشاء الجدول باستخدام إعداد على مستوى الاستعلام. القيم الممكنة:

عدد صحيح موجب
-1 - غير محدود (الافتراضي)

يمكنك أيضًا تحديد إعداد MergeTree max_partitions_to_read ضمن إعدادات الجدول.

max_parts_to_move

يحدّد عدد الأجزاء التي يمكن نقلها في استعلام واحد. ويعني الصفر عدم وجود حد.

max_projection_rows_to_use_projection_index

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

max_query_size

الحد الأقصى لعدد البايتات في سلسلة الاستعلام التي يُحلّلها مُحلِّل SQL. تُعالَج البيانات في عبارة VALUES ضمن استعلامات INSERT بواسطة مُحلِّل دفق منفصل (يستهلك O(1) من RAM)، ولا تتأثر بهذا القيد.

لا يمكن تعيين max_query_size داخل استعلام SQL (على سبيل المثال، SELECT now() SETTINGS max_query_size=10000) لأن ClickHouse يحتاج إلى تخصيص مخزن مؤقت لتحليل الاستعلام، ويُحدَّد حجم هذا المخزن المؤقت بواسطة الإعداد max_query_size، الذي يجب تهيئته قبل تنفيذ الاستعلام.

max_rand_distribution_parameter

الحد الأقصى لمعاملات شكل التوزيع في دوال التوزيعات العشوائية مثل randChiSquared وrandStudentT وrandFisherF. يمنع ذلك فترات حساب طويلة جدًا عند استخدام قيم معاملات شديدة التطرف.

max_rand_distribution_trials

الحد الأقصى لعدد المحاولات المسموح به في دوال التوزيعات العشوائية مثل randBinomial وrandNegativeBinomial. يساعد ذلك على تجنب أزمنة حساب طويلة جدًا عند وجود عدد كبير من المحاولات.

max_read_buffer_size

أقصى حجم للمخزن المؤقت المستخدم للقراءة من نظام الملفات.

max_read_buffer_size_local_fs

الحد الأقصى لحجم المخزن المؤقت للقراءة من نظام الملفات المحلي. إذا ضُبطت على 0، فسيُستخدم max_read_buffer_size.

max_read_buffer_size_remote_fs

الحد الأقصى لحجم المخزن المؤقت المستخدم للقراءة من نظام الملفات البعيد. إذا ضُبطت القيمة على 0، فسيُستخدم max_read_buffer_size.

max_recursive_cte_evaluation_depth

الحد الأقصى لعمق تقييم CTE التكراري

max_remote_read_network_bandwidth

الحد الأقصى لمعدل نقل البيانات عبر الشبكة، بالبايت في الثانية، لعمليات القراءة.

max_remote_write_network_bandwidth

الحد الأقصى لسرعة نقل البيانات عبر الشبكة، بالبايت في الثانية، لعمليات الكتابة.

max_replica_delay_for_distributed_queries

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

عدد صحيح موجب.
0 — لا يتم التحقق من تأخر النسخ المتماثلة.

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

max_result_bytes

يفرض حدًا على حجم النتيجة بالبايت (غير مضغوط). سيتوقف الاستعلام بعد معالجة كتلة من البيانات إذا تم بلوغ العتبة، لكنه لن يقتطع آخر كتلة من النتيجة، لذلك قد يكون حجم النتيجة أكبر من العتبة. محاذير يُؤخَذ في الاعتبار حجم النتيجة في الذاكرة عند تطبيق هذه العتبة. حتى إذا كان حجم النتيجة صغيرًا، فقد يشير إلى هياكل بيانات أكبر في الذاكرة، مثل Dictionaries الخاصة بأعمدة LowCardinality، وساحات أعمدة AggregateFunction، لذلك قد تُتجاوز العتبة رغم صِغر حجم النتيجة.

هذا الإعداد منخفض المستوى نسبيًا، ويجب استخدامه بحذر

max_result_rows

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

max_reverse_dictionary_lookup_cache_size_bytes

الحد الأقصى للحجم بالبايت لذاكرة التخزين المؤقت لعملية lookup العكسي في القاموس على مستوى كل استعلام، والمستخدمة بواسطة الدالة dictGetKeys. تخزّن ذاكرة التخزين المؤقت Tupleات المفاتيح المُسلسلة لكل قيمة attribute لتجنّب إعادة فحص القاموس ضمن الاستعلام نفسه. عند بلوغ الحد الأقصى، تُزال العناصر وفق سياسة LRU. اضبطها على 0 لتعطيل التخزين المؤقت.

max_rows_for_lazy_final

الحد الأقصى لعدد الصفوف في المجموعة من أجل تحسين FINAL الكسول. وإذا تم تجاوزه، فسيتم الرجوع إلى FINAL العادي.

max_rows_in_distinct

الحد الأقصى لعدد الصفوف المميزة عند استخدام DISTINCT.

max_rows_in_join

يحدّ من عدد الصفوف في بنية البيانات الموجودة على الجانب الأيمن (وعادةً ما تكون جدول hash) والمستخدمة عند ربط الجداول. ينطبق هذا الإعداد على عمليات SELECT … JOIN وعلى محرك الجدول Join. إذا كان الاستعلام يحتوي على عدة عمليات join، فإن ClickHouse يفحص هذا الإعداد لكل نتيجة وسيطة. وعند بلوغ الحد، يعتمد الإجراء المتخذ على join_algorithm المحدد — راجع هذا الإعداد لمعرفة السلوك الخاص بكل خوارزمية (spill، أو إعادة partition، أو التبديل، أو throw/break وفقًا لـ join_overflow_mode). القيم الممكنة:

عدد صحيح موجب.
0 — عدد غير محدود من الصفوف.

max_rows_in_set

الحد الأقصى لعدد الصفوف في مجموعة البيانات داخل عبارة IN المُنشأة من استعلام فرعي.

max_rows_in_set_to_optimize_join

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

0 — تعطيل.
أي عدد صحيح موجب.

max_rows_to_group_by

الحد الأقصى لعدد المفاتيح الفريدة الناتجة عن التجميع. يتيح لك هذا الإعداد الحد من استهلاك الذاكرة عند إجراء التجميع. إذا كان التجميع أثناء GROUP BY يُنتج عددًا من الصفوف (مفاتيح GROUP BY الفريدة) أكبر من العدد المحدد، فسيُحدَّد السلوك بواسطة group_by_overflow_mode، التي تكون قيمتها الافتراضية throw، ولكن يمكن أيضًا التبديل إلى وضع GROUP BY تقريبي.

max_rows_to_read

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

max_rows_to_read_leaf

الحد الأقصى لعدد الصفوف التي يمكن قراءتها من جدول محلي على عقدة طرفية عند تشغيل استعلام موزّع. ورغم أن الاستعلامات الموزّعة قد تُصدر عدة استعلامات فرعية إلى كل شظية (طرفية)، فلن يُتحقق من هذا الحد إلا في مرحلة القراءة على العُقد الطرفية، وسيُتجاهل في مرحلة دمج النتائج على العقدة الجذرية. على سبيل المثال، يتكوّن العنقود من 2 شظية، ويحتوي كل شظية على جدول فيه 100 صف. سيفشل الاستعلام الموزّع الذي يُفترض أن يقرأ جميع البيانات من كلا الجدولين مع الإعداد max_rows_to_read=150، لأن العدد الإجمالي سيكون 200 صف. أما الاستعلام مع max_rows_to_read_leaf=150 فسينجح، لأن العُقد الطرفية لن تقرأ أكثر من 100 صف. يُتحقق من هذا القيد لكل دفعة بيانات مُعالَجة.

هذا الإعداد غير مستقر مع prefer_localhost_replica=1.

max_rows_to_sort

الحد الأقصى لعدد الصفوف قبل الفرز. يتيح لك هذا الحد من استهلاك الذاكرة عند الفرز. إذا كانت عملية ORDER BY تتطلب معالجة عدد من السجلات يتجاوز المقدار المحدد، فسيُحدَّد السلوك بواسطة sort_overflow_mode، والذي يكون مضبوطًا افتراضيًا على throw.

max_rows_to_transfer

الحد الأقصى لعدد الصفوف التي يمكن تمريرها إلى خادم بعيد أو حفظها في جدول مؤقت عند تنفيذ جزء GLOBAL IN/JOIN.

max_sessions_for_user

الحد الأقصى لعدد الجلسات المتزامنة لكل مستخدم موثَّق على خادم ClickHouse. مثال:

<profiles>
    <single_session_profile>
        <max_sessions_for_user>1</max_sessions_for_user>
    </single_session_profile>
    <two_sessions_profile>
        <max_sessions_for_user>2</max_sessions_for_user>
    </two_sessions_profile>
    <unlimited_sessions_profile>
        <max_sessions_for_user>0</max_sessions_for_user>
    </unlimited_sessions_profile>
</profiles>
<users>
    <!-- User Alice can connect to a ClickHouse server no more than once at a time. -->
    <Alice>
        <profile>single_session_user</profile>
    </Alice>
    <!-- User Bob can use 2 simultaneous sessions. -->
    <Bob>
        <profile>two_sessions_profile</profile>
    </Bob>
    <!-- User Charles can use arbitrarily many of simultaneous sessions. -->
    <Charles>
        <profile>unlimited_sessions_profile</profile>
    </Charles>
</users>

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

عدد صحيح موجب
0 - عدد غير محدود من الجلسات المتزامنة (الافتراضي)

max_size_to_preallocate_for_aggregation

لعدد العناصر التي يُسمح من أجلها بالتخصيص المسبق للمساحة في جميع جداول التجزئة إجمالًا قبل التجمي

max_size_to_preallocate_for_joins

عدد العناصر المسموح بالحجز المسبق للمساحة لها في جميع جداول التجزئة إجمالًا قبل joi

max_skip_unavailable_shards_num

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

max_skip_unavailable_shards_ratio

عند تمكين skip_unavailable_shards، يحدد هذا الإعداد الحد الأقصى للنسبة (من 0 إلى 1) للشظايا التي يمكن تخطيها بصمت. إذا تجاوزت نسبة الشظايا غير المتاحة إلى إجمالي الشظايا هذه القيمة، فسيتم إطلاق استثناء بدلًا من التخطي بصمت. تعني القيمة 0 عدم وجود حد (السلوك الافتراضي — يمكن تخطي جميع الشظايا غير المتاحة).

max_streams_for_files_processing_in_cluster_functions

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

max_streams_for_merge_tree_reading

إذا كانت القيمة غير صفرية، فسيُحدَّد عدد تدفقات القراءة لجدول MergeTree.

max_streams_for_union_step

يقيّد عدد تدفقات البيانات النشطة بالتزامن في خطوة UNION (وينطبق ذلك على كلٍّ من UNION ALL وUNION DISTINCT، لأن UNION DISTINCT يُنفَّذ من خلال خطوة UNION ALL تتبعها خطوة DISTINCT). عندما يحتوي استعلام UNION على عدد كبير من الاستعلامات الفرعية، فإنها جميعًا تفتح مخازن القراءة المؤقتة الخاصة بها في الوقت نفسه، مما يؤدي إلى استخدام للذاكرة يتناسب مع عدد الاستعلامات الفرعية. يُدرج هذا الإعداد معالجات Concat لتضييق خط المعالجة بحيث لا يكون نشطًا في وقت واحد أكثر من هذا العدد من التدفقات، مما يقلّل ذروة الذاكرة بشكل كبير. الحد الفعلي هو القيمة الصغرى بين هذه القيمة وmax_threads * max_streams_for_union_step_to_max_threads_ratio (إذا كانت أيٌّ منهما تساوي 0، فهذا يعني تجاهلها). وعندما تكون كلتا القيمتين 0، لا يُطبَّق أي تضييق. كذلك لا يُطبَّق هذا الحد عندما تتطلب خطة الاستعلام أن يبقى كل تدفق خرج من UNION مرتبًا بشكل مستقل (على سبيل المثال، عند تطبيق تحسين read-in-order عبر UNION)؛ ففي هذه الحالة تكون صحة الترتيب هي الأولوية ويُتجاوز التضييق.

max_streams_for_union_step_to_max_threads_ratio

تحدِّد هذه النسبة، عند ضربها في max_threads، حدًا أقصى لعدد التدفّقات النشطة بالتزامن في خطوة UNION (وينطبق ذلك على كلٍّ من UNION ALL وUNION DISTINCT). والحدّ الفعلي هو القيمة الدنيا بين هذه القيمة المحسوبة وmax_streams_for_union_step (وإذا كانت قيمة أيٍّ منهما 0، فسيتم تجاهلها). على سبيل المثال، إذا كان max_threads = 8 وكانت هذه النسبة مضبوطة على 1، فلن يكون هناك أكثر من 8 تدفّقات نشطة. اضبطها على 0 لتعطيل هذا الحدّ المستند إلى النسبة. ومثل max_streams_for_union_step، لا يُطبَّق هذا الحد عندما تتطلب خطة الاستعلام أن يبقى كل تدفّق خرج من UNION مرتّبًا على حدة.

max_streams_multiplier_for_merge_tables

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

max_streams_to_max_threads_ratio

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

max_subquery_depth

إذا كان الاستعلام يحتوي على عدد من الاستعلامات الفرعية المتداخلة يتجاوز العدد المحدد، فسيتم طرح استثناء.

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

max_table_size_to_drop

قيد على حذف الجداول وقت تنفيذ الاستعلام. تعني القيمة 0 أنه يمكنك حذف جميع الجداول دون أي قيود. Cloud default value: 1 TB.

يتجاوز إعداد الاستعلام هذا إعداد الخادم المكافئ له، راجع max_table_size_to_drop

max_temporary_columns

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

يفيد هذا الإعداد في منع الاستعلامات شديدة التعقيد.

تعني القيمة 0 عدم وجود حد.

max_temporary_data_on_disk_size_for_query

الحد الأقصى لكمية البيانات، بالبايت، التي تستهلكها الملفات المؤقتة على القرص عبر جميع الاستعلامات المتزامنة قيد التشغيل. القيم الممكنة:

عدد صحيح موجب.
0 — غير محدود (الافتراضي)

max_temporary_data_on_disk_size_for_user

الحد الأقصى لكمية البيانات التي تستهلكها الملفات المؤقتة على القرص، بالبايت، عبر جميع استعلامات المستخدم التي تعمل بالتوازي. القيم الممكنة:

عدد صحيح موجب.
0 — غير محدود (الافتراضي)

max_temporary_non_const_columns

مثل max_temporary_columns، هذا هو الحد الأقصى لعدد الأعمدة المؤقتة التي يجب الاحتفاظ بها في RAM في آنٍ واحد عند تنفيذ استعلام، ولكن من دون احتساب الأعمدة الثابتة.

غالبًا ما تتكوّن الأعمدة الثابتة عند تنفيذ استعلام، لكنها لا تتطلب عمليًا أي موارد حوسبة تُذكر.

max_threads

الحد الأقصى لعدد خيوط معالجة الاستعلام، باستثناء الخيوط المخصّصة لاسترجاع البيانات من الخوادم البعيدة (راجع المعلمة ‘max_distributed_connections’). تنطبق هذه المعلمة على خيوط التنفيذ التي تنفّذ المراحل نفسها من مسار معالجة الاستعلام بالتوازي. على سبيل المثال، عند القراءة من جدول، إذا كان من الممكن تقييم التعبيرات التي تتضمن دوال، والتصفية باستخدام WHERE، وإجراء التجميع المسبق لـ GROUP BY بالتوازي باستخدام عدد لا يقل عن ‘max_threads’ من خيوط التنفيذ، فسيُستخدم ‘max_threads’. بالنسبة إلى الاستعلامات التي تكتمل بسرعة بسبب LIMIT، يمكنك ضبط ‘max_threads’ على قيمة أقل. على سبيل المثال، إذا كان العدد المطلوب من الإدخالات موجودًا في كل كتلة وكان max_threads = 8، فسيجري استرجاع 8 كتل، رغم أن قراءة كتلة واحدة فقط كانت ستكفي. وكلما صغرت قيمة max_threads، قلّ استهلاك الذاكرة. يتوافق الإعداد max_threads افتراضيًا مع عدد الخيوط العتادية (عدد أنوية CPU) المتاحة لـ ClickHouse. وكحالة خاصة، بالنسبة إلى معالجات x86 التي تحتوي على أقل من 32 نواة CPU وتدعم SMT (مثل Intel HyperThreading)، يستخدم ClickHouse افتراضيًا عدد الأنوية المنطقية (= 2 × عدد الأنوية الفعلية). في حال عدم وجود SMT (مثل Intel HyperThreading)، فإن ذلك يتوافق مع عدد أنوية CPU. بالنسبة إلى مستخدمي ClickHouse Cloud، ستظهر القيمة الافتراضية على شكل auto(N) حيث يطابق N حجم vCPU الخاص بالخدمة لديك، مثل 2vCPU/8GiB و4vCPU/16GiB وما إلى ذلك. راجع علامة تبويب الإعدادات في Cloud Console للحصول على قائمة بجميع أحجام الخدمات.

max_threads_for_indexes

الحد الأقصى لعدد الخيوط التي تعالج الفهارس.

max_threads_min_free_memory_per_thread

يُخفِّض max_threads عندما يكون الخادم تحت ضغط الذاكرة، لتجنّب بدء استعلامات عالية التوازي يُرجَّح أن تتجاوز حد الذاكرة. تُحتسب الذاكرة الحرة على أنها max_server_memory_usage الخاص بالخادم مطروحًا منه الذاكرة التي يتتبعها حاليًا متتبّع الذاكرة العام. وإذا كانت هذه الذاكرة الحرة أقل من max_threads مضروبًا في هذه القيمة، فسيُخفَّض max_threads إلى أكبر قيمة N بحيث يكون N * value <= free_memory، على ألا يقل عن 1. اضبطها على 0 لتعطيل هذا القيد. على سبيل المثال، مع القيمة الافتراضية البالغة 1 GiB و32 GiB من الذاكرة الحرة، يُحدَّد الحد الأقصى لـ max_threads عند 32؛ ومع 1 GiB من الذاكرة الحرة ينخفض إلى 1. ينطبق هذا الإعداد على التوازي في جانب القراءة (SELECT وUNION وINTERSECT/EXCEPT، وكذلك جانب SELECT من INSERT ... SELECT). أمّا بالنسبة إلى جانب الكتابة، فانظر max_insert_threads_min_free_memory_per_thread.

max_untracked_memory

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

max_wkb_geometry_elements

الحد الأقصى لعدد النقاط أو الحلقات أو المضلعات المسموح بها في عنصر هندسة WKB واحد أثناء التحليل بواسطة readWKB والدوال ذات الصلة. يوفّر ذلك حماية من التخصيص المفرط للذاكرة الناتج عن بيانات WKB تالفة. اضبطه على 0 لاستخدام الحد المضمّن في الشيفرة (100 مليون).

memory_overcommit_ratio_denominator

يمثل هذا الحد المرن للذاكرة عند بلوغ الحد الصارم على المستوى العام. تُستخدم هذه القيمة لحساب نسبة overcommit للاستعلام. تعني القيمة صفر تجاهل الاستعلام. اقرأ المزيد عن memory overcommit.

memory_overcommit_ratio_denominator_for_user

يمثل حد الذاكرة المرن عند بلوغ الحد الصارم على مستوى المستخدم. تُستخدم هذه القيمة لاحتساب نسبة overcommit للاستعلام. تعني القيمة صفرًا تخطي الاستعلام. اقرأ المزيد عن memory overcommit.

memory_profiler_sample_max_allocation_size

يجمع تخصيصات ذاكرة عشوائية يكون حجمها أقل من القيمة المحددة أو مساويًا لها، باحتمال يساوي memory_profiler_sample_probability. وتعني القيمة 0 أن هذا الإعداد معطّل. قد ترغب في ضبط max_untracked_memory على 0 لكي تعمل هذه العتبة كما هو متوقع.

memory_profiler_sample_min_allocation_size

اجمع تخصيصات ذاكرة عشوائية بحجم أكبر من القيمة المحددة أو مساوٍ لها، باحتمال يساوي memory_profiler_sample_probability. تعني القيمة 0 أن هذا الخيار معطّل. قد ترغب في تعيين max_untracked_memory إلى 0 لكي تعمل هذه العتبة كما هو متوقّع.

memory_profiler_sample_probability

اجمع عمليات تخصيص الذاكرة وتحريرها العشوائية، واكتبها في system.trace_log مع trace_type بالقيمة ‘MemorySample’. تُطبَّق هذه الاحتمالية على كل عملية alloc/free بغضّ النظر عن حجم التخصيص (ويمكن تغيير ذلك باستخدام memory_profiler_sample_min_allocation_size و memory_profiler_sample_max_allocation_size). لاحظ أن أخذ العينات يحدث فقط عندما تتجاوز كمية الذاكرة غير المتعقَّبة القيمة ‘max_untracked_memory’. وقد ترغب في ضبط ‘max_untracked_memory’ على 0 للحصول على أخذ عينات أكثر دقة.

memory_profiler_step

يضبط قيمة step الخاصة بمُحلِّل الذاكرة. كلما أصبح استخدام الذاكرة في الاستعلام أكبر من كل خطوة تالية محسوبة بعدد البايتات، سيجمع مُحلِّل الذاكرة stacktrace الخاص بالتخصيص ويكتبه في trace_log. القيم الممكنة:

عدد صحيح موجب من البايتات.
القيمة 0 لإيقاف مُحلِّل الذاكرة.

memory_tracker_fault_probability

لاختبار exception safety، أطلق استثناءً في كل مرة يجري فيها تخصيص الذاكرة بالاحتمال المحدد.

memory_usage_overcommit_max_wait_microseconds

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

merge_table_max_tables_to_look_for_schema_inference

عند إنشاء جدول Merge بدون مخطط محدد صراحةً، أو عند استخدام table function ‏merge، يُستنتج المخطط على أنه اتحاد لما لا يزيد على العدد المحدد من الجداول المتطابقة. إذا كان عدد الجداول أكبر من ذلك، فسيُستنتج المخطط من أول عدد محدد من الجداول.

merge_tree_coarse_index_granularity

عند البحث عن البيانات، يفحص ClickHouse العلامات في ملف الفهرس. وإذا تبيّن لـ ClickHouse أن المفاتيح المطلوبة تقع ضمن نطاق معيّن، فإنه يقسم هذا النطاق إلى merge_tree_coarse_index_granularity نطاقات فرعية ويبحث فيها عن المفاتيح المطلوبة على نحوٍ تكراري. القيم الممكنة:

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

merge_tree_compact_parts_min_granules_to_multibuffer_read

لا يكون لهذا الإعداد تأثير إلا في ClickHouse Cloud. يحدد عدد الـ حبيبات في stripe ضمن compact part في MergeTree tables اللازم لاستخدام قارئ متعدد المخازن المؤقتة، الذي يدعم القراءة المتوازية وprefetch. عند القراءة من remote fs، يؤدي استخدام قارئ متعدد المخازن المؤقتة إلى زيادة عدد read request.

merge_tree_determine_task_size_by_prewhere_columns

ما إذا كان ينبغي استخدام حجم أعمدة prewhere فقط لتحديد حجم مهمة القراءة.

merge_tree_max_bytes_to_use_cache

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

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

merge_tree_max_rows_to_use_cache

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

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

merge_tree_min_bytes_for_concurrent_read

إذا تجاوز عدد البايتات المراد قراءتها من ملف واحد في جدول يستخدم محرك MergeTree القيمة merge_tree_min_bytes_for_concurrent_read، فسيحاول ClickHouse إجراء قراءة متزامنة لهذا الملف باستخدام عدة خيوط تنفيذ. القيمة الممكنة:

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

merge_tree_min_bytes_for_concurrent_read_for_remote_filesystem

الحد الأدنى لعدد البايتات التي يجب قراءتها من ملف واحد قبل أن يتمكن محرك MergeTree من موازاة القراءة عند القراءة من نظام ملفات بعيد. لا نوصي باستخدام هذا الإعداد. القيم الممكنة:

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

merge_tree_min_bytes_for_seek

إذا كانت المسافة بين كتلتَي بيانات مطلوب قراءتهما من ملف واحد أقل من merge_tree_min_bytes_for_seek بايت، فسيقرأ ClickHouse تسلسليًا نطاقًا من الملف يضم كلتا الكتلتين، متجنبًا بذلك إجراء seek إضافي. القيم الممكنة:

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

merge_tree_min_bytes_per_task_for_remote_reading

الأسماء البديلة: filesystem_prefetch_min_bytes_for_single_read_task الحد الأدنى لعدد البايتات المطلوب قراءتها لكل مهمة.

merge_tree_min_read_task_size

حد أدنى صارم لحجم المهمة (حتى عندما يكون عدد الحبيبات منخفضًا وعدد خيوط التنفيذ المتاحة مرتفعًا، فلن نخصص مهامًا أصغر

merge_tree_min_rows_for_concurrent_read

إذا تجاوز عدد الصفوف المطلوب قراءتها من ملف لجدول MergeTree القيمة merge_tree_min_rows_for_concurrent_read، فسيحاول ClickHouse إجراء قراءة متزامنة من هذا الملف باستخدام عدة خيوط تنفيذ. القيم الممكنة:

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

merge_tree_min_rows_for_concurrent_read_for_remote_filesystem

الحد الأدنى لعدد الأسطر المطلوب قراءتها من ملف واحد قبل أن يتمكن محرك MergeTree من موازاة القراءة عند القراءة من نظام ملفات بعيد. لا نوصي باستخدام هذا الإعداد. القيم الممكنة:

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

merge_tree_min_rows_for_seek

إذا كانت المسافة بين كتلتَي بيانات مطلوب قراءتهما من ملف واحد أقل من merge_tree_min_rows_for_seek صفًا، فلن يُجري ClickHouse عملية seek داخل الملف، بل سيقرأ البيانات بشكل متسلسل. القيم الممكنة:

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

merge_tree_read_split_ranges_into_intersecting_and_non_intersecting_injection_probability

لاختبار PartsSplitter — تقسيم نطاقات القراءة إلى نطاقات متداخلة وغير متداخلة في كل مرة تتم فيها القراءة من MergeTree، وذلك بالاحتمال المحدد.

merge_tree_storage_snapshot_sleep_ms

يُدرج تأخيرًا اصطناعيًا (بالمللي ثانية) عند إنشاء لقطة تخزين لجداول MergeTree. يُستخدم فقط لأغراض الاختبار وتصحيح الأخطاء. القيم الممكنة:

0 - بدون تأخير (الافتراضي)
N - تأخير بالمللي ثانية

merge_tree_use_const_size_tasks_for_remote_reading

ما إذا كان سيتم استخدام مهام ثابتة الحجم للقراءة من جدول بعيد.

merge_tree_use_deserialization_prefixes_cache

يُمكّن التخزين المؤقت للبيانات الوصفية للأعمدة من بادئات الملفات عند القراءة من الأقراص البعيدة في MergeTree.

merge_tree_use_prefixes_deserialization_thread_pool

يُمكّن استخدام مجمّع خيوط التنفيذ لقراءة البادئات بالتوازي في الأجزاء العريضة في MergeTree. ويُتحكَّم في حجم مجمّع خيوط التنفيذ هذا من خلال إعداد الخادم max_prefixes_deserialization_thread_pool_size.

merge_tree_use_v1_object_and_dynamic_serialization

عند التمكين، سيُستخدم الإصدار V1 من التسلسل لأنواع JSON وDynamic في MergeTree بدلًا من V2. ولا يسري تغيير هذا الإعداد إلا بعد إعادة تشغيل الخادم.

metrics_perf_events_enabled

إذا كان هذا الإعداد مفعّلًا، فسيُقاس بعض أحداث perf أثناء تنفيذ الاستعلامات.

metrics_perf_events_list

قائمة بمقاييس perf مفصولة بفواصل، وسيُجرى قياسها أثناء تنفيذ الاستعلامات. تعني القيمة الفارغة جميع الأحداث. راجع PerfEventInfo في الشيفرة المصدرية للاطلاع على الأحداث المتاحة.

min_bytes_to_use_direct_io

الحد الأدنى لحجم البيانات المطلوب لاستخدام الإدخال/الإخراج المباشر إلى قرص التخزين. يستخدم ClickHouse هذا الإعداد عند قراءة البيانات من الجداول. إذا تجاوز الحجم الإجمالي لجميع البيانات المراد قراءتها من التخزين min_bytes_to_use_direct_io بايت، فسيقرأ ClickHouse البيانات من قرص التخزين باستخدام الخيار O_DIRECT. القيم الممكنة:

0 — الإدخال/الإخراج المباشر معطّل.
عدد صحيح موجب.

min_bytes_to_use_mmap_io

هذا إعداد تجريبي. يحدد الحد الأدنى من الذاكرة لقراءة الملفات الكبيرة دون نسخ البيانات من النواة إلى فضاء المستخدم. القيمة الحدّية الموصى بها هي نحو 64 ميغابايت، لأن mmap/munmap بطيء. ولا يكون ذلك مجديًا إلا مع الملفات الكبيرة، ولا يساعد إلا إذا كانت البيانات موجودة في ذاكرة التخزين المؤقت للصفحات. القيم الممكنة:

عدد صحيح موجب.
0 — تُقرأ الملفات الكبيرة فقط مع نسخ البيانات من النواة إلى فضاء المستخدم.

min_chunk_bytes_for_parallel_parsing

النوع: عدد صحيح غير موقّع
القيمة الافتراضية: 1 MiB

الحد الأدنى لحجم الجزء بالبايتات الذي سيحلّله كل خيط تنفيذ بالتوازي.

min_compress_block_size

ينطبق على جداول MergeTree. لتقليل زمن الاستجابة عند معالجة الاستعلامات، تُضغط كتلة عند كتابة العلامة التالية إذا كان حجمها لا يقل عن min_compress_block_size. والقيمة الافتراضية هي 65,536. أما الحجم الفعلي للكتلة، فإذا كانت البيانات غير المضغوطة أقل من max_compress_block_size، فلن يكون أقل من هذه القيمة، ولا أقل من حجم البيانات الخاص بعلامة واحدة. لننظر إلى مثال. افترض أن index_granularity ضُبط على 8192 عند إنشاء الجدول. لنكتب عمودًا من النوع UInt32 ‏(4 بايت لكل قيمة). عند كتابة 8192 صفًا، يكون الإجمالي 32 كيلوبايت من البيانات. وبما أن min_compress_block_size = 65,536، فستتكوّن كتلة مضغوطة لكل علامتين. ولنكتب عمود URL من النوع String ‏(بمتوسط حجم 60 بايت لكل قيمة). عند كتابة 8192 صفًا، يكون المتوسط أقل قليلًا من 500 كيلوبايت من البيانات. وبما أن هذا أكبر من 65,536، فستتكوّن كتلة مضغوطة لكل علامة. في هذه الحالة، عند قراءة البيانات من القرص ضمن نطاق علامة واحدة، لن يلزم فك ضغط بيانات إضافية.

هذا إعداد مخصص للمستخدمين الخبراء، ولا ينبغي تغييره إذا كنت لا تزال في بداية استخدام ClickHouse.

min_count_to_compile_aggregate_expression

الحد الأدنى لعدد التعبيرات التجميعية المتطابقة اللازمة لبدء الترجمة الفورية JIT. لا يعمل هذا إلا إذا كان الإعداد compile_aggregate_expressions ممكّنًا. القيم الممكنة:

عدد صحيح موجب.
0 — تُترجَم التعبيرات التجميعية المتطابقة دائمًا ترجمة فورية باستخدام JIT.

min_count_to_compile_expression

الحد الأدنى لعدد مرات تنفيذ التعبير نفسه قبل أن يُجمَّع.

min_count_to_compile_sort_description

عدد أوصاف الترتيب المتطابقة قبل تجميعها باستخدام JIT

min_execution_speed

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

min_execution_speed_bytes

الحد الأدنى لعدد بايتات التنفيذ في الثانية. يُتحقَّق من ذلك عند كل كتلة بيانات عند انتهاء مهلة timeout_before_checking_execution_speed. إذا كانت سرعة التنفيذ أقل من ذلك، يُرفَع استثناء.

min_external_table_block_size_bytes

ادمج الكتل المُمرَّرة إلى الجدول الخارجي بحيث تصل إلى الحجم المحدد بالبايت، إذا لم تكن كبيرة بما يكفي.

min_external_table_block_size_rows

دمج الكتل المُمرَّرة إلى الجدول الخارجي لتصل إلى الحجم المحدد من حيث عدد الصفوف، إذا لم تكن كبيرة بما يكفي.

min_filtered_ratio_for_lazy_final

الحد الأدنى لنسبة العلامات التي يُصفّيها تحليل الفهرس من أجل تحسين FINAL الكسول. إذا كانت نسبة العلامات المُصفّاة أقل من هذه القيمة، فسيتم الرجوع إلى FINAL العادي. تؤدي القيمة 0 إلى تعطيل هذا الفحص.

min_free_disk_bytes_to_perform_insert

الحد الأدنى من بايتات المساحة الحرة على القرص المطلوبة لتنفيذ عملية إدراج.

min_free_disk_ratio_to_perform_insert

الحد الأدنى لنسبة المساحة الحرة على القرص اللازمة لتنفيذ عملية إدراج.

min_free_disk_space_for_temporary_data

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

min_hit_rate_to_use_consecutive_keys_optimization

الحد الأدنى لمعدل الإصابة لذاكرة التخزين المؤقت المستخدمة في تحسين المفاتيح المتتالية في التجميع، للإبقاء على هذا التحسين مفعّلًا

min_insert_block_size_bytes

الحد الأدنى لحجم الكتل (بالبايت) المطلوب تكوينها لإدراجها في جدول. يعمل هذا الإعداد مع min_insert_block_size_rows، ويتحكم في تكوين الكتل ضمن السياقات نفسها (تحليل التنسيق وعمليات INSERT). راجع min_insert_block_size_rows للحصول على معلومات تفصيلية حول متى وكيفية تطبيق هذه الإعدادات. القيم الممكنة:

عدد صحيح موجب.
0 — لا يشارك الإعداد في تكوين الكتل.

min_insert_block_size_bytes_for_materialized_views

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

أي عدد صحيح موجب.
0 — تعطيل الدمج.

انظر أيضًا

min_insert_block_size_bytes

min_insert_block_size_rows

الحد الأدنى لحجم الكتل (بالصفوف) التي يجب تكوينها للإدراج في جدول. يتحكم هذا الإعداد في تكوين الكتل ضمن سياقين:

تحليل التنسيق: عندما يحلّل الخادم تنسيقات الإدخال المعتمدة على الصفوف (CSV وTSV وJSONEachRow وغيرها) من أي واجهة (HTTP أو clickhouse-client مع بيانات Inline أو gRPC أو PostgreSQL wire protocol)، تُخرَج الكتل عندما:
- يتم بلوغ كلٍّ من min_insert_block_size_rows و min_insert_block_size_bytes، OR
- يتم بلوغ أحد max_insert_block_size_rows أو max_insert_block_size_bytes
ملاحظة: عند استخدام clickhouse-client أو clickhouse-local للقراءة من ملف، يتولى العميل نفسه تحليل البيانات، ويُطبَّق هذا الإعداد على جهة العميل.
عمليات INSERT: أثناء استعلامات INSERT وعندما تتدفق البيانات عبر العروض المادية، يعتمد سلوك هذا الإعداد على use_strict_insert_block_limits:
- عند التمكين: تُخرَج الكتل عندما:
  - الحدود الدنيا (AND): يتم بلوغ كلٍّ من min_insert_block_size_rows و min_insert_block_size_bytes
  - الحدود القصوى (OR): يتم بلوغ أحد max_insert_block_size_rows أو max_insert_block_size_bytes
- عند التعطيل (default): تُخرَج الكتل عند بلوغ min_insert_block_size_rows أو min_insert_block_size_bytes. ولا يتم فرض إعدادات max_insert_block_size.

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

عدد صحيح موجب.
0 — لا يشارك الإعداد في تكوين الكتل.

min_insert_block_size_rows_for_materialized_views

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

أي عدد صحيح موجب.
0 — الدمج معطّل.

انظر أيضًا

min_insert_block_size_rows

min_joined_block_size_bytes

الحد الأدنى لحجم الكتلة بالبايت لكتل الإدخال والإخراج الخاصة بـ JOIN (إذا كانت خوارزمية JOIN تدعم ذلك). ستُدمَج الكتل الصغيرة. 0 تعني غير محدود.

min_joined_block_size_rows

الحد الأدنى لحجم الكتلة، محسوبًا بعدد الصفوف، لكتل الإدخال والإخراج الخاصة بـ JOIN (إذا كانت خوارزمية JOIN تدعم ذلك). ستُدمَج الكتل الصغيرة. وتعني القيمة 0 عدم وجود حد.

min_os_cpu_wait_time_ratio_to_throw

الحد الأدنى للنسبة بين وقت انتظار CPU في نظام التشغيل (المقياس OSCPUWaitMicroseconds) ووقت الانشغال (المقياس OSCPUVirtualTimeMicroseconds) الذي عنده يبدأ النظر في رفض الاستعلامات. ويُستخدم الاستيفاء الخطي بين الحدين الأدنى والأقصى لهذه النسبة لحساب الاحتمال، ويكون الاحتمال 0 عند هذه النقطة.

min_outstreams_per_resize_after_split

يحدّد الحد الأدنى لعدد تدفقات الإخراج لمعالج Resize أو StrictResize بعد تنفيذ عملية التقسيم أثناء توليد خط المعالجة. وإذا كان عدد التدفقات الناتج أقل من هذه القيمة، فلن تُنفَّذ عملية التقسيم.

ما هي عقدة Resize

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

لماذا يلزم تقسيم عقدة Resize

أثناء تنفيذ خط المعالجة، يشهد status_mutex الخاص بـ ExecutingGraph::Node في عقدة Resize المركزية تَزاحمًا شديدًا، ولا سيما في البيئات ذات الأعداد الكبيرة من الأنوية، ويؤدي هذا التزاحم إلى:

زيادة زمن الاستجابة في ExecutingGraph::updateNode، مما يؤثر مباشرةً في أداء الاستعلام.
إهدار مفرط لدورات CPU في التزاحم على القفل الدوراني (native_queued_spin_lock_slowpath)، مما يضعف الكفاءة.
انخفاض استغلال CPU، مما يحدّ من التوازي ومعدل النقل.

كيفية تقسيم عقدة Resize

يُتحقَّق من عدد تدفقات الإخراج لضمان إمكانية إجراء التقسيم: بحيث تفي تدفقات الإخراج لكل معالج مُقسَّم بعتبة min_outstreams_per_resize_after_split أو تتجاوزها.
تُقسَّم عقدة Resize إلى عقد Resize أصغر بعدد متساوٍ من المنافذ، بحيث تتولى كل منها مجموعة فرعية من تدفقات الإدخال والإخراج.
تُعالَج كل مجموعة بشكل مستقل، مما يقلل التزاحم على القفل.

تقسيم عقدة Resize بمدخلات/مخرجات غير قابلة للتقسيم بالتساوي

في بعض الحالات، عندما لا تكون المدخلات/المخرجات قابلة للقسمة بالتساوي على عدد عقد Resize المقسّمة، تُوصَل بعض المدخلات بـ NullSource وتُوصَل بعض المخرجات بـ NullSink. يتيح ذلك إجراء التقسيم من دون التأثير في التدفق العام للبيانات.

الغرض من الإعداد

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

تعطيل هذا الإعداد

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

min_table_rows_to_use_projection_index

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

mongodb_throw_on_unsupported_query

إذا كان مفعّلًا، فستُرجِع جداول MongoDB خطأً عندما يتعذر تكوين استعلام MongoDB. وإلا، يقرأ ClickHouse الجدول بالكامل ويعالجه محليًا. لا يسري هذا الخيار عندما تكون ‘allow_experimental_analyzer=0’.

move_all_conditions_to_prewhere

انقل جميع الشروط التي يمكن نقلها من WHERE إلى PREWHERE

move_primary_key_columns_to_end_of_prewhere

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

multiple_joins_try_to_keep_original_names

لا تُضِف أسماءً مستعارة إلى قائمة التعبيرات على المستوى الأعلى عند إعادة كتابة عمليات الربط المتعددة

mutations_execute_nondeterministic_on_initiator

إذا كانت القيمة true، فستُنفَّذ الدوال الثابتة غير الحتمية (مثل الدالة now()) على المُبادِر، وتُستبدل بقيم حرفية في استعلامات UPDATE وDELETE. يساعد ذلك على إبقاء البيانات متزامنة عبر النسخ المتماثلة عند تنفيذ الطفرات باستخدام دوال ثابتة غير حتمية. القيمة الافتراضية: false.

mutations_execute_subqueries_on_initiator

إذا كانت القيمة true، تُنفَّذ الاستعلامات الفرعية القيَمية على المُبادِر وتُستبدل بقيم حرفية في استعلامات UPDATE وDELETE. القيمة الافتراضية: false.

mutations_max_literal_size_to_replace

الحد الأقصى لحجم القيمة الحرفية المُسلسلة، بالبايت، التي يمكن استبدالها في استعلامات UPDATE وDELETE. لا يسري هذا إلا إذا كان أحد الإعدادين المذكورين أعلاه مُمكّنًا على الأقل. القيمة الافتراضية: 16384 ‏(16 KiB).

mutations_sync

القيمة	الوصف
`0`	تُنفَّذ الطفرات بشكل غير متزامن.
`1`	ينتظر الاستعلام حتى تكتمل جميع الطفرات على الخادم الحالي.
`2`	ينتظر الاستعلام حتى تكتمل جميع الطفرات على جميع النُسخ المتماثلة (إن وُجدت).
`3`	ينتظر الاستعلام فقط النُسخ المتماثلة النشطة. وهذا مدعوم فقط لـ `SharedMergeTree`. أما في `ReplicatedMergeTree`، فيكون السلوك مماثلًا لـ `mutations_sync = 2`.

mysql_datatypes_support_level

يحدّد كيفية تحويل أنواع MySQL إلى أنواع ClickHouse المقابلة. وهي قائمة مفصولة بفواصل يمكن أن تتضمن أي تركيبة من decimal أو datetime64 أو date2Date32 أو date2String. جميع التعيينات الحديثة (decimal وdatetime64 وdate2Date32) مفعّلة افتراضيًا.

decimal: تحويل النوعين NUMERIC وDECIMAL إلى Decimal عندما تسمح precision بذلك.
datetime64: تحويل النوعين DATETIME وTIMESTAMP إلى DateTime64 بدلًا من DateTime عندما لا تكون precision 0.
date2Date32: تحويل DATE إلى Date32 بدلًا من Date. وله أولوية على date2String.
date2String: تحويل DATE إلى String بدلًا من Date. وتتجاوزه datetime64.

mysql_map_fixed_string_to_text_in_show_columns

عند التمكين، سيُعرض نوع البيانات FixedString في ClickHouse كـ TEXT في SHOW COLUMNS. يسري ذلك فقط عند إنشاء الاتصال عبر MySQL wire protocol.

0 - استخدم BLOB.
1 - استخدم TEXT.

mysql_map_string_to_text_in_show_columns

عند التمكين، سيُعرض نوع البيانات String في ClickHouse على أنه TEXT في SHOW COLUMNS. لا يؤثر هذا إلا عند إنشاء الاتصال عبر بروتوكول MySQL wire.

0 - استخدم BLOB.
1 - استخدم TEXT.

mysql_max_rows_to_insert

الحد الأقصى لعدد الصفوف في عملية الإدراج الدفعي في MySQL ضمن محرك تخزين MySQL

network_compression_method

ترميز الضغط المستخدم لاتصالات العميل/الخادم والخادم/الخادم. القيم الممكنة:

NONE — بدون ضغط.
LZ4 — استخدم ترميز LZ4.
LZ4HC — استخدم ترميز LZ4HC.
ZSTD — استخدم ترميز ZSTD.

انظر أيضًا

network_zstd_compression_level

network_zstd_compression_level

يحدّد مستوى ضغط ZSTD. يُستخدم فقط عندما يكون network_compression_method مضبوطًا على ZSTD. القيم الممكنة:

عدد صحيح موجب من 1 إلى 15.

normalize_function_names

طبّع أسماء الدوال إلى صيغها القياسية

number_of_mutations_to_delay

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

number_of_mutations_to_throw

إذا كان الجدول الذي طُبِّقت عليه طفرات يحتوي على هذا العدد أو أكثر من الطفرات غير المكتملة، فسيتم طرح الاستثناء ‘Too many mutations …’. 0 - معطّل

odbc_bridge_connection_pool_size

حجم تجمّع الاتصالات لكل سلسلة إعدادات اتصال في ODBC bridge.

odbc_bridge_use_connection_pooling

استخدم تجمّع الاتصالات في جسر ODBC. إذا ضُبط هذا الإعداد على false، فسيُنشأ اتصال جديد في كل مرة.

offset

يحدّد عدد الصفوف التي يجب تخطيها قبل البدء في إرجاع الصفوف من الاستعلام. ويعدّل قيمة الإزاحة المحددة بواسطة عبارة OFFSET، بحيث تُجمع هاتان القيمتان. القيم الممكنة:

0 — لا يتم تخطي أي صفوف.
عدد صحيح موجب.

مثال جدول الإدخال:

CREATE TABLE test (i UInt64) ENGINE = MergeTree() ORDER BY i;
INSERT INTO test SELECT number FROM numbers(500);

الاستعلام:

SET limit = 5;
SET offset = 7;
SELECT * FROM test LIMIT 10 OFFSET 100;

النتيجة:

┌───i─┐
│ 107 │
│ 108 │
│ 109 │
└─────┘

opentelemetry_start_keeper_trace_probability

احتمال بدء تتبّع لطلب ZooKeeper، سواء كان هناك تتبّع أصل أم لا. القيم الممكنة:

‘auto’ - يساوي الإعداد opentelemetry_start_trace_probability
0 — يكون التتبّع معطّلًا
من 0 إلى 1 — الاحتمال (على سبيل المثال، 1.0 = مفعّل دائمًا)

opentelemetry_start_trace_probability

يحدّد احتمال أن يتمكّن ClickHouse من بدء تتبّع للاستعلامات المنفّذة (إذا لم يتم تمرير trace context أصل). Possible values:

0 — يكون التتبّع معطّلًا لجميع الاستعلامات المنفّذة (إذا لم يتم تمرير trace context أصل).
عدد موجب بفاصلة عائمة ضمن النطاق [0..1]. على سبيل المثال، إذا كانت قيمة الإعداد 0,5، يمكن لـ ClickHouse في المتوسط بدء تتبّع لنصف الاستعلامات.
1 — يكون التتبّع مفعّلًا لجميع الاستعلامات المنفّذة.

opentelemetry_trace_cpu_scheduling

اجمع سبانات OpenTelemetry لجدولة CPU الاستباقية لأعباء العمل.

opentelemetry_trace_processors

يجمع سبان OpenTelemetry الخاصة بالمعالجات.

optimize_aggregation_in_order

يُمكّن تحسين GROUP BY في استعلامات SELECT لتجميع البيانات بالترتيب المقابل في جداول MergeTree. القيم الممكنة:

0 — تحسين GROUP BY معطّل.
1 — تحسين GROUP BY مفعّل.

راجع أيضًا

تحسين GROUP BY

optimize_aggregators_of_group_by_keys

يزيل دوال التجميع min/max/any/anyLast من مفاتيح GROUP BY في قسم SELECT

optimize_and_compare_chain

يُولِّد مقارنات ثابتة في سلاسل AND لتحسين قدرة التصفية. ويدعم المعاملات < و <= و > و >= و = وأي مزيج منها. على سبيل المثال، (a < b) AND (b < c) AND (c < 5) ستصبح (a < b) AND (b < c) AND (c < 5) AND (b < 5) AND (a < 5).

optimize_append_index

استخدم القيود لإضافة شرط الفهرس. القيمة الافتراضية هي false. القيم الممكنة:

true, false

optimize_arithmetic_operations_in_aggregate_functions

أخرج العمليات الحسابية من دوال التجميع

optimize_const_name_size

يستبدل الثوابت الكبيرة بقيمة scalar ويستخدم hash اسمًا لها (يُقدَّر الحجم بطول الاسم). القيم الممكنة:

عدد صحيح موجب - الحد الأقصى لطول الاسم،
0 — دائمًا،
عدد صحيح سالب - أبدًا.

optimize_count_from_files

يؤدي إلى تفعيل أو تعطيل تحسين حساب عدد الصفوف من الملفات عبر تنسيقات الإدخال المختلفة. وينطبق ذلك على دوال/محركات الجداول file/s3/url/hdfs/azureBlobStorage. القيم الممكنة:

0 — التحسين معطّل.
1 — التحسين مفعّل.

optimize_dictget_tuple_element

حوِّل tupleElement(dictGet('dict', ('a', 'b', 'c'), key), 2) إلى dictGet('dict', 'b', key) لتجنّب جلب سمات القاموس غير الضرورية. يدعم الوصول الموضعي (.1, .2, …) والمسمّى (.b)، ويُطبَّق أيضًا على dictGetOrDefault عندما تكون وسيطة القيمة الافتراضية tuple ثابتة أو tuple(...) من الثوابت.

optimize_distinct_in_order

فعِّل تحسين DISTINCT إذا كانت بعض الأعمدة فيه تُشكّل بادئة لمفتاح الترتيب. على سبيل المثال، بادئة مفتاح الترتيب في MergeTree أو في عبارة ORDER BY

optimize_distributed_group_by_sharding_key

يُحسِّن استعلامات GROUP BY sharding_key عبر تجنّب التجميع المكلف على الخادم المُبادِر (مما يقلّل استخدام الذاكرة لهذا الاستعلام على الخادم المُبادِر). أنواع الاستعلامات التالية مدعومة (بما في ذلك جميع التركيبات بينها):

SELECT DISTINCT [..., ]sharding_key[, ...] FROM dist
SELECT ... FROM dist GROUP BY sharding_key[, ...]
SELECT ... FROM dist GROUP BY sharding_key[, ...] ORDER BY x
SELECT ... FROM dist GROUP BY sharding_key[, ...] LIMIT 1
SELECT ... FROM dist GROUP BY sharding_key[, ...] LIMIT 1 BY x

أنواع الاستعلامات التالية غير مدعومة (وقد يُضاف دعم بعضها لاحقًا):

SELECT ... GROUP BY sharding_key[, ...] WITH TOTALS
SELECT ... GROUP BY sharding_key[, ...] WITH ROLLUP
SELECT ... GROUP BY sharding_key[, ...] WITH CUBE
SELECT ... GROUP BY sharding_key[, ...] SETTINGS extremes=1

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

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

انظر أيضًا:

distributed_group_by_no_merge
distributed_push_down_limit
optimize_skip_unused_shards

حاليًا، يتطلب هذا optimize_skip_unused_shards (والسبب هو أنه قد يُفعَّل افتراضيًا يومًا ما، ولن يعمل بشكل صحيح إلا إذا أُدرجت البيانات عبر جدول Distributed، أي إذا وُزِّعت البيانات وفقًا لـ sharding_key).

optimize_dry_run_check_part

عند التفعيل، يتحقق OPTIMIZE ... DRY RUN من صحة الجزء المدمج الناتج باستخدام checkDataPart. وإذا فشل التحقق، يتم طرح استثناء.

optimize_empty_string_comparisons

حوِّل التعبيرات مثل col = '' أو '' = col إلى empty(col)، وcol != '' أو '' != col إلى notEmpty(col)، وذلك فقط عندما يكون col من النوع String أو FixedString.

optimize_extract_common_expressions

يسمح باستخراج التعبيرات المشتركة من حالات OR في تعبيرات WHERE وPREWHERE وON وHAVING وQUALIFY. يمكن إعادة كتابة تعبير منطقي مثل (A AND B) OR (A AND C) إلى A AND (B OR C)، مما قد يساعد في الاستفادة من:

الفهارس في تعبيرات التصفية البسيطة
تحسين تحويل cross إلى inner join

optimize_functions_to_subcolumns

يُمكّن هذا الخيار التحسين أو يعطّله من خلال تحويل بعض الدوال إلى قراءة الأعمدة الفرعية. وهذا يقلّل مقدار البيانات المطلوب قراءتها. يمكن تحويل هذه الدوال:

length لقراءة العمود الفرعي size0.
empty لقراءة العمود الفرعي size0.
notEmpty لقراءة العمود الفرعي size0.
isNull لقراءة العمود الفرعي null.
isNotNull لقراءة العمود الفرعي null.
count لقراءة العمود الفرعي null.
mapKeys لقراءة العمود الفرعي keys.
mapValues لقراءة العمود الفرعي values.

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

0 — التحسين معطّل.
1 — التحسين مُمكَّن.

optimize_group_by_constant_keys

تحسين GROUP BY عندما تكون جميع المفاتيح في الكتلة ثابتة

optimize_group_by_function_keys

يُزيل دوالّ المفاتيح الأخرى في قسم GROUP BY

optimize_if_chain_to_multiif

يستبدل سلاسل if(cond1, then1, if(cond2, ...)) بـ multiIf. لا يفيد ذلك حاليًا مع الأنواع الرقمية.

optimize_if_transform_strings_to_enum

يستبدل الوسيطات من النوع String في If وTransform إلى enum. يكون معطّلًا افتراضيًا لأنه قد يتسبب في تغيير غير متسق في الاستعلام الموزع، مما يؤدي إلى فشله.

optimize_injective_functions_in_group_by

يستبدل الدوال الحقنية بمعاملاتها في عبارة GROUP BY

optimize_injective_functions_in_limit_by

يستبدل الدوال الحقنية بوسائطها في عبارة LIMIT BY. مثال: LIMIT 5 BY toString(x) تصبح LIMIT 5 BY x.

optimize_injective_functions_inside_uniq

يحذف الدوال الحقنية أحادية الوسيط داخل دوال uniq*().

optimize_inverse_dictionary_lookup

تجنّب تكرار عمليات البحث العكسي في القاموس من خلال إجراء عمليات بحث أسرع ضمن مجموعة مُحتسبة مسبقًا من قيم المفاتيح المحتملة.

optimize_limit_by_function_keys

يزيل المفاتيح التي تكون دوالًا لمفاتيح أخرى في قسم LIMIT BY. مثال: LIMIT 5 BY x, f(x) تصبح LIMIT 5 BY x.

optimize_limit_by_in_order

يُحسِّن استعلامات SELECT ... LIMIT N BY <cols> عندما كانت <cols> (بأي ترتيب) تُشكّل بادئة لمفتاح فرز الجدول، أو تصبح كذلك بعد أن يثبّت الشرط WHERE col = const الأعمدةَ الأولى. عند تفعيل هذا الإعداد، يقرأ المصدر البيانات بترتيب المفتاح الأساسي، بحيث تصل الصفوف ذات القيم المتساوية في أعمدة BY متجاورة داخل كل تدفّق. وعندما تصل البيانات ضمن تدفّق واحد مرتّب، يرشّح LIMIT BY هذه البيانات في وضع streaming باستخدام ذاكرة بحجم O(1)، بدلًا من إنشاء hash table لكل تركيبة مميّزة من أعمدة BY تمّت رؤيتها. وعندما تصل البيانات المرتّبة عبر عدة تدفّقات، ويمكن أن تظهر قيم BY نفسها في أكثر من تدفّق واحد، يُرشَّح كل تدفّق أولًا مسبقًا في وضع streaming إلى حد أقصى قدره LIMIT + OFFSET من الصفوف لكل مجموعة، ثم تُدمَج التدفّقات ويُجري LIMIT BY نهائي قائم على hash إزالة التكرار للمجموعات الممتدة عبر عدة تدفّقات. وتحتفظ هذه المرحلة النهائية مع ذلك بـ entry لكل تركيبة مميّزة من أعمدة BY، لكنها لا تعالج إلا الصفوف التي خضعت للتصفية المسبقة.

optimize_min_equality_disjunction_chain_length

الحد الأدنى لطول التعبير expr = x1 OR ... expr = xN من أجل التحسي

optimize_min_inequality_conjunction_chain_length

الحد الأدنى لطول التعبير expr <> x1 AND ... expr <> xN اللازم لإجراء التحسين

optimize_move_to_prewhere

يتيح تفعيل أو تعطيل التحسين التلقائي لـ PREWHERE في استعلامات SELECT. يعمل فقط مع جداول *MergeTree. القيم الممكنة:

0 — يكون التحسين التلقائي لـ PREWHERE معطّلًا.
1 — يكون التحسين التلقائي لـ PREWHERE مفعّلًا.

optimize_move_to_prewhere_if_final

يُفعِّل أو يعطِّل تحسين PREWHERE التلقائي في استعلامات SELECT التي تستخدم المُعدِّل FINAL. يعمل فقط مع جداول *MergeTree. القيم الممكنة:

0 — يكون تحسين PREWHERE التلقائي في استعلامات SELECT التي تستخدم المُعدِّل FINAL معطّلًا.
1 — يكون تحسين PREWHERE التلقائي في استعلامات SELECT التي تستخدم المُعدِّل FINAL مفعّلًا.

انظر أيضًا

الإعداد optimize_move_to_prewhere

optimize_multiif_to_if

استبدال ‘multiIf’ الذي يتضمن شرطًا واحدًا فقط بـ ‘if’.

optimize_normalize_count_variants

إعادة صياغة الدوال التجميعية المكافئة دلاليًا لـ count() إلى count().

optimize_on_insert

يُمكّن أو يعطّل تحويل البيانات قبل الإدراج، كما لو أُجريت عملية دمج على هذه الكتلة (بحسب محرك الجدول). القيم الممكنة:

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

مثال الفرق بين حالتي التمكين والتعطيل: الاستعلام:

SET optimize_on_insert = 1;

CREATE TABLE test1 (`FirstTable` UInt32) ENGINE = ReplacingMergeTree ORDER BY FirstTable;

INSERT INTO test1 SELECT number % 2 FROM numbers(5);

SELECT * FROM test1;

SET optimize_on_insert = 0;

CREATE TABLE test2 (`SecondTable` UInt32) ENGINE = ReplacingMergeTree ORDER BY SecondTable;

INSERT INTO test2 SELECT number % 2 FROM numbers(5);

SELECT * FROM test2;

النتيجة:

┌─FirstTable─┐
│          0 │
│          1 │
└────────────┘

┌─SecondTable─┐
│           0 │
│           0 │
│           0 │
│           1 │
│           1 │
└─────────────┘

لاحظ أن هذا الإعداد يؤثر في طريقة عمل العرض المادي.

optimize_or_like_chain

يعمل على تحسين عبارات OR LIKE المتعددة بتحويلها إلى multiMatchAny. لا ينبغي تمكين هذا التحسين افتراضيًا، لأنه يتعارض مع تحليل الفهارس في بعض الحالات.

optimize_prewhere_after_pushdown

شغّل تمريرة ثانية لترقية PREWHERE بعد أن تكون تحسينات خطة الاستعلام اللاحقة قد أضافت عوامل تصفية إضافية فوق خطوة قراءة MergeTree (على سبيل المثال، دفع الشروط عبر JOIN وإعادة كتابة الإسقاطات). وعند وجود PREWHERE بالفعل، يُدمَج عامل التصفية الجديد فيه باستخدام AND بدلًا من أن يبقى كخطوة تصفية منفصلة.

optimize_qbit_distance_function_reads

استبدِل دوال المسافة المستخدمة مع نوع البيانات QBit بنظيرات مكافئة لا تقرأ من التخزين إلا الأعمدة اللازمة للحساب.

optimize_read_in_order

يؤدي إلى تفعيل تحسين ORDER BY في استعلامات SELECT عند قراءة البيانات من جداول MergeTree. القيم الممكنة:

0 — يكون تحسين ORDER BY معطّلًا.
1 — يكون تحسين ORDER BY مفعّلًا.

انظر أيضًا

عبارة ORDER BY

optimize_redundant_functions_in_order_by

أزل الدوال من ORDER BY إذا كانت وسيطاتها مُدرجة أيضًا في ORDER BY

optimize_respect_aliases

إذا تم ضبطه على true، فسيأخذ الأسماء المستعارة في WHERE/GROUP BY/ORDER BY في الاعتبار، مما يساعد في تقليم الأقسام/الفهارس الثانوية/optimize_aggregation_in_order/optimize_read_in_order/optimize_trivial_count

optimize_rewrite_aggregate_function_with_if

يعيد كتابة الدوال التجميعية التي تستخدم تعبير if كوسيطة عندما تكون مكافئة منطقيًا. على سبيل المثال، يمكن إعادة كتابة avg(if(cond, col, null)) إلى avgOrNullIf(cond, col). وقد يؤدي ذلك إلى تحسين الأداء.

مدعوم فقط مع المحلّل (enable_analyzer = 1).

optimize_rewrite_array_exists_to_has

أعِد كتابة دوال arrayExists() إلى has() عندما تكون متكافئة منطقيًا. على سبيل المثال، يمكن إعادة كتابة arrayExists(x -> x = 1, arr) إلى has(arr, 1)

optimize_rewrite_has_to_in

أعِد كتابة دوال has إلى IN عندما تكون الوسيطة الأولى مصفوفة ثابتة. على سبيل المثال، يمكن إعادة صياغة has([1, 2, 3], x) إلى x IN [1, 2, 3] لتحسين الأداء مع المصفوفات الثابتة

optimize_rewrite_like_perfect_affix

أعِد كتابة تعبيرات LIKE ذات البادئة أو اللاحقة المطابقة تمامًا (مثل col LIKE 'ClickHouse%') إلى الدالتين startsWith أو endsWith (مثل startsWith(col, 'ClickHouse')).

optimize_rewrite_regexp_functions

أعِد كتابة الدوال المرتبطة بالتعبيرات النمطية إلى صيغ أبسط وأكثر كفاءة

optimize_rewrite_sum_if_to_count_if

إعادة كتابة sumIf() و sum(if()) إلى countIf() عندما تكون الدالتان متكافئتين منطقيًا

optimize_skip_merged_partitions

يُمكّن هذا الإعداد أو يعطّل التحسين لاستعلام OPTIMIZE TABLE … FINAL إذا كان هناك part واحد فقط بمستوى > 0 ولم تنتهِ صلاحية TTL الخاصة به.

OPTIMIZE TABLE ... FINAL SETTINGS optimize_skip_merged_partitions=1

بشكل افتراضي، يعيد استعلام OPTIMIZE TABLE ... FINAL كتابة هذا الـpart حتى إذا كان هناك part واحد فقط. القيم الممكنة:

1 - تمكين التحسين.
0 - تعطيل التحسين.

optimize_skip_unused_shards

يُمكّن أو يعطّل تخطي الشظايا غير المستخدمة في استعلامات SELECT التي تحتوي على شرط لمفتاح التقسيم في WHERE/PREWHERE، كما يفعّل التحسينات المرتبطة بالاستعلامات الموزعة (مثل التجميع حسب مفتاح التقسيم).

يفترض أن البيانات موزعة بحسب مفتاح التقسيم، وإلا فسيُرجع الاستعلام نتيجة غير صحيحة.

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

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

optimize_skip_unused_shards_limit

الحد الأقصى لعدد قيم مفتاح التقسيم؛ ويُعطِّل optimize_skip_unused_shards عند بلوغ هذا الحد. قد يتطلب العدد الكبير جدًا من القيم قدرًا ملحوظًا من المعالجة، بينما تكون الفائدة منه محل شك، لأنه إذا كان لديك عدد هائل من القيم في IN (...)، فمن المرجح في هذه الحالة أن يُرسَل الاستعلام إلى جميع الشظايا على أي حال.

optimize_skip_unused_shards_nesting

يتحكم هذا الإعداد في optimize_skip_unused_shards — مع العلم أنه لا يزال يتطلب تفعيل optimize_skip_unused_shards — وذلك بحسب مستوى تداخل الاستعلام الموزع (أي في الحالة التي يكون لديك فيها جدول Distributed يشير إلى جدول Distributed آخر). القيم الممكنة:

0 — معطّل، ويعمل optimize_skip_unused_shards دائمًا.
1 — يفعّل optimize_skip_unused_shards للمستوى الأول فقط.
2 — يفعّل optimize_skip_unused_shards حتى المستوى الثاني.

optimize_skip_unused_shards_rewrite_in

إعادة كتابة IN في الاستعلام الخاص بالشظايا البعيدة لاستبعاد القيم التي لا تنتمي إلى الشظية (يتطلب optimize_skip_unused_shards). القيم الممكنة:

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

optimize_sorting_by_input_stream_properties

تحسين الفرز استنادًا إلى خصائص فرز تدفق الإدخال

optimize_substitute_columns

استخدم القيود لاستبدال الأعمدة. القيمة الافتراضية هي false. القيم الممكنة:

true, false

optimize_syntax_fuse_functions

يتيح دمج الدوال التجميعية ذات الوسيط المتماثل. ويُعيد كتابة أي query يحتوي على دالتين تجميعيتين على الأقل من sum أو count أو avg لها الوسيط نفسه إلى sumCount. القيم الممكنة:

0 — لا يتم دمج الدوال ذات الوسيط المتماثل.
1 — يتم دمج الدوال ذات الوسيط المتماثل.

مثال الاستعلام:

CREATE TABLE fuse_tbl(a Int8, b Int8) Engine = Log;
SET optimize_syntax_fuse_functions = 1;
EXPLAIN SYNTAX run_query_tree_passes = 1 SELECT sum(a), sum(b), count(b), avg(b) from fuse_tbl FORMAT TSV;

النتيجة:

SELECT
    sum(__table1.a) AS `sum(a)`,
    tupleElement(sumCount(__table1.b), 1) AS `sum(b)`,
    tupleElement(sumCount(__table1.b), 2) AS `count(b)`,
    divide(tupleElement(sumCount(__table1.b), 1), toFloat64(tupleElement(sumCount(__table1.b), 2))) AS `avg(b)`
FROM default.fuse_tbl AS __table1

optimize_throw_if_noop

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

1 — إصدار استثناء مُمكّن.
0 — إصدار استثناء معطّل.

optimize_time_filter_with_preimage

تحسين شروط Date وDateTime عبر تحويل الدوال إلى مقارنات مكافئة من دون تحويلات (مثل: toYear(col) = 2023 -> col >= '2023-01-01' AND col <= '2023-12-31')

optimize_trivial_approximate_count_query

استخدم قيمة تقديرية لتحسين عمليات العدّ البسيطة في وحدات التخزين التي تدعم هذا النوع من التقدير، مثل EmbeddedRocksDB. القيم الممكنة:

0 — التحسين معطّل.
- 1 — التحسين مفعّل.

optimize_trivial_count_query

يُمكّن هذا الإعداد أو يعطّل تحسين الاستعلام البسيط SELECT count() FROM table باستخدام البيانات الوصفية من MergeTree. إذا كنت بحاجة إلى استخدام أمان على مستوى الصفوف، فعطّل هذا الإعداد. القيم الممكنة:

0 — التحسين معطّل.
- 1 — التحسين مفعّل.

انظر أيضًا:

optimize_functions_to_subcolumns

optimize_trivial_group_by_limit_query

يعمل هذا الإعداد على تمكين أو تعطيل تحسين الاستعلام البسيط SELECT key_expr FROM table GROUP BY key_expr LIMIT n (من دون دوال تجميعية في الإسقاط، ومن دون عبارات HAVING/ORDER BY/LIMIT BY/window، ومن دون modifiers لـ GROUP BY) وذلك عبر تعيين max_rows_to_group_by = n + offset مع group_by_overflow_mode = 'any'. ويتوقف التجميع بمجرد إنتاج n + offset من المفاتيح المميّزة. يُوقَف هذا التحسين عندما يكون المستخدم قد عيّن group_by_overflow_mode صراحةً إلى قيمة غير any (للحفاظ على سلوك throw/break الذي حدّده صراحةً)، وكذلك عندما يكون المستخدم قد عيّن بالفعل قيمة أكثر تقييدًا لـ max_rows_to_group_by (إذ سيكون التحسين عندها no-op). القيم الممكنة:

0 — التحسين معطّل.
- 1 — التحسين مفعّل.

optimize_trivial_insert_select

تحسين استعلام ‘INSERT INTO table SELECT … FROM TABLES’ البسيط

optimize_truncate_order_by_after_group_by_keys

أزل عناصر ORDER BY اللاحقة بمجرد أن تغطي بادئة ORDER BY جميع مفاتيح GROUP BY.

optimize_uniq_to_count

أعِد كتابة uniq وصِيَغه المختلفة (باستثناء uniqUpTo) إلى count إذا تضمّن الاستعلام الفرعي distinct أو عبارة group by.

optimize_use_implicit_projections

يختار الإسقاطات الضمنية تلقائيًا لتنفيذ استعلام SELECT

optimize_use_projection_filtering

يتيح استخدام الإسقاطات لتصفية نطاقات الأجزاء حتى عند عدم تحديد الإسقاطات لتنفيذ استعلام SELECT.

optimize_use_projections

الأسماء البديلة: allow_experimental_projection_optimization يُمكّن أو يعطّل تحسين الإسقاطات عند معالجة استعلامات SELECT. القيم الممكنة:

0 — تحسين الإسقاطات معطّل.
1 — تحسين الإسقاطات مفعّل.

optimize_using_constraints

استخدم القيود لتحسين الاستعلامات. القيمة الافتراضية هي false. القيم الممكنة:

true, false

os_threads_nice_value_materialized_view

قيمة nice في Linux لخيوط العرض المادي. القيم الأقل تعني أولوية أعلى للـCPU. يتطلب صلاحية CAP_SYS_NICE، وإلا فلن يكون له أي تأثير. القيم الممكنة: من -20 إلى 19.

os_threads_nice_value_query

الأسماء البديلة: os_thread_priority قيمة nice في Linux لخيوط معالجة الاستعلامات. كلما انخفضت القيمة، ارتفعت أولوية CPU. يتطلب امتياز CAP_SYS_NICE، وإلا فلن يكون له أي تأثير. القيم الممكنة: من -20 إلى 19.

page_cache_block_size

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

page_cache_inject_eviction

قد تُلغي ذاكرة التخزين المؤقت للصفحات في فضاء المستخدم صلاحية بعض الصفحات عشوائيًا من حين لآخر. هذا مخصص للاختبار.

page_cache_lookahead_blocks

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

page_cache_max_coalesced_bytes

عندما يملأ readBigAt ذاكرة تخزين الصفحات المؤقتة في فضاء المستخدم، تُدمَج حالات الإخفاق المتتالية في cache في قراءة واحدة من طبقة التخزين الأساسية. يحدّد هذا الإعداد حجم القراءة المدمجة الواحدة بالبايت؛ وتُقسَّم سلاسل الإخفاق الأطول إلى عدة قراءات. كما يحدّ من الاستخدام العابر للذاكرة في المخزن المؤقت المؤقت عند إجراء قراءات باردة متوازية. تقلّل القيمة الأعلى عدد طلبات HTTP في عمليات المسح البارد على التخزين الكائني؛ بينما تقلّل القيمة الأقل ذروة الذاكرة العابرة.

paimon_target_snapshot_id

قراءة لقطة مستهدفة على مستوى الاستعلام لوضع Paimon التزايدي. عندما تكون القيمة >0، لن يجلب القارئ سوى البيانات التفاضلية لـ snapshot_id المحدد، من دون تحريك العلامة المائية المُعتمدة إلى الأمام. القيمة الافتراضية: -1 (معطّل)

parallel_distributed_insert_select

يُمكّن تنفيذ استعلام INSERT ... SELECT الموزّع بشكل متوازٍ. إذا نفّذنا استعلامات INSERT INTO distributed_table_a SELECT ... FROM distributed_table_b وكان كلا الجدولين يستخدمان الـ cluster نفسه، وكان كلا الجدولين إما مكرّرين أو غير مكرّرين، فستُعالَج هذه الاستعلامات محليًا على كل شظية. القيم الممكنة:

0 — معطّل.
1 — سيُنفَّذ SELECT على كل شظية من الجدول الأساسي لمحرك Distributed.
2 — سيُنفَّذ SELECT وINSERT على كل شظية من/إلى الجدول الأساسي لمحرك Distributed.

اعتبارًا من v25.4، يمكن أيضًا تنفيذ INSERT ... SELECT من مصدر ReplicatedMergeTree أو SharedMergeTree بشكل متوازٍ عبر replicas. لتمكين ذلك:

parallel_distributed_insert_select = 2
enable_parallel_replicas = 1

parallel_hash_join_threshold

عند استخدام خوارزمية join المعتمدة على hash، تساعد هذه العتبة في تحديد ما إذا كان ينبغي استخدام hash أو parallel_hash (وذلك فقط إذا كان تقدير حجم الجدول الأيمن متاحًا). ويُستخدم الخيار الأول عندما نعلم أن حجم الجدول الأيمن أقل من هذه العتبة.

parallel_non_joined_rows_processing

يسمح لعدة خيوط بمعالجة الصفوف غير المنضمّة من الجدول الأيمن بالتوازي أثناء عمليتَي RIGHT JOIN وFULL JOIN. يمكن أن يؤدي ذلك إلى تسريع مرحلة الصفوف غير المنضمّة عند استخدام خوارزمية الربط parallel_hash مع الجداول الكبيرة. عند تعطيله، تُعالَج الصفوف غير المنضمّة بواسطة خيط واحد.

parallel_replica_offset

هذا إعداد داخلي لا ينبغي استخدامه مباشرةً، وهو يمثل تفصيلًا تنفيذيًا لوضع “النسخ المتماثلة المتوازية”. سيُضبط هذا الإعداد تلقائيًا بواسطة الخادم المُبادِر للاستعلامات الموزعة، بحيث يشير إلى فهرس النسخة المتماثلة المشاركة في معالجة الاستعلام ضمن النسخ المتماثلة المتوازية.

parallel_replicas_allow_in_with_subquery

إذا كانت القيمة true، فسيُنفَّذ الاستعلام الفرعي الخاص بـ IN على كل نسخة متماثلة تابعة.

parallel_replicas_allow_materialized_views

السماح باستخدام العروض المادية مع النسخ المتماثلة المتوازية

parallel_replicas_allow_view_over_mergetree

يسمح للنسخ المتماثلة المتوازية بتنفيذ الاستعلام الخارجي لعرض بسيط فوق جداول MergeTree (بدلًا من الاستعلام الداخلي للعرض)، مما يحسّن التوازي عبر العُقد. وينطبق ذلك أيضًا على عروض UNION ALL التي تقرأ جميع فروعها من جداول MergeTree مختلفة.

parallel_replicas_connect_timeout_ms

المهلة بالمللي ثانية للاتصال بنسخة متماثلة بعيدة أثناء تنفيذ الاستعلام باستخدام النسخ المتماثلة المتوازية. إذا انتهت المهلة، فلن تُستخدم النسخة المتماثلة المقابلة في تنفيذ الاستعلا

parallel_replicas_count

هذا إعداد داخلي لا ينبغي استخدامه مباشرةً، ويمثل تفصيلًا تنفيذيًا لوضع ‘النسخ المتماثلة المتوازية’. وسيُضبط هذا الإعداد تلقائيًا بواسطة الخادم المُبادِر للاستعلامات الموزعة على عدد النسخ المتماثلة المتوازية المشاركة في معالجة الاستعلامات.

parallel_replicas_custom_key

تعبير عددي صحيح اعتباطي يمكن استخدامه لتقسيم العمل بين النسخ المتماثلة لجدول معيّن. يمكن أن تكون القيمة أي تعبير عددي صحيح. يُفضَّل استخدام التعبيرات البسيطة التي تعتمد على المفتاح الأساسي. إذا استُخدم هذا الإعداد على عنقود يتكوّن من شظية واحدة مع عدة نسخ متماثلة، فستُحوَّل تلك النسخ المتماثلة إلى شظايا افتراضية. وبخلاف ذلك، فسيتصرف بالطريقة نفسها كما في مفتاح SAMPLE، إذ سيستخدم عدة نسخ متماثلة من كل شظية.

parallel_replicas_custom_key_range_lower

يتيح لمرشح range تقسيم العمل بالتساوي بين النسخ المتماثلة استنادًا إلى النطاق المخصص [parallel_replicas_custom_key_range_lower, INT_MAX]. وعند استخدامه مع parallel_replicas_custom_key_range_upper، فإنه يتيح للمرشح تقسيم العمل بالتساوي على النسخ المتماثلة ضمن النطاق [parallel_replicas_custom_key_range_lower, parallel_replicas_custom_key_range_upper]. ملاحظة: لا يؤدي هذا الإعداد إلى تصفية أي بيانات إضافية أثناء معالجة الاستعلام؛ بل يغيّر فقط النقاط التي يقسم عندها مرشح النطاق المجال [0, INT_MAX] لأغراض المعالجة المتوازية.

parallel_replicas_custom_key_range_upper

يسمح نوع المرشح range بتقسيم العمل بالتساوي بين النسخ المتماثلة استنادًا إلى النطاق المخصص [0, parallel_replicas_custom_key_range_upper]. تؤدي القيمة 0 إلى تعطيل الحد الأعلى، ما يضبطه على القيمة القصوى لتعبير المفتاح المخصص. عند استخدامه مع parallel_replicas_custom_key_range_lower، فإنه يتيح للمرشح تقسيم العمل بالتساوي على النسخ المتماثلة ضمن النطاق [parallel_replicas_custom_key_range_lower, parallel_replicas_custom_key_range_upper]. ملاحظة: لن يتسبب هذا الإعداد في ترشيح أي بيانات إضافية أثناء معالجة الاستعلامات، بل يغيّر النقاط التي يقسم عندها مرشح النطاق المجال [0, INT_MAX] لأغراض المعالجة المتوازية

parallel_replicas_filter_pushdown

السماح بدفع عوامل التصفية إلى الجزء من الاستعلام الذي تختار النسخ المتماثلة المتوازية تنفيذه

parallel_replicas_for_cluster_engines

استبدِل محركات دوال الجداول بنظائرها من نوع -Cluster

parallel_replicas_for_non_replicated_merge_tree

إذا كانت القيمة true، فسيستخدم ClickHouse أيضًا خوارزمية النسخ المتماثلة المتوازية مع جداول MergeTree غير المكررة

parallel_replicas_index_analysis_only_on_coordinator

يُجرى تحليل الفهرس فقط على replica-coordinator، ويُتخطى على النسخ المتماثلة الأخرى. ولا يكون فعالًا إلا عند تمكين parallel_replicas_local_pla

parallel_replicas_insert_select_local_pipeline

استخدام مسار المعالجة المحلي أثناء INSERT SELECT الموزّع مع النسخ المتماثلة المتوازية

parallel_replicas_local_plan

إنشاء خطة محلية للنسخة المتماثلة المحلية

parallel_replicas_mark_segment_size

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

parallel_replicas_min_number_of_rows_per_replica

يقيّد عدد النسخ المتماثلة المستخدمة في query إلى (العدد التقديري للصفوف المراد قراءتها / min_number_of_rows_per_replica). ويظل الحد الأقصى مقيّدًا بالقيمة ‘max_parallel_replicas’

parallel_replicas_mode

نوع عامل التصفية الذي يُستخدم مع المفتاح المخصص للنسخ المتماثلة المتوازية. default - استخدام عملية modulo على المفتاح المخصص، range - استخدام عامل تصفية النطاق على المفتاح المخصص بالاعتماد على جميع القيم الممكنة لنوع قيمة المفتاح المخصص.

parallel_replicas_only_with_analyzer

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

parallel_replicas_prefer_local_join

إذا كانت القيمة true، وكان من الممكن تنفيذ JOIN باستخدام خوارزمية النسخ المتماثلة المتوازية، وكانت جميع وحدات التخزين في الجزء الأيمن من JOIN من نوع *MergeTree، فسيُستخدم JOIN المحلي بدلًا من GLOBAL JOIN.

parallel_replicas_prefer_local_replica

عند تمكينه (وهو الإعداد الافتراضي)، تُدرَج النسخة المتماثلة المحلية دائمًا ضمن مجموعة النسخ المتماثلة المستخدمة للقراءة المتوازية. عند تعطيله، لا تُمنَح النسخة المتماثلة المحلية أي أفضلية، وتُحدَّد النسخ المتماثلة اعتمادًا فقط على خوارزمية موازنة التحميل. يتيح ذلك توجيه الاستعلامات التي تستخدم max_parallel_replicas = 1 إلى مضيف آخر، مما قد يحسّن محلية ذاكرة التخزين المؤقت عند توزيع عدد كبير من الاستعلامات القصيرة عبر عنقود.

parallel_replicas_support_projection

يمكن تطبيق تحسين الإسقاطات في النسخ المتماثلة المتوازية. ويكون ذلك فعالًا فقط عند تمكين parallel_replicas_local_plan وعندما يكون aggregation_in_order غير مفعّل.

parallel_view_processing

يُمكّن دفع البيانات إلى العروض المرفقة بشكل متزامن بدلًا من بشكل تسلسلي.

parallelize_output_from_storages

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

parsedatetime_e_requires_space_padding

يتوقع المُنسِّق ‘%e’ في الدالة ‘parseDateTime’ أن تُستكمَل الأيام المكوّنة من رقم واحد بمسافة، فمثلًا يُقبل ’ 2’، لكن ‘2’ يتسبب في حدوث خطأ.

parsedatetime_parse_without_leading_zeros

تُحلِّل محددات التنسيق ‘%c’ و’%l’ و’%k’ في الدالة ‘parseDateTime’ الأشهر والساعات من دون أصفار بادئة.

partial_merge_join_left_table_buffer_bytes

إذا لم تكن القيمة 0، فستُجمَّع كتل الجدول الأيسر في كتل أكبر للجدول الواقع على الجانب الأيسر في partial merge join. ويستخدم هذا ما يصل إلى ضعفي الذاكرة المحددة لكل مؤشر ترابط لعملية الربط.

partial_merge_join_rows_in_right_blocks

يحدّ من أحجام كتل بيانات الربط في الطرف الأيمن ضمن خوارزمية الربط بالدمج الجزئي لاستعلامات JOIN. خادم ClickHouse:

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

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

أي عدد صحيح موجب. النطاق الموصى به للقيم: [1000, 100000].

partial_result_on_first_cancel

يسمح بإرجاع نتيجة جزئية للاستعلام بعد إلغائه.

parts_to_delay_insert

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

parts_to_throw_insert

إذا تجاوز عدد الأجزاء النشطة في قسم واحد من الجدول الهدف هذا العدد، فسيُرفَع الاستثناء ‘Too many parts …‘.

per_part_index_stats

يسجّل إحصاءات الفهرس لكل جزء

poll_interval

يحظر في حلقة انتظار الاستعلام على الخادم لعدد الثواني المحدد.

polyglot_dialect

لهجة SQL المصدر للمحوِّل متعدد اللغات (على سبيل المثال: ‘sqlite’ و’mysql’ و’postgresql’ و’snowflake’ و’duckdb’).

postgresql_connection_attempt_timeout

مهلة محاولة واحدة للاتصال بنقطة نهاية PostgreSQL، مقاسة بالثواني. تُمرَّر القيمة باعتبارها المعلَمة connect_timeout ضمن URL الاتصال.

postgresql_connection_pool_auto_close_connection

أغلق الاتصال قبل إعادته إلى مجمع الاتصالات.

postgresql_connection_pool_retries

عدد مرات إعادة المحاولة لعمليات push/pop في مجمع الاتصالات لمحرك جدول PostgreSQL ومحرك قاعدة البيانات.

postgresql_connection_pool_size

حجم تجمّع الاتصالات في محرك جدول PostgreSQL ومحرك قاعدة البيانات.

postgresql_connection_pool_wait_timeout

مهلة انتظار push/pop لتجمّع الاتصالات عند فراغ التجمّع، وذلك لمحرك جدول PostgreSQL ومحرك قاعدة البيانات. بشكل افتراضي، سيدخل في حالة انتظار عند فراغ التجمّع.

postgresql_fault_injection_probability

الاحتمال التقريبي لفشل استعلامات PostgreSQL الداخلية (الخاصة بالنسخ المتماثل). تكون القيمة الصالحة ضمن النطاق [0.0f, 1.0f]

predicate_statistics_sample_rate

يجمع إحصاءات انتقائية الشرط في system.predicate_statistics_log. عند تعيينه إلى N > 0، تُؤخذ عيّنة من نحو 1/N من الاستعلامات (استنادًا إلى معرّف الاستعلام). وتعني القيمة 0 أنه معطّل.

prefer_column_name_to_alias

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

0 — يُستبدل اسم العمود بالاسم المستعار.
1 — لا يُستبدل اسم العمود بالاسم المستعار.

مثال الفرق بين حالتي التمكين والتعطيل: الاستعلام:

SET prefer_column_name_to_alias = 0;
SELECT avg(number) AS number, max(number) FROM numbers(10);

النتيجة:

Received exception from server (version 21.5.1):
Code: 184. DB::Exception: Received from localhost:9000. DB::Exception: Aggregate function avg(number) is found inside another aggregate function in query: While processing avg(number) AS number.

الاستعلام:

SET prefer_column_name_to_alias = 1;
SELECT avg(number) AS number, max(number) FROM numbers(10);

النتيجة:

┌─number─┬─max(number)─┐
│    4.5 │           9 │
└────────┴─────────────┘

prefer_external_sort_block_bytes

تفضيل الحد الأقصى لحجم الكتلة بالبايت للفرز الخارجي لتقليل استخدام الذاكرة أثناء الدمج.

prefer_global_in_and_join

يُمكّن استبدال معاملي IN/JOIN بـ GLOBAL IN/GLOBAL JOIN. القيم الممكنة:

0 — معطّل. لا يتم استبدال معاملي IN/JOIN بـ GLOBAL IN/GLOBAL JOIN.
1 — مفعّل. يتم استبدال معاملي IN/JOIN بـ GLOBAL IN/GLOBAL JOIN.

الاستخدام على الرغم من أن SET distributed_product_mode=global يمكنه تغيير سلوك الاستعلامات بالنسبة إلى الجداول الموزعة، فإنه غير مناسب للجداول المحلية أو الجداول القادمة من الموارد الخارجية. وهنا يأتي دور الإعداد prefer_global_in_and_join. على سبيل المثال، قد تكون لدينا عُقد لخدمة الاستعلامات تحتوي على جداول محلية لا تناسب التوزيع. في هذه الحالة، نحتاج إلى توزيع بياناتها أثناء المعالجة الموزعة في وقت التنفيذ باستخدام الكلمة المفتاحية GLOBAL — GLOBAL IN/GLOBAL JOIN. ومن حالات الاستخدام الأخرى للإعداد prefer_global_in_and_join الوصول إلى الجداول المُنشأة بواسطة المحركات الخارجية. يساعد هذا الإعداد على تقليل عدد الاستدعاءات إلى المصادر الخارجية عند ربط مثل هذه الجداول: استدعاء واحد فقط لكل استعلام. انظر أيضًا:

Distributed subqueries لمزيد من المعلومات حول كيفية استخدام GLOBAL IN/GLOBAL JOIN

prefer_localhost_replica

يُفعِّل/يُعطِّل تفضيل استخدام النسخة المتماثلة على localhost عند معالجة الاستعلامات الموزعة. القيم الممكنة:

1 — يرسل ClickHouse دائمًا الاستعلام إلى النسخة المتماثلة على localhost إذا كانت موجودة.
0 — يستخدم ClickHouse استراتيجية الموازنة المحددة في الإعداد load_balancing.

عطّل هذا الإعداد إذا كنت تستخدم max_parallel_replicas بدون parallel_replicas_custom_key. إذا كان parallel_replicas_custom_key مضبوطًا، فعطّل هذا الإعداد فقط إذا كان يُستخدم على عنقود يضم عدة shards تحتوي على عدة نسخ متماثلة. إذا كان يُستخدم على عنقود يحتوي على shard واحدة وعدة نسخ متماثلة، فسيكون لتعطيل هذا الإعداد آثار سلبية.

prefer_warmed_unmerged_parts_seconds

لا يكون لهذا الإعداد أي تأثير إلا في ClickHouse Cloud. إذا كان الجزء المدمج أحدث من هذا العدد من الثواني ولم يُسخَّن مسبقًا (راجع cache_populated_by_fetch)، وكانت جميع أجزائه المصدرية متاحة ومُسخَّنة مسبقًا، فستقرأ استعلامات SELECT من تلك الأجزاء بدلًا منه. ينطبق هذا فقط على Replicated-/SharedMergeTree. لاحظ أن هذا يتحقق فقط مما إذا كان CacheWarmer قد عالج الجزء؛ فإذا أُدخِل الجزء إلى ذاكرة التخزين المؤقت بواسطة آلية أخرى، فسيظل يُعتبر غير مُسخَّن حتى يعالجه CacheWarmer؛ وإذا كان قد سُخِّن ثم أُخرج من ذاكرة التخزين المؤقت، فسيظل يُعتبر مُسخَّنًا.

preferred_block_size_bytes

يضبط هذا الإعداد حجم كتلة البيانات لمعالجة الاستعلامات، ويُعد ضبطًا إضافيًا أدقّ مقارنةً بإعداد ‘max_block_size’ الأقل دقة. إذا كانت الأعمدة كبيرة، وكان من المحتمل أن يتجاوز حجم الكتلة، عند استخدام عدد الصفوف المحدد في ‘max_block_size’، عدد البايتات المحدد، فسيُخفَّض حجمها لتحسين محلية ذاكرة التخزين المؤقت للـ CPU.

preferred_max_column_in_block_size_bytes

الحد الأقصى لحجم العمود داخل الكتلة أثناء القراءة. يساعد على تقليل عدد مرات الإخفاق في ذاكرة التخزين المؤقت. ينبغي أن يكون قريبًا من حجم ذاكرة التخزين المؤقت L2.

preferred_optimize_projection_name

إذا ضُبطت على سلسلة غير فارغة، فسيحاول ClickHouse تطبيق الإسقاط المحدَّد في الاستعلام. القيم الممكنة:

String: اسم الإسقاط المفضّل

prefetch_buffer_size

الحد الأقصى لحجم المخزن المؤقت للجلب المسبق للقراءة من نظام الملفات.

print_pretty_type_names

يسمح بطباعة أسماء الأنواع شديدة التداخل بصورة منسقة مع المسافات البادئة في استعلام DESCRIBE وفي الدالة toTypeName(). مثال:

CREATE TABLE test (a Tuple(b String, c Tuple(d Nullable(UInt64), e Array(UInt32), f Array(Tuple(g String, h Map(String, Array(Tuple(i String, j UInt64))))), k Date), l Nullable(String))) ENGINE=Memory;
DESCRIBE TABLE test FORMAT TSVRaw SETTINGS print_pretty_type_names=1;

a   Tuple(
    b String,
    c Tuple(
        d Nullable(UInt64),
        e Array(UInt32),
        f Array(Tuple(
            g String,
            h Map(
                String,
                Array(Tuple(
                    i String,
                    j UInt64
                ))
            )
        )),
        k Date
    ),
    l Nullable(String)
)

الأولوية

أولوية الاستعلام. 1 - الأعلى، وكلما ارتفعت القيمة انخفضت الأولوية؛ 0 - لا تُستخدم الأولويات.

promql_database

يحدّد اسم قاعدة البيانات المستخدم مع لهجة ‘promql’. وتعني السلسلة الفارغة قاعدة البيانات الحالية.

promql_evaluation_time

الأسماء البديلة: evaluation_time يحدّد وقت التقييم المستخدم مع لهجة promql. وتعني 'auto' الوقت الحالي.

promql_table

يحدّد اسم جدول TimeSeries الذي تستخدمه لهجة ‘promql’.

push_external_roles_in_interserver_queries

تمكين تمرير أدوار المستخدم من العُقدة المُصدِرة إلى العُقد الأخرى أثناء تنفيذ الاستعلام.

query_cache_compress_entries

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

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

query_cache_for_subqueries

إذا كان هذا الخيار مفعّلًا، فقد تُكتب نتائج الاستعلامات الفرعية إلى ذاكرة التخزين المؤقت للاستعلامات وتُقرأ منها. ويتيح ذلك تمرير use_query_cache إلى جميع الاستعلامات الفرعية. القيم الممكنة:

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

query_cache_max_entries

الحد الأقصى لعدد نتائج الاستعلام التي يمكن للمستخدم الحالي تخزينها في ذاكرة التخزين المؤقت للاستعلامات. وتعني القيمة 0 عدم وجود حد. القيم الممكنة:

عدد صحيح غير سالب >= 0.

query_cache_max_size_in_bytes

الحد الأقصى لمقدار الذاكرة (بالبايت) الذي يمكن للمستخدم الحالي تخصيصه في ذاكرة التخزين المؤقت للاستعلامات. تعني القيمة 0 عدم وجود حد. القيم الممكنة:

عدد صحيح غير سالب >= 0.

query_cache_min_query_duration

الحد الأدنى للمدة، بالمللي ثانية، التي يجب أن يستغرقها الاستعلام حتى تُخزَّن نتيجته في ذاكرة التخزين المؤقت للاستعلامات. القيم الممكنة:

عدد صحيح موجب أو صفر >= 0.

query_cache_min_query_runs

الحد الأدنى لعدد المرات التي يجب فيها تنفيذ استعلام SELECT قبل تخزين نتيجته في ذاكرة التخزين المؤقت للاستعلامات. القيم الممكنة:

عدد صحيح غير سالب >= 0.

query_cache_nondeterministic_function_handling

يتحكم هذا الإعداد في كيفية تعامل ذاكرة التخزين المؤقت للاستعلامات مع استعلامات SELECT التي تتضمن دوال غير حتمية مثل rand() أو now(). القيم الممكنة:

'throw' - طرح استثناء وعدم تخزين نتيجة الاستعلام مؤقتًا.
'save' - تخزين نتيجة الاستعلام مؤقتًا.
'ignore' - عدم تخزين نتيجة الاستعلام مؤقتًا وعدم طرح استثناء.

query_cache_share_between_users

إذا كان هذا الإعداد مفعّلًا، يمكن للمستخدمين الآخرين قراءة نتائج استعلامات SELECT المخزّنة مؤقتًا في ذاكرة التخزين المؤقت للاستعلامات. لا يُنصح بتمكين هذا الإعداد لأسباب أمنية. القيم الممكنة:

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

query_cache_squash_partial_results

ادمج كتل النتائج الجزئية في كتل بحجم max_block_size. يقلل ذلك من أداء عمليات الإدراج في ذاكرة التخزين المؤقت للاستعلامات، لكنه يحسّن قابلية ضغط عناصر ذاكرة التخزين المؤقت (راجع query_cache_compress-entries). القيم الممكنة:

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

query_cache_system_table_handling

يتحكّم هذا الإعداد في كيفية تعامل ذاكرة التخزين المؤقت للاستعلامات مع استعلامات SELECT على جداول النظام، أي الجداول الموجودة في قاعدتَي البيانات system.* وinformation_schema.*. القيم الممكنة:

'throw' - رفع استثناء وعدم تخزين نتيجة الاستعلام مؤقتًا.
'save' - تخزين نتيجة الاستعلام مؤقتًا.
'ignore' - عدم تخزين نتيجة الاستعلام مؤقتًا وعدم رفع استثناء.

query_cache_tag

سلسلة نصية تُستخدم كوسم لإدخالات ذاكرة التخزين المؤقت للاستعلامات. تتعامل ذاكرة التخزين المؤقت للاستعلامات مع الاستعلامات نفسها ذات الوسوم المختلفة على أنها استعلامات مختلفة. القيم الممكنة:

أي سلسلة نصية

query_cache_ttl

بعد انقضاء هذه المدة بالثواني، تصبح العناصر في ذاكرة التخزين المؤقت للاستعلامات قديمة. القيم الممكنة:

عدد صحيح غير سالب >= 0.

query_metric_log_interval

الفاصل الزمني، بالمللي ثانية، الذي يتم عنده جمع query_metric_log للاستعلامات الفردية. إذا ضُبطت هذه القيمة على أي قيمة سالبة، فستأخذ قيمة collect_interval_milliseconds من إعداد query_metric_log، أو ستستخدم القيمة الافتراضية 1000 إذا لم تكن موجودة. لتعطيل الجمع لاستعلام واحد، اضبط query_metric_log_interval على 0. القيمة الافتراضية: -1

query_plan_aggregation_in_order

يُفعّل أو يعطّل تحسين التجميع بالترتيب على مستوى خطة الاستعلام. لا يسري مفعوله إلا إذا كان الإعداد query_plan_enable_optimizations يساوي 1.

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

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

0 - تعطيل
1 - تمكين

query_plan_convert_any_join_to_semi_or_anti_join

السماح بتحويل ANY JOIN إلى SEMI أو ANTI JOIN إذا كان عامل التصفية بعد JOIN يُقيَّم دائمًا إلى false للصفوف المطابقة أو غير المطابقة

query_plan_convert_join_to_in

السماح بتحويل JOIN إلى استعلام فرعي يتضمّن IN إذا كانت أعمدة الإخراج مرتبطة بالجدول الأيسر فقط. قد يؤدي ذلك إلى نتائج غير صحيحة مع أنواع JOIN غير ANY (مثل ALL JOINs، وهو الإعداد الافتراضي).

query_plan_convert_outer_join_to_inner_join

السماح بتحويل OUTER JOIN إلى INNER JOIN إذا كان عامل التصفية بعد JOIN يستبعد دائمًا القيم الافتراضية

query_plan_direct_read_from_text_index

يسمح بإجراء التصفية في البحث النصي الكامل بالاعتماد فقط على الفهرس النصي المعكوس ضمن خطة الاستعلام.

query_plan_display_internal_aliases

يعرض الأسماء المستعارة الداخلية (مثل __table1) في EXPLAIN PLAN بدلًا من الأسماء المحددة في الاستعلام الأصلي.

query_plan_enable_multithreading_after_window_functions

تمكين المعالجة متعددة الخيوط بعد تقييم دوال النافذة للسماح بمعالجة التدفقات بالتوازي

query_plan_enable_optimizations

يتيح تمكين أو تعطيل تحسين الاستعلام على مستوى خطة الاستعلام.

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

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

0 - تعطيل جميع عمليات التحسين على مستوى خطة الاستعلام
1 - تمكين عمليات التحسين على مستوى خطة الاستعلام (لكن قد تظل بعض عمليات التحسين الفردية معطّلة عبر إعداداتها الخاصة)

query_plan_execute_functions_after_sorting

يبدّل تحسينًا على مستوى خطة الاستعلام ينقل التعبيرات إلى ما بعد خطوات الفرز. ولا يسري مفعوله إلا إذا كانت قيمة الإعداد query_plan_enable_optimizations تساوي 1.

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

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

0 - تعطيل
1 - تمكين

query_plan_filter_push_down

يبدّل تحسينًا على مستوى خطة الاستعلام يدفع عوامل التصفية إلى أسفل ضمن خطة التنفيذ. ولا يسري مفعوله إلا إذا كانت قيمة الإعداد query_plan_enable_optimizations تساوي 1.

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

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

0 - تعطيل
1 - تمكين

query_plan_join_shard_by_pk_ranges

طبّق sharding على JOIN إذا كانت مفاتيح الربط تتضمن بادئة من PRIMARY KEY في كلا الجدولين. هذا الإعداد مدعوم مع الخوارزميات hash وparallel_hash وfull_sorting_merge. وعادةً لا يؤدي إلى تسريع الاستعلامات، لكنه قد يقلل استهلاك الذاكرة.

query_plan_join_swap_table

حدِّد أي طرف من طرفَي JOIN يجب أن يكون جدول البناء (ويُسمى أيضًا الداخلي، وهو الذي يُدرَج في جدول التجزئة في hash join) في خطة الاستعلام. لا يدعم هذا الإعداد إلا درجة الصرامة ALL في JOIN مع عبارة JOIN ON. القيم الممكنة هي:

‘auto’: دع المخطِّط يقرر أي جدول سيُستخدم كجدول البناء.
- ‘false’: لا تبدِّل الجداول مطلقًا (الجدول الأيمن هو جدول البناء).
- ‘true’: بدِّل الجداول دائمًا (الجدول الأيسر هو جدول البناء).

query_plan_lift_up_array_join

يُفعّل أو يعطّل تحسينًا على مستوى خطة الاستعلام يرفع عمليات ARRAY JOIN إلى أعلى في خطة التنفيذ. ولا يسري مفعوله إلا إذا كانت قيمة الإعداد query_plan_enable_optimizations تساوي 1.

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

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

0 - تعطيل
1 - تمكين

query_plan_lift_up_union

يبدّل هذا الإعداد تحسينًا على مستوى خطة الاستعلام ينقل أشجارًا فرعية أكبر ضمن خطة الاستعلام إلى union لإتاحة المزيد من التحسينات. ولا يسري مفعوله إلا إذا كان الإعداد query_plan_enable_optimizations مضبوطًا على 1.

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

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

0 - تعطيل
1 - تمكين

query_plan_max_limit_for_join_lazy_indexing

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

query_plan_max_limit_for_lazy_materialization

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

query_plan_max_limit_for_top_k_optimization

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

query_plan_max_optimizations_to_apply

يحدّ هذا الإعداد من العدد الإجمالي لعمليات التحسين المُطبَّقة على خطة الاستعلام؛ راجع الإعداد query_plan_enable_optimizations. وهو مفيد لتجنّب إطالة وقت التحسين في الاستعلامات المعقّدة. في استعلام EXPLAIN PLAN، يتوقف تطبيق التحسينات بعد بلوغ هذا الحد وتُعاد الخطة كما هي. أما عند تنفيذ الاستعلامات العادية، فإذا تجاوز العدد الفعلي لعمليات التحسين هذا الإعداد، يُطرَح استثناء.

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

query_plan_max_set_size_for_projection_match

الحد الأقصى لعدد الصفوف في مجموعة لعبارة IN يحسب لها مُطابِق الإسقاط تجزئات المحتوى ويقارنها عند تحديد ما إذا كانت مجموعتان متساويتين. وتُعامَل المجموعات الأكبر من ذلك على أنها غير متطابقة، ويُتخطّى الإسقاط. تؤدي القيمة صفر إلى تعطيل مقارنة تجزئة المحتوى بالكامل: لا تنجح مطابقة الإسقاط مطلقًا للعُقد التي تحتوي على مجموعات لعبارة IN. يُستخدم هذا الإعداد بواسطة مُطابِق الإسقاط التجميعي (وأي مُطابِق إسقاط مستقبلي يحتاج إلى مقارنة مجموعات لعبارة IN). ويبلغ تعقيد حساب تجزئة المحتوى O(N log N) بالنسبة إلى عدد عناصر المجموعة؛ لذا يضع هذا الإعداد حدًا للتكلفة المتكبدة أثناء التخطيط عند ظهور عدد كبير من عبارات IN في الاستعلام أو الإسقاط.

query_plan_max_step_description_length

الحد الأقصى لطول وصف الخطوة في EXPLAIN PLAN.

query_plan_merge_expressions

يبدّل تحسينًا على مستوى خطة الاستعلام يدمج المرشحات المتتالية. لا يسري مفعوله إلا إذا كانت قيمة الإعداد query_plan_enable_optimizations تساوي 1.

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

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

0 - تعطيل
1 - تمكين

query_plan_merge_filter_into_join_condition

السماح بدمج عامل التصفية ضمن شرط JOIN وتحويل CROSS JOIN إلى INNER.

query_plan_merge_filters

السماح بدمج عوامل التصفية في خطة الاستعلام.

query_plan_min_columns_for_join_lazy_indexing

يتحكم هذا الإعداد في الحد الأدنى لعدد أعمدة حمولة البيانات من الجانب الأيسر المطلوبة لتمكين تحسين الفهرسة الكسولة في JOIN. وتعني القيمة 0 أن هذا التحسين معطّل.

query_plan_optimize_join_order_algorithm

يحدّد خوارزميات ترتيب JOIN التي تجب تجربتها أثناء تحسين خطة الاستعلام. الخوارزميات التالية متاحة:

greedy - خوارزمية جشعة أساسية - تعمل بسرعة، لكنها قد لا تنتج أفضل ترتيب لعمليات JOIN
dpsize - يطبّق خوارزمية DPsize حاليًا على عمليات INNER JOIN فقط - يراعي جميع ترتيبات JOIN الممكنة ويعثر على الترتيب الأمثل، لكنه قد يكون بطيئًا للاستعلامات التي تتضمن عددًا كبيرًا من الجداول وشروط JOIN
dphyp - يطبّق خوارزمية DPhyp (البرمجة الديناميكية عبر تقسيم الرسم البياني الفائق) حاليًا على عمليات INNER JOIN فقط - يستكشف مجال البحث نفسه الذي تستكشفه dpsize، لكنه لا يُعدِّد إلا أزواج الرسوم البيانية الفرعية المتصلة، مما يولّد عددًا أقل من عمليات JOIN الوسيطة في رسوم JOIN البيانية المتناثرة، وذلك مقابل عدم أخذ الضربات الديكارتية في الحسبان يمكن تحديد عدة خوارزميات في صورة قائمة مفصولة بفواصل، مثل dphyp,greedy. وتُجرَّب هذه الخوارزميات بالترتيب؛ فإذا تعذّر على إحدى الخوارزميات التعامل مع الاستعلام (على سبيل المثال، بسبب عمليات OUTER JOIN أو المكوّنات غير المتصلة)، تُستخدَم الخوارزمية التالية كخيار احتياطي.

query_plan_optimize_join_order_limit

يعمل على تحسين ترتيب عمليات JOIN داخل الاستعلام الفرعي نفسه. ولا يُدعَم ذلك حاليًا إلا في حالات محدودة جدًا. القيمة هي الحد الأقصى لعدد الجداول التي يمكن تحسينها.

query_plan_optimize_join_order_max_searched_plans

الحد الأقصى لعدد الخطط الجزئية التي يمكن لمُحسِّن ترتيب join استكشافها قبل التوقف والرجوع إلى الخوارزمية التالية في query_plan_optimize_join_order_algorithm. يضع هذا حدًا حتميًا لزمن التحسين (بصرف النظر عن الزمن المنقضي فعليًا) في الرسوم البيانية الكثيفة لعمليات join، مثل cliques أو stars، حيث تنمو مساحة البحث نموًا أُسّيًا. اضبطه على 0 لتعطيل هذا الحد. لا يؤثر ذلك في القيمة الافتراضية query_plan_optimize_join_order_limit، حيث يظل البحث دائمًا أدنى بكثير من هذا الحد.

query_plan_optimize_join_order_randomize

عندما تكون القيمة غير صفرية، يستخدم مُحسِّن ترتيب join قيم cardinality وNDV مولَّدة عشوائيًا بدلًا من الإحصاءات الفعلية. عند ضبطها على 1، تُولَّد random seed، وعند ضبطها على قيمة > 1، تُستخدم تلك القيمة نفسها بوصفها seed مباشرةً. هذا مخصَّص للاختبار بهدف العثور على الأخطاء الناتجة عن ترتيبات join المختلفة.

query_plan_optimize_lazy_final

تحسين القراءة باستخدام FINAL من ReplacingMergeTree عبر إنشاء مجموعة من المفاتيح الأساسية واستخدامها لتحليل الفهرس.

query_plan_optimize_lazy_materialization

استخدم خطة الاستعلام لتحسين التجسيد الكسول.

query_plan_optimize_prewhere

السماح بدفع التصفية إلى تعبير PREWHERE لوحدات التخزين المدعومة

query_plan_push_down_limit

يبدّل حالة تحسين على مستوى خطة الاستعلام يدفع عبارات LIMIT إلى أسفل ضمن خطة التنفيذ. ولا يسري مفعوله إلا إذا كانت قيمة الإعداد query_plan_enable_optimizations تساوي 1.

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

0 - تعطيل
1 - تمكين

query_plan_push_limit_by_into_sort

يبدّل تحسينًا على مستوى خطة الاستعلام لاستعلامات ORDER BY ... LIMIT BY. عندما تكون أعمدة LIMIT BY بادئة لعبارة ORDER BY، يطبّق كل تدفق مفروز ومتوازٍ LIMIT BY قبل دمج التدفقات في تدفق واحد، مما يقلل عدد الصفوف التي تعالجها عملية الدمج النهائية ومراحل المسار اللاحقة. يسرّع ذلك الاستعلامات التي يستبعد فيها LIMIT BY نسبة كبيرة من الصفوف. لا يسري مفعوله إلا إذا كان الإعداد query_plan_enable_optimizations يساوي 1. القيم الممكنة:

0 - تعطيل
1 - تمكين

query_plan_read_in_order

يبدّل تفعيل تحسين القراءة بالترتيب على مستوى خطة الاستعلام. ولا يسري مفعوله إلا إذا كانت قيمة الإعداد query_plan_enable_optimizations تساوي 1.

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

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

0 - تعطيل
1 - تمكين

query_plan_read_in_order_through_join

الحفاظ على القراءة بالترتيب من الجدول الأيسر في عمليات JOIN، بحيث يمكن للخطوات اللاحقة الاستفادة من ذلك.

query_plan_remove_redundant_distinct

يبدّل تحسينًا على مستوى خطة الاستعلام يزيل خطوات DISTINCT غير الضرورية. لا يسري مفعوله إلا إذا كان الإعداد query_plan_enable_optimizations يساوي 1.

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

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

0 - تعطيل
1 - تمكين

query_plan_remove_redundant_sorting

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

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

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

0 - تعطيل
1 - تمكين

query_plan_remove_unused_columns

يُفعِّل أو يعطِّل تحسينًا على مستوى خطة الاستعلام يحاول إزالة الأعمدة غير المستخدمة (أعمدة الإدخال والإخراج على حدّ سواء) من خطوات خطة الاستعلام. ولا يسري مفعوله إلا إذا كانت قيمة الإعداد query_plan_enable_optimizations تساوي 1.

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

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

0 - تعطيل
1 - تمكين

query_plan_reuse_storage_ordering_for_window_functions

الأسماء البديلة: optimize_read_in_window_order يبدّل تحسينًا على مستوى خطة الاستعلام يستخدم ترتيب التخزين عند إجراء الفرز لدوال النافذة. ولا يسري مفعوله إلا إذا كان الإعداد query_plan_enable_optimizations مضبوطًا على 1.

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

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

0 - تعطيل
1 - تمكين

query_plan_split_filter

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

يتحكم في تفعيل تحسين على مستوى خطة الاستعلام يقسّم عوامل التصفية إلى تعبيرات أو تعطيله. ولا يسري إلا إذا كانت قيمة الإعداد query_plan_enable_optimizations تساوي 1. القيم الممكنة:

0 - تعطيل
1 - تمكين

query_plan_text_index_add_hint

يسمح بإضافة تلميح (شرط إضافي) لعملية التصفية المبنية من الفهرس النصي المعكوس في خطة الاستعلام.

query_plan_top_k_through_join

يؤدي هذا إلى تفعيل تحسين على مستوى خطة الاستعلام يدفع ORDER BY ... LIMIT n إلى أسفل عبر عملية join عندما لا يشير مفتاح الفرز إلا إلى الأعمدة في الجانب الذي يحتفظ به الـ join ‏(LEFT/RIGHT). ويقيّد عدد الصفوف التي يجب أن ينتجها الإدخال الخاص بالجانب المُحتفَظ به قبل إجراء الربط. لا يسري مفعوله إلا إذا كانت قيمة الإعداد query_plan_enable_optimizations تساوي 1. القيم الممكنة:

0 - تعطيل
1 - تمكين

query_plan_try_use_vector_search

يُبدّل تحسينًا على مستوى خطة الاستعلام يحاول استخدام فهرس تشابه المتجهات. ولا يسري مفعوله إلا إذا كانت قيمة الإعداد query_plan_enable_optimizations تساوي 1.

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

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

0 - تعطيل
1 - تمكين

query_profiler_cpu_time_period_ns

يحدّد الفترة الزمنية لمؤقّت ساعة CPU الخاص بـ أداة توصيف الاستعلام. لا يحسب هذا المؤقّت سوى وقت CPU. القيم الممكنة:

عدد صحيح موجب من النانوثواني. القيم الموصى بها:
- 10000000 (100 مرة في الثانية) نانوثانية أو أكثر للاستعلامات الفردية.
- 1000000000 (مرة واحدة في الثانية) للتوصيف على مستوى العنقود بالكامل.
0 لإيقاف المؤقّت.

انظر أيضًا:

جدول النظام trace_log

query_profiler_real_time_period_ns

يحدّد الفترة الزمنية لمؤقّت الزمن الحقيقي الخاص بـ أداة توصيف الاستعلام. ويقيس مؤقّت الزمن الحقيقي وقت الساعة. القيم الممكنة:

عدد صحيح موجب، بالنانوثانية. القيم الموصى بها:
- 10000000 (100 مرة في الثانية) نانوثانية أو أقل للاستعلامات الفردية.
- 1000000000 (مرة واحدة في الثانية) لتحليل الأداء على مستوى العنقود بأكمله.
0 لإيقاف المؤقّت.

انظر أيضًا:

جدول النظام trace_log

القيمة الافتراضية في Cloud: 3000000000.

queue_max_wait_ms

زمن الانتظار في قائمة انتظار الطلبات إذا تجاوز عدد الطلبات المتزامنة الحد الأقصى.

rabbitmq_max_wait_ms

مدة الانتظار قبل إعادة المحاولة عند القراءة من RabbitMQ.

read_backoff_max_throughput

إعدادات لتقليل عدد الخيوط عند بطء عمليات القراءة. تُحتسب الأحداث عندما يقل معدل نقل القراءة عن هذا العدد من البايتات في الثانية.

read_backoff_min_concurrency

إعدادات تهدف إلى الإبقاء على الحد الأدنى من الخيوط عند بطء عمليات القراءة.

read_backoff_min_events

إعدادات لتقليل عدد الخيوط في حال بطء عمليات القراءة. عدد الأحداث الذي بعده سيُخفَّض عدد الخيوط.

read_backoff_min_interval_between_events_ms

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

read_backoff_min_latency_ms

إعداد لتقليل عدد خيوط التنفيذ عند بطء عمليات القراءة. لا تُؤخذ في الاعتبار إلا عمليات القراءة التي استغرقت على الأقل هذا القدر من الوقت.

read_from_distributed_cache_if_exists_otherwise_bypass_cache

لا يكون لهذا الإعداد أي تأثير إلا في ClickHouse Cloud. وهو مماثل لـ read_from_filesystem_cache_if_exists_otherwise_bypass_cache، ولكن لذاكرة التخزين المؤقت الموزعة.

read_from_filesystem_cache_if_exists_otherwise_bypass_cache

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

read_from_page_cache_if_exists_otherwise_bypass_cache

استخدم ذاكرة تخزين مؤقت للصفحات في مساحة المستخدم في الوضع السلبي، على غرار read_from_filesystem_cache_if_exists_otherwise_bypass_cache.

read_in_order_two_level_merge_threshold

الحد الأدنى لعدد الأجزاء التي يجب قراءتها لتشغيل خطوة الدمج الأولي أثناء القراءة متعددة الخيوط وفق ترتيب المفتاح الأساسي.

read_in_order_use_buffering

استخدم التخزين المؤقت قبل الدمج أثناء القراءة وفق ترتيب المفتاح الأساسي. يزيد ذلك من التوازي في تنفيذ الاستعلام

read_in_order_use_virtual_row

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

read_in_order_use_virtual_row_per_block

عند تمكينه مع read_in_order_use_virtual_row، يُخرِج صفًا افتراضيًا بعد كل block تتم قراءته (وليس فقط في بداية كل part). يتيح ذلك لـ MergingSortedTransform إعادة تحديد أولوية sources بوتيرة أعلى، وهو ما يكون مفيدًا عندما تستبعد عوامل التصفية اللاحقة عددًا كبيرًا من rows وتكون البيانات موزعة بشكل غير متساوٍ عبر parts. لاحظ أن هذا يعطّل تحسين read_in_order_use_buffering وpreliminary merge (read_in_order_two_level_merge_threshold) أثناء القراءة.

read_overflow_mode

ما يجب فعله عند تجاوز الحد.

read_overflow_mode_leaf

يحدّد ما يحدث عندما يتجاوز حجم البيانات المقروءة أحد الحدود الخاصة بالعُقد الطرفية. الخيارات الممكنة:

throw: إثارة استثناء (الافتراضي).
break: إيقاف تنفيذ الاستعلام وإرجاع نتيجة جزئية.

read_priority

أولوية قراءة البيانات من نظام الملفات المحلي أو نظام الملفات البعيد. لا يُدعم هذا إلا مع الأسلوب ‘pread_threadpool’ لنظام الملفات المحلي، ومع الأسلوب threadpool لنظام الملفات البعيد.

read_through_distributed_cache

لا يكون له تأثير إلا في ClickHouse Cloud. يتيح القراءة من ذاكرة التخزين المؤقت الموزعة

readonly

0 - لا توجد قيود على وضع القراءة فقط. 1 - يُسمح فقط بطلبات القراءة، وكذلك بتغيير الإعدادات المسموح بها صراحةً. 2 - يُسمح فقط بطلبات القراءة، وكذلك بتغيير الإعدادات، باستثناء الإعداد ‘readonly’.

receive_data_timeout_ms

مهلة الاتصال لتلقّي أول حزمة بيانات أو حزمة تُظهر تقدّمًا من النسخة المتماثلة

receive_timeout

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

recursive_cte_max_steps_in_type_inference

الحد الأقصى لعدد التكرارات لاستنتاج أنواع الأعمدة في CTEs التكرارية. تُحدَّد أنواع الأعمدة من خلال التطبيق التكراري للدالة getLeastSupertype على الجزأين غير التكراري والتكراري من UNION ALL حتى الوصول إلى حالة الاستقرار. اضبطه على 0 لتعطيل توسيع النوع واستخدام أنواع الجزء غير التكراري فقط.

regexp_dict_allow_hyperscan

يسمح لقاموس regexp_tree باستخدام مكتبة Hyperscan.

regexp_dict_flag_case_insensitive

استخدم مطابقة غير حساسة لحالة الأحرف لقاموس regexp_tree. ويمكن تجاوز هذا الإعداد في التعبيرات الفردية باستخدام (?i) و (?-i).

regexp_dict_flag_dotall

يسمح للرمز ’.’ بمطابقة أحرف السطر الجديد في قاموس regexp_tree.

regexp_max_matches_per_row

يحدّد الحد الأقصى لعدد التطابقات لتعبير نمطي واحد في كل صف. استخدمه للحماية من الاستهلاك المفرط للذاكرة عند استخدام تعبير نمطي جشع في الدالة extractAllGroupsHorizontal. القيم الممكنة:

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

reject_expensive_hyperscan_regexps

يرفض الأنماط التي يُرجّح أن يكون تقييمها مكلفًا باستخدام hyperscan (بسبب انفجار حالات NFA)

remerge_sort_lowered_memory_bytes_ratio

إذا لم ينخفض استهلاك الذاكرة بعد إعادة الدمج بهذه النسبة، فسيتم تعطيل إعادة الدمج.

remote_filesystem_read_method

طريقة قراءة البيانات من نظام الملفات البعيد، وتكون إحدى القيم التالية: read، threadpool.

remote_filesystem_read_prefetch

يُستخدم الجلب المسبق عند قراءة البيانات من نظام الملفات البعيد.

remote_fs_read_backoff_max_tries

الحد الأقصى لعدد محاولات القراءة عند استخدام آلية التراجع التدريجي

remote_fs_read_max_backoff_ms

الحد الأقصى لمدة الانتظار عند محاولة قراءة البيانات من القرص البعيد

remote_read_min_bytes_for_seek

الحد الأدنى من البايتات المطلوبة للقراءة عن بُعد (URL، S3) لإجراء seek بدلًا من القراءة مع ignore.

rename_files_after_processing

النوع: String
القيمة الافتراضية: سلسلة فارغة

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

العناصر النائبة

%a — اسم الملف الأصلي كاملًا (مثل: “sample.csv”).
%f — اسم الملف الأصلي من دون امتداد (مثل: “sample”).
%e — امتداد الملف الأصلي متضمّنًا النقطة (مثل: “.csv”).
%t — الطابع الزمني (بالميكروثانية).
%% — علامة النسبة المئوية (”%”).

مثال

الخيار: --rename_files_after_processing="processed_%f_%t%e"
الاستعلام: SELECT * FROM file('sample.csv')

إذا تمت قراءة sample.csv بنجاح، فستُعاد تسمية الملف إلى processed_sample_1683473210851438.csv

replace_running_query

عند استخدام واجهة HTTP، يمكن تمرير المعلَمة ‘query_id’. ويمكن أن تكون أي سلسلة نصية تُستخدم كمُعرّف للاستعلام. إذا كان هناك بالفعل استعلام للمستخدم نفسه وله ‘query_id’ نفسه في هذا الوقت، فإن السلوك يعتمد على المعلَمة ‘replace_running_query’. 0 (الافتراضي) – إثارة استثناء (عدم السماح بتشغيل الاستعلام إذا كان هناك بالفعل استعلام له ‘query_id’ نفسه قيد التشغيل). 1 – إلغاء الاستعلام القديم وبدء تشغيل الاستعلام الجديد. اضبط هذه المعلَمة على 1 لتنفيذ اقتراحات شروط التقسيم. بعد إدخال الحرف التالي، إذا لم يكن الاستعلام القديم قد انتهى بعد، فيجب إلغاؤه.

replace_running_query_max_wait_ms

مدة الانتظار اللازمة لانتهاء الاستعلام الجاري الذي يحمل query_id نفسه، عندما يكون الإعداد replace_running_query مفعّلًا. القيم الممكنة:

عدد صحيح موجب.
0 — طرح استثناء يمنع تشغيل استعلام جديد إذا كان الخادم ينفّذ بالفعل استعلامًا يحمل query_id نفسه.

replication_wait_for_inactive_replica_timeout

يحدّد المدة (بالثواني) التي يجب انتظارها حتى تنفّذ النسخ المتماثلة غير النشطة استعلامات ALTER أو OPTIMIZE أو TRUNCATE. القيم الممكنة:

0 — لا تنتظر.
عدد صحيح سالب — انتظر لمدة غير محدودة.
عدد صحيح موجب — عدد الثواني التي يجب انتظارها.

restore_replace_external_dictionary_source_to_null

استبدال مصادر القواميس الخارجية بالقيمة Null عند الاستعادة. مفيد لأغراض الاختبار

restore_replace_external_engines_to_null

لأغراض الاختبار. يستبدل جميع المحركات الخارجية بـ Null حتى لا يُنشئ اتصالات خارجية.

restore_replace_external_table_functions_to_null

لأغراض الاختبار. يستبدل جميع دوال الجداول الخارجية بـ Null لتجنّب إنشاء اتصالات خارجية.

restore_replicated_merge_tree_to_shared_merge_tree

يُستبدل محرك الجدول من ReplicatedMergeTree -> SharedMergeTree أثناء RESTORE. القيمة الافتراضية في Cloud: 1.

result_overflow_mode

القيمة الافتراضية في Cloud: throw يحدّد ما يجب فعله إذا تجاوز حجم النتيجة أحد الحدود. القيم الممكنة:

throw: رفع استثناء (افتراضي).
break: إيقاف تنفيذ الاستعلام وإرجاع نتيجة جزئية، كما لو أن البيانات المصدر قد نفدت.

يشبه استخدام ‘break’ استخدام LIMIT. لا يوقف Break التنفيذ إلا على مستوى الكتلة. وهذا يعني أن عدد الصفوف المُعادة يكون أكبر من max_result_rows، ويكون مضاعفًا لـ max_block_size ويعتمد على max_threads. مثال

Query

SET max_threads = 3, max_block_size = 3333;
SET max_result_rows = 3334, result_overflow_mode = 'break';

SELECT *
FROM numbers_mt(100000)
FORMAT Null;

Result

6666 rows in set. ...

rewrite_count_distinct_if_with_count_distinct_implementation

يتيح لك إعادة كتابة countDistcintIf باستخدام إعداد count_distinct_implementation. القيم الممكنة:

true — مسموح.
false — غير مسموح.

rewrite_in_to_join

أعد كتابة تعبيرات مثل ‘x IN subquery’ بصيغة JOIN. قد يكون ذلك مفيدًا لتحسين الاستعلام بأكمله باستخدام إعادة ترتيب عمليات JOIN.

rows_before_aggregation

عند تفعيله، سيوفّر ClickHouse قيمة دقيقة لإحصائية rows_before_aggregation، التي تمثّل عدد الصفوف المقروءة قبل التجمي

s3_allow_multipart_copy

تمكين النسخ متعدد الأجزاء في S3.

s3_allow_parallel_part_upload

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

s3_check_objects_after_upload

تحقّق من كل كائن تم رفعه إلى S3 باستخدام طلب head للتأكد من نجاح عملية الرفع

s3_connect_timeout_ms

مهلة الاتصال بالمضيف لأقراص S3.

s3_create_new_file_on_insert

يؤدي إلى تمكين أو تعطيل إنشاء ملف جديد مع كل عملية insert في جداول محرك S3. عند التمكين، سيُنشأ كائن S3 جديد بمفتاح جديد مع كل عملية insert، وفق نمط مشابه لما يلي: الأصل: data.Parquet.gz -> data.1.Parquet.gz -> data.2.Parquet.gz، إلخ. القيم الممكنة:

0 — ينشئ استعلام INSERT ملفًا جديدًا، أو يفشل إذا كان الملف موجودًا ولم يتم تعيين s3_truncate_on_insert.
1 — ينشئ استعلام INSERT ملفًا جديدًا مع كل عملية insert باستخدام لاحقة (بدءًا من الملف الثاني) إذا لم يتم تعيين s3_truncate_on_insert.

اطّلع على مزيد من التفاصيل هنا.

s3_disable_checksum

لا تحسب قيمة checksum عند إرسال ملف إلى S3. يسرّع ذلك عمليات الكتابة من خلال تجنّب تكرار المعالجة غير الضروري للملف. ويُعد هذا آمنًا في معظم الحالات، لأن ClickHouse يتحقق أصلًا من سلامة بيانات جداول MergeTree باستخدام checksums، وعند الوصول إلى S3 عبر HTTPS، توفّر طبقة TLS بالفعل سلامة البيانات أثناء نقلها عبر الشبكة. ومع ذلك، فإن استخدام checksums إضافية على S3 يوفّر طبقة حماية إضافية.

s3_ignore_file_doesnt_exist

تجاهل عدم وجود الملف عند قراءة مفاتيح معيّنة. القيم الممكنة:

1 — يعيد SELECT نتيجة فارغة.
0 — يطلق SELECT استثناءً.

s3_list_object_keys_size

الحد الأقصى لعدد الملفات التي يمكن أن يعيدها طلب ListObject في دفعة واحدة

s3_max_connections

الحد الأقصى لعدد الاتصالات لكل خادم.

s3_max_get_burst

الحد الأقصى لعدد الطلبات التي يمكن إصدارها بالتزامن قبل بلوغ حدّ الطلبات في الثانية. افتراضيًا، تكون القيمة (0) مساوية لـ s3_max_get_rps

s3_max_get_rps

الحد الأقصى لعدد طلبات GET إلى S3 في الثانية قبل بدء throttling. تعني القيمة صفر عدم وجود حد.

s3_max_inflight_parts_for_one_file

الحد الأقصى لعدد الأجزاء التي يمكن تحميلها بالتوازي في طلب الرفع متعدد الأجزاء. تعني القيمة 0 عدم وجود حد.

s3_max_part_number

الحد الأقصى لرقم جزء الرفع إلى S3.

s3_max_put_burst

الحد الأقصى لعدد الطلبات التي يمكن إرسالها بالتزامن قبل الوصول إلى حد الطلبات في الثانية. تكون القيمة الافتراضية (0) مساوية لـ s3_max_put_rps

s3_max_put_rps

الحد الأقصى لمعدل طلبات PUT إلى S3 في الثانية قبل تطبيق throttling. وتعني القيمة صفر عدم وجود حد.

s3_max_single_operation_copy_size

الحد الأقصى لحجم عملية نسخ واحدة في S3. لا يُستخدم هذا الإعداد إلا إذا كانت قيمة s3_allow_multipart_copy هي true.

s3_max_single_part_upload_size

الحد الأقصى لحجم الكائن الذي يمكن رفعه إلى S3 باستخدام رفع أحادي الجزء.

s3_max_single_read_retries

الحد الأقصى لعدد مرات إعادة المحاولة عند تنفيذ قراءة واحدة من S3.

s3_max_unexpected_write_error_retries

الحد الأقصى لعدد مرات إعادة المحاولة عند حدوث أخطاء غير متوقعة أثناء الكتابة إلى S3.

s3_max_upload_part_size

الحد الأقصى لحجم الجزء المراد تحميله أثناء الرفع متعدد الأجزاء إلى S3.

s3_min_upload_part_size

الحد الأدنى لحجم الجزء المطلوب رفعه أثناء الرفع متعدد الأجزاء إلى S3.

s3_path_filter_limit

الحد الأقصى لعدد قيم _path التي يمكن استخراجها من مرشحات الاستعلام لاستخدامها عند التكرار على الملفات بدلًا من السرد باستخدام glob. وتعني القيمة 0 أنه معطّل.

s3_request_timeout_ms

مهلة الخمول لإرسال البيانات إلى S3 واستقبالها منه. تُعدّ العملية فاشلة إذا ظلّ استدعاء واحد للقراءة أو الكتابة عبر TCP محجوبًا طوال هذه المدة.

s3_skip_empty_files

يُمكّن أو يعطّل تخطي الملفات الفارغة في الجداول التي تستخدم المحرك S3. القيم الممكنة:

0 — يُطلق SELECT استثناءً إذا لم يكن الملف الفارغ متوافقًا مع التنسيق المطلوب.
1 — يعيد SELECT نتيجة فارغة للملف الفارغ.

s3_slow_all_threads_after_network_error

عند تعيينه إلى true، تُبطَّأ جميع خيوط التنفيذ التي تنفّذ طلبات S3 إلى نقطة نهاية النسخ الاحتياطي نفسها بعد أن يواجه أي طلب S3 واحد خطأ شبكة قابلاً لإعادة المحاولة، مثل انتهاء مهلة المقبس. وعند تعيينه إلى false، تتعامل كل خيط تنفيذ مع تأخير إعادة المحاولة لطلبات S3 بشكل مستقل عن الخيوط الأخرى.

s3_strict_upload_part_size

الحجم الدقيق للجزء المطلوب رفعه أثناء الرفع متعدد الأجزاء إلى S3 (بعض التطبيقات لا تدعم الأجزاء ذات الأحجام المتغيرة).

s3_throw_on_zero_files_match

إظهار خطأ عند تعذّر طلب ListObjects على مطابقة أي ملفات

s3_truncate_on_insert

يُمكّن أو يعطّل إجراء truncate قبل عمليات الإدراج في جداول محرك S3. وإذا كان معطّلًا، فسيُطرَح استثناء عند محاولة الإدراج إذا كان كائن في S3 موجودًا بالفعل. القيم الممكنة:

0 — ينشئ استعلام INSERT ملفًا جديدًا، أو يفشل إذا كان الملف موجودًا ولم يتم تعيين s3_create_new_file_on_insert.
1 — يستبدل استعلام INSERT المحتوى الحالي للملف بالبيانات الجديدة.

اطّلع على مزيد من التفاصيل هنا.

s3_upload_part_size_multiply_factor

اضرب s3_min_upload_part_size في هذا العامل في كل مرة يتم فيها تحميل s3_multiply_parts_count_threshold جزءًا من عملية كتابة واحدة إلى S3.

s3_upload_part_size_multiply_parts_count_threshold

في كل مرة يُرفَع فيها هذا العدد من الأجزاء إلى S3، تُضاعَف قيمة s3_min_upload_part_size بمعامل s3_upload_part_size_multiply_factor.

s3_uri_style

يفرض نمط نقطة نهاية S3. القيم الممكنة: auto، virtual_hosted، path.

s3_use_adaptive_timeouts

عند ضبطه على true، تُجرى المحاولتان الأوليان لجميع طلبات S3 أولًا بمهلات إرسال واستقبال منخفضة. وعند ضبطه على false، تُجرى جميع المحاولات بمهلات متطابقة.

s3_validate_request_settings

يُمكّن التحقق من صحة إعدادات طلبات S3. القيم الممكنة:

1 — التحقق من صحة الإعدادات.
0 — عدم التحقق من صحة الإعدادات.

s3queue_default_zookeeper_path

بادئة مسار ZooKeeper الافتراضية لمحرك S3Queue

s3queue_enable_logging_to_s3queue_log

يتيح الكتابة في system.s3queue_log. ويمكن تجاوز هذه القيمة على مستوى كل جدول باستخدام إعدادات الجدول

s3queue_keeper_fault_injection_probability

احتمال حقن الأعطال في Keeper الخاص بـ S3Queue.

s3queue_migrate_old_metadata_to_buckets

ترحيل بنية البيانات الوصفية القديمة لجدول S3Queue إلى بنية جديدة

schema_inference_cache_require_modification_time_for_url

استخدم المخطط من ذاكرة التخزين المؤقت لعناوين URL مع التحقق من وقت آخر تعديل (لعناوين URL التي تتضمن ترويسة Last-Modified)

schema_inference_use_cache_for_azure

استخدم ذاكرة التخزين المؤقت عند استنتاج المخطط أثناء استخدام دالة الجدول Azure

schema_inference_use_cache_for_file

استخدم ذاكرة التخزين المؤقت في استنتاج المخطط عند استخدام دالة الجدول file

schema_inference_use_cache_for_hdfs

استخدم ذاكرة التخزين المؤقت عند استنتاج المخطط أثناء استخدام دالة table functio الخاصة بـ hdfs

schema_inference_use_cache_for_s3

استخدم ذاكرة التخزين المؤقت عند استنتاج المخطط أثناء استخدام دالة الجدول S3

schema_inference_use_cache_for_url

استخدم ذاكرة التخزين المؤقت عند استنتاج المخطط أثناء استخدام دالة الجدول URL

secondary_indices_enable_bulk_filtering

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

select_sequential_consistency

يختلف سلوك هذا الإعداد بين SharedMergeTree وReplicatedMergeTree. راجع SharedMergeTree consistency لمزيد من المعلومات حول سلوك select_sequential_consistency في SharedMergeTree.

يُمكّن هذا الإعداد الاتساق التسلسلي لاستعلامات SELECT أو يعطّله. ويتطلب تعطيل insert_quorum_parallel (وهو مُمكَّن افتراضيًا). القيم الممكنة:

0 — معطّل.
1 — مُمكَّن.

الاستخدام عند تمكين الاتساق التسلسلي، لا يسمح ClickHouse للعميل بتنفيذ استعلام SELECT إلا على النسخ المتماثلة التي تحتوي على بيانات جميع استعلامات INSERT السابقة المنفَّذة باستخدام insert_quorum. وإذا وجّه العميل الطلب إلى نسخة متماثلة جزئية، فسيُرجع ClickHouse استثناءً. ولن يتضمن استعلام SELECT البيانات التي لم تُكتب بعد إلى النصاب المطلوب من النسخ المتماثلة. عندما يكون insert_quorum_parallel مُمكَّنًا (وهو الوضع الافتراضي)، فإن select_sequential_consistency لا يعمل. ويرجع ذلك إلى أن استعلامات INSERT المتوازية قد تُكتب إلى مجموعات مختلفة من النسخ المتماثلة الخاصة بالنصاب، لذا لا يوجد ما يضمن أن نسخة متماثلة واحدة قد استقبلت جميع عمليات الكتابة. انظر أيضًا:

insert_quorum
insert_quorum_timeout
insert_quorum_parallel

send_logs_level

يرسل السجلات النصية الخاصة بالخادم إلى العميل عند الحد الأدنى المحدد من المستوى. القيم الصالحة: ‘trace’، ‘debug’، ‘information’، ‘warning’، ‘error’، ‘fatal’، ‘none’

send_logs_source_regexp

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

send_profile_events

يُفعِّل أو يعطِّل إرسال حزم ProfileEvents إلى العميل. يمكن تعطيل هذا لتقليل حركة مرور الشبكة للعملاء الذين لا يحتاجون إلى أحداث Profile. القيم الممكنة:

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

send_progress_in_http_headers

يُمكّن أو يعطّل رؤوس HTTP للاستجابة X-ClickHouse-Progress في ردود clickhouse-server. لمزيد من المعلومات، اقرأ وصف واجهة HTTP. القيم الممكنة:

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

send_table_structure_on_insert_with_inline_data

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

send_timeout

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

serialize_query_plan

إجراء تسلسل لخطة الاستعلام للمعالجة الموزعة

serialize_string_in_memory_with_zero_byte

سلسِل قيم String أثناء التجميع مع إضافة بايت صفري في النهاية. فعّل هذا الخيار للحفاظ على التوافق عند الاستعلام عن عنقود بإصدارات غير متوافقة.

session_timezone

يحدّد المنطقة الزمنية الضمنية للجلسة الحالية أو للاستعلام الحالي. المنطقة الزمنية الضمنية هي المنطقة الزمنية التي تُطبَّق على القيم من النوع DateTime/DateTime64 التي لا تكون لها منطقة زمنية محددة صراحةً. لهذا الإعداد أولوية على المنطقة الزمنية الضمنية المُعدّة عمومًا (على مستوى الخادم). تعني القيمة ” (سلسلة فارغة) أن المنطقة الزمنية الضمنية للجلسة الحالية أو للاستعلام الحالي تساوي المنطقة الزمنية للخادم. يمكنك استخدام الدالتين timeZone() وserverTimeZone() للحصول على المنطقة الزمنية للجلسة والمنطقة الزمنية للخادم. القيم الممكنة:

أي اسم منطقة زمنية من system.time_zones، مثل Europe/Berlin أو UTC أو Zulu

أمثلة:

SELECT timeZone(), serverTimeZone() FORMAT CSV

"Europe/Berlin","Europe/Berlin"

SELECT timeZone(), serverTimeZone() SETTINGS session_timezone = 'Asia/Novosibirsk' FORMAT CSV

"Asia/Novosibirsk","Europe/Berlin"

عيّن المنطقة الزمنية للجلسة ‘America/Denver’ لقيمة DateTime الداخلية التي لم تُحدَّد لها منطقة زمنية صراحةً:

SELECT toDateTime64(toDateTime64('1999-12-12 23:23:23.123', 3), 3, 'Europe/Zurich') SETTINGS session_timezone = 'America/Denver' FORMAT TSV

1999-12-13 07:23:23.123

لا تراعي جميع الدوال التي تُحلِّل DateTime/DateTime64 القيمة session_timezone. وقد يؤدي ذلك إلى أخطاء دقيقة يصعب ملاحظتها. راجع المثال التالي والشرح المصاحب له.

CREATE TABLE test_tz (`d` DateTime('UTC')) ENGINE = Memory AS SELECT toDateTime('2000-01-01 00:00:00', 'UTC');

SELECT *, timeZone() FROM test_tz WHERE d = toDateTime('2000-01-01 00:00:00') SETTINGS session_timezone = 'Asia/Novosibirsk'
0 rows in set.

SELECT *, timeZone() FROM test_tz WHERE d = '2000-01-01 00:00:00' SETTINGS session_timezone = 'Asia/Novosibirsk'
┌───────────────────d─┬─timeZone()───────┐
│ 2000-01-01 00:00:00 │ Asia/Novosibirsk │
└─────────────────────┴──────────────────┘

يحدث هذا بسبب اختلاف مسارات التحليل:

إن toDateTime()، عند استخدامها في استعلام SELECT الأول من دون تحديد time zone صراحةً، تراعي الإعداد session_timezone والمنطقة الزمنية العامة.
في الاستعلام الثاني، يُحلَّل DateTime من String، ويرث النوع والمنطقة الزمنية من العمود الموجود d. لذلك، لا يُعتدّ بالإعداد session_timezone ولا بالمنطقة الزمنية العامة.

انظر أيضًا

timezone

set_overflow_mode

يحدد ما الذي يحدث عندما تتجاوز كمية البيانات أحد الحدود. القيم الممكنة:

throw: طرح استثناء (الافتراضي).
break: إيقاف تنفيذ الاستعلام وإرجاع نتيجة جزئية، كما لو أن بيانات المصدر قد نفدت.

shared_merge_tree_sequential_consistency_initial_parts_update_backoff_ms

فترة التراجع الأولية، بالمللي ثانية، لتحديث الأجزاء عند استخدام select_sequential_consistency مع SharedMergeTree. متاح فقط في ClickHouse Cloud.

shared_merge_tree_sequential_consistency_max_parts_update_backoff_ms

الحد الأقصى لفترة التراجع، بالمللي ثانية، لتحديث الأجزاء عند استخدام select_sequential_consistency مع SharedMergeTree. هذا الإعداد متاح فقط في ClickHouse Cloud.

shared_merge_tree_sequential_consistency_parts_update_max_retries

الحد الأقصى لعدد مرات إعادة المحاولة لتحديث الأجزاء عند استخدام select_sequential_consistency مع SharedMergeTree. متاح فقط في ClickHouse Cloud.

shared_merge_tree_sync_parts_on_partition_operations

تتم مزامنة مجموعة أجزاء البيانات تلقائيًا بعد عمليات partition من MOVE|REPLACE|ATTACH في جداول SMT. Cloud فقط

short_circuit_function_evaluation

يسمح بحساب الدوال if وmultiIf وand وor وفقًا لآلية التقييم المختصر. يساعد ذلك على تحسين تنفيذ التعبيرات المعقدة في هذه الدوال ومنع الاستثناءات المحتملة (مثل القسمة على الصفر عندما لا يكون ذلك متوقعًا). القيم الممكنة:

enable — يفعّل التقييم المختصر للدوال المناسبة لذلك (التي قد تطرح استثناءً أو تكون مكلفة حسابيًا).
force_enable — يفعّل التقييم المختصر لجميع الدوال.
disable — يعطّل التقييم المختصر للدوال.

short_circuit_function_evaluation_for_nulls

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

short_circuit_function_evaluation_for_nulls_threshold

عتبة نسبة قيم NULL لتشغيل الدوال ذات الوسيطات Nullable فقط على الصفوف التي تكون فيها جميع الوسيطات ذات قيم غير NULL. يُطبَّق هذا عند تمكين الإعداد short_circuit_function_evaluation_for_nulls. عندما تتجاوز نسبة الصفوف التي تحتوي على قيم NULL من إجمالي عدد الصفوف هذه العتبة، فلن يتم تقييم هذه الصفوف التي تحتوي على قيم NULL.

show_processlist_include_internal

إظهار العمليات الداخلية المساعدة في مخرجات الاستعلام SHOW PROCESSLIST. تشمل العمليات الداخلية إعادة تحميل القواميس، وإعادة تحميل العروض المادية القابلة للتحديث، وعمليات SELECT المساعدة المنفذة ضمن استعلامات SHOW ...، واستعلامات CREATE DATABASE ... المساعدة المنفذة داخليًا للتعامل مع الجداول المعطوبة، وغير ذلك.

show_remote_databases_in_system_tables

الأسماء البديلة: show_data_lake_catalogs_in_system_tables يُفعّل إظهار قواعد البيانات البعيدة (كتالوجات بحيرة البيانات، وMySQL، وPostgreSQL) في جداول النظام.

show_table_uuid_in_table_create_query_if_not_nil

يضبط طريقة عرض استعلام SHOW TABLE. القيم الممكنة:

0 — سيُعرض الاستعلام بدون UUID للجدول.
1 — سيُعرض الاستعلام مع UUID للجدول.

single_join_prefer_left_table

في حالة استخدام JOIN واحد، وعند وجود غموض في المعرّف، يُفضَّل الجدول الأيسر

skip_redundant_aliases_in_udf

لا تُستخدَم الأسماء المستعارة الزائدة (ولا تُستبدَل) في الدوال المعرّفة من قبل المستخدم، وذلك لتبسيط استخدامها. القيم الممكنة:

1 — يتم تخطي الأسماء المستعارة (واستبدالها) في UDFs.
0 — لا يتم تخطي الأسماء المستعارة (ولا استبدالها) في UDFs.

مثال الفرق بين حالتي التمكين والتعطيل: الاستعلام:

SET skip_redundant_aliases_in_udf = 0;
CREATE FUNCTION IF NOT EXISTS test_03274 AS ( x ) -> ((x + 1 as y, y + 2));

EXPLAIN SYNTAX SELECT test_03274(4 + 2);

النتيجة:

SELECT ((4 + 2) + 1 AS y, y + 2)

الاستعلام:

SET skip_redundant_aliases_in_udf = 1;
CREATE FUNCTION IF NOT EXISTS test_03274 AS ( x ) -> ((x + 1 as y, y + 2));

EXPLAIN SYNTAX SELECT test_03274(4 + 2);

النتيجة:

SELECT ((4 + 2) + 1, ((4 + 2) + 1) + 2)

skip_unavailable_shards

يُفعِّل أو يعطِّل تخطي الشظايا غير المتاحة بصمت. تُعد الشظية غير متاحة إذا كانت جميع النسخ المتماثلة التابعة لها غير متاحة. وتكون النسخة المتماثلة غير متاحة في الحالات التالية:

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

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

1 — التخطي مفعّل. إذا كانت إحدى الشظايا غير متاحة، يعيد ClickHouse نتيجةً تستند إلى بيانات جزئية ولا يبلّغ عن مشكلات في توافر العقد.
0 — التخطي معطّل. إذا كانت إحدى الشظايا غير متاحة، يطرح ClickHouse استثناءً.

sleep_after_receiving_query_ms

مدة التوقف بعد تلقّي الاستعلام في TCPHandler

sleep_in_send_data_ms

مدة التوقف المؤقت عند إرسال البيانات في TCPHandler

sleep_in_send_tables_status_ms

مدة السكون عند إرسال استجابة حالة الجداول في TCPHandler

sort_overflow_mode

يحدّد ما يحدث إذا تجاوز عدد الصفوف المُستلمة قبل الفرز أحد الحدود. القيم الممكنة:

throw: طرح استثناء.
break: إيقاف تنفيذ الاستعلام وإرجاع نتيجة جزئية.

split_intersecting_parts_ranges_into_layers_final

تقسيم نطاقات الأجزاء المتداخلة إلى طبقات أثناء تحسين FINAL

split_parts_ranges_into_intersecting_and_non_intersecting_final

تقسيم نطاقات الأجزاء إلى نطاقات متقاطعة وأخرى غير متقاطعة أثناء تحسين FINAL

splitby_max_substrings_includes_remaining_string

يتحكم هذا الإعداد في ما إذا كانت الدالة splitBy*()، عند استخدام الوسيط max_substrings > 0، ستُضمِّن السلسلة المتبقية في العنصر الأخير من مصفوفة النتيجة. القيم الممكنة:

0 - لن تُضمَّن السلسلة المتبقية في العنصر الأخير من مصفوفة النتيجة.
1 - ستُضمَّن السلسلة المتبقية في العنصر الأخير من مصفوفة النتيجة. وهذا هو سلوك الدالة split() في Spark، والأسلوب ‘string.split()’ في بايثون.

stop_refreshable_materialized_views_on_startup

عند بدء تشغيل الخادم، امنع جدولة العروض المادية القابلة لإعادة التحديث، كما لو تم استخدام SYSTEM STOP VIEWS. يمكنك بدء تشغيلها يدويًا لاحقًا باستخدام SYSTEM START VIEWS أو SYSTEM START VIEW <name>. ينطبق ذلك أيضًا على العروض المُنشأة حديثًا. لا يؤثر ذلك في العروض المادية غير القابلة لإعادة التحديث.

storage_file_read_method

طريقة قراءة البيانات من ملف التخزين، وتكون إحدى الطرق التالية: read، pread، mmap. لا تنطبق الطريقة mmap على clickhouse-server (فهي مخصّصة لـ clickhouse-local).

storage_system_stack_trace_pipe_read_timeout_ms

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

stream_flush_interval_ms

يعمل مع الجداول المتدفقة عند حدوث مهلة، أو عندما يُنشئ مؤشر ترابط max_insert_block_size من الصفوف. القيمة الافتراضية هي 7500. كلما صغرت القيمة، زاد تكرار تفريغ البيانات إلى الجدول. ويؤدي تعيين قيمة منخفضة جدًا إلى ضعف الأداء.

stream_like_engine_allow_direct_select

السماح باستعلام SELECT مباشر لمحركات Kafka وRabbitMQ وFileLog وRedis Streams وS3Queue وAzureQueue وNATS. في حال وجود عروض مادية مرفقة، لا يُسمح باستعلام SELECT حتى إذا كان هذا الإعداد مُمكّنًا. إذا لم تكن هناك عروض مادية مرفقة، فإن تمكين هذا الإعداد يتيح قراءة البيانات. انتبه إلى أن البيانات المقروءة تُزال عادةً من قائمة الانتظار. ولتجنّب إزالة البيانات المقروءة، يجب تهيئة إعدادات المحرك ذات الصلة بشكل صحيح.

stream_like_engine_insert_queue

عندما يقرأ محرك من نوع stream من عدة قوائم انتظار، سيحتاج المستخدم إلى اختيار قائمة انتظار واحدة لتنفيذ insert فيها عند الكتابة. تُستخدم هذه الخاصية في Redis Streams وNATS.

stream_poll_timeout_ms

مهلة استقصاء البيانات من/إلى مخازن البث.

system_events_show_zero_values

يسمح بتحديد الأحداث ذات القيمة الصفرية من system.events. تتطلب بعض أنظمة المراقبة تمرير جميع قيم المقاييس إليها عند كل نقطة تحقق، حتى إذا كانت قيمة المقياس صفرًا. القيم الممكنة:

0 — معطّل.
1 — مُمكّن.

أمثلة استعلام

SELECT * FROM system.events WHERE event='QueryMemoryLimitExceeded';

النتيجة

Ok.

استعلام

SET system_events_show_zero_values = 1;
SELECT * FROM system.events WHERE event='QueryMemoryLimitExceeded';

النتيجة

┌─event────────────────────┬─value─┬─description───────────────────────────────────────────┐
│ QueryMemoryLimitExceeded │     0 │ Number of times when memory limit exceeded for query. │
└──────────────────────────┴───────┴───────────────────────────────────────────────────────┘

system_metric_log_show_zero_values_in_histograms

يتحكم هذا الإعداد في ما إذا كانت بيانات المُدرَّج التكراري ذات القيمة الصفرية تُكتَب في العمود المتداخل histograms ضمن system.metric_log. افتراضياً، يتم تجاهل المُدرَّجات التكرارية التي يكون فيها إجمالي count للمشاهدات صفراً، وداخل كل مُدرَّج تكراري مكتوب، تُحذَف أيضاً إدخالات الحاويات التي لا تحتوي على أي مشاهدات من خريطة histogram. فعِّل هذا الخيار لكتابة كل مُدرَّج تكراري وكل حاوية بغضّ النظر عن العدد — وهو مفيد لأنظمة المراقبة التي تتطلب ظهور كل مقياس عند كل نقطة تحقق. القيم الممكنة:

0 — معطّل. لا تُكتَب المُدرَّجات التكرارية التي فيها count = 0؛ وتقتصر المُدرَّجات التكرارية المكتوبة على الحاويات التي استقبلت مشاهدة واحدة على الأقل.
1 — مفعّل. تُكتَب جميع المُدرَّجات التكرارية، وتظهر كل حدود الحاويات في histogram.

table_engine_read_through_distributed_cache

يسري هذا فقط في ClickHouse Cloud. يتيح القراءة من distributed cache عبر محركات الجداول / دوال الجداول (s3 وazure وما إلى ذلك)

table_function_remote_max_addresses

يعيّن الحد الأقصى لعدد العناوين المُنشأة من الأنماط للدالة remote. القيم الممكنة:

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

tcp_keep_alive_timeout

المدة بالثواني التي يجب أن يظل فيها الاتصال خاملًا قبل أن يبدأ TCP في إرسال حزم keepalive

temporary_data_in_cache_reserve_space_wait_lock_timeout_milliseconds

مدة الانتظار للحصول على قفل ذاكرة التخزين المؤقت عند حجز مساحة للبيانات المؤقتة في ذاكرة التخزين المؤقت لنظام الملفات

temporary_files_buffer_size

حجم المخزن المؤقت لعمليات كتابة الملفات المؤقتة. وكلما زاد حجم المخزن المؤقت، قلّ عدد استدعاءات النظام، لكنه يزيد من استهلاك الذاكرة.

temporary_files_codec

يحدّد خوارزمية الضغط للملفات المؤقتة المستخدمة في عمليات الفرز والربط على القرص. القيم الممكنة:

LZ4 — يُستخدم ضغط LZ4.
NONE — لا يُستخدم أي ضغط.

text_index_density_threshold

عتبة الكثافة لاختيار الخوارزمية في وضع قائمة النشر الكسولة. أقل من العتبة: تقاطع leapfrog. عند العتبة أو أعلى منها: bitmap بطريقة brute-force.

text_index_hint_max_selectivity

الحد الأقصى لانتقائية عامل التصفية لاستخدام التلميح المُنشأ من الفهرس النصي المعكوس.

text_index_like_max_postings_to_read

الحد الأقصى لعدد قوائم الإسناد الكبيرة التي يمكن قراءتها عند تفعيل تقييم LIKE للفهرس النصي باستخدام المسح بالقاموس. يتطلب تفعيل use_text_index_like_evaluation_by_dictionary_scan.

text_index_like_min_pattern_length

الحد الأدنى المطلوب لطول المقطع الأبجدي الرقمي المستهدَف في نمط LIKE/ILIKE لاستخدام تقييم LIKE للفهرس النصي عبر المسح بالقاموس. الأنماط الأقصر من هذه العتبة تطابق عددًا كبيرًا جدًا من رموز القاموس، لذلك يتم تخطيها لتجنّب عمليات الفحص المكلفة. يتطلب أن يكون use_text_index_like_evaluation_by_dictionary_scan مُمكّنًا.

text_index_posting_list_apply_mode

يتحكم في كيفية تطبيق قوائم النشر أثناء استعلامات الفهرس النصي. ‘materialize’ (الافتراضي) يفك ترميز قوائم النشر مباشرةً إلى Roaring Bitmaps. ‘lazy’ يستخدم فك ترميز عند الطلب يعتمد على المؤشر (يتطلب تنسيق الفهرس V2 و allow_experimental_text_index_lazy_apply).

throw_if_no_data_to_insert

يسمح بعمليات INSERT الفارغة أو يمنعها، وهو مفعّل افتراضيًا (ويُصدر خطأ عند تنفيذ INSERT فارغ). ينطبق هذا فقط على عمليات INSERT التي تستخدم clickhouse-client أو واجهة gRPC.

throw_on_error_from_cache_on_write_operations

تجاهل الخطأ الصادر من cache عند التخزين المؤقت أثناء عمليات الكتابة (INSERT، عمليات الدمج)

throw_on_max_partitions_per_insert_block

يتيح لك هذا الإعداد التحكم في السلوك عند بلوغ max_partitions_per_insert_block. القيم الممكنة:

true - عند بلوغ كتلة إدراج max_partitions_per_insert_block، يتم إطلاق استثناء.
false - يُسجَّل تحذير عند بلوغ max_partitions_per_insert_block.

قد يكون هذا مفيدًا إذا كنت تحاول فهم التأثير في المستخدمين عند تغيير max_partitions_per_insert_block.

throw_on_unsupported_query_inside_transaction

يُطرَح استثناء إذا استُخدِم استعلام غير مدعوم داخل معاملة

timeout_before_checking_execution_speed

يتحقق من أن سرعة التنفيذ ليست منخفضة جدًا (أي لا تقل عن min_execution_speed)، بعد انقضاء المدة المحددة بالثواني.

timeout_overflow_mode

يحدّد ما يجب فعله إذا استمر تنفيذ الاستعلام مدة أطول من max_execution_time أو كان الوقت المقدَّر للتنفيذ أطول من max_estimated_execution_time. القيم الممكنة:

throw: إثارة استثناء (الافتراضي).
break: إيقاف تنفيذ الاستعلام وإرجاع نتيجة جزئية، كما لو أن البيانات المصدر قد نفدت.

timeout_overflow_mode_leaf

يحدد ما يحدث عندما يستغرق الاستعلام على العقدة الطرفية وقتًا أطول من max_execution_time_leaf. القيم المحتملة:

throw: رفع استثناء (الافتراضي).
break: إيقاف تنفيذ الاستعلام وإرجاع النتيجة الجزئية، كما لو أن بيانات المصدر قد نفدت.

totals_auto_threshold

العتبة الخاصة بـ totals_mode = 'auto'. راجع قسم «مُعدِّل WITH TOTALS».

totals_mode

كيفية احتساب TOTALS عند وجود HAVING، وكذلك عند تعيين max_rows_to_group_by و group_by_overflow_mode = ‘any’. راجع قسم “المُعدِّل WITH TOTALS”.

trace_profile_events

يمكّن أو يعطّل جمع stacktraces عند كل تحديث لأحداث profile، مع اسم حدث profile وقيمة الزيادة، وإرسالها إلى trace_log. القيم الممكنة:

1 — تتبّع أحداث profile مُمكَّن.
0 — تتبّع أحداث profile مُعطَّل.

trace_profile_events_list

عند تمكين الإعداد trace_profile_events، تقتصر الأحداث التي يُتتبَّعها على قائمة الأسماء المحددة والمفصولة بفواصل. إذا كانت trace_profile_events_list سلسلة نصية فارغة (افتراضيًا)، فسيتم تتبُّع جميع أحداث profile. مثال على قيمة: ‘DiskS3ReadMicroseconds,DiskS3ReadRequestsCount,SelectQueryTimeMicroseconds,ReadBufferFromS3Bytes’ يتيح استخدام هذا الإعداد جمع البيانات بدقة أكبر لعدد كبير من الاستعلامات، لأن الكم الهائل من الأحداث قد يؤدي، بخلاف ذلك، إلى تجاوز سعة طابور سجل النظام الداخلي، مما يتسبب في إسقاط جزء منها.

transfer_overflow_mode

يحدد ما يحدث عندما تتجاوز كمية البيانات أحد الحدود. القيم الممكنة:

throw: إثارة استثناء (الافتراضي).
break: إيقاف تنفيذ الاستعلام وإرجاع نتيجة جزئية، كما لو أن بيانات المصدر قد نفدت.

transform_null_in

يتيح اعتبار قيم NULL متساوية في المعامل IN. بشكل افتراضي، لا يمكن مقارنة قيم NULL لأن NULL تعني قيمة غير معرّفة. لذلك، يجب أن تُرجع المقارنة expr = NULL دائمًا القيمة false. ومع هذا الإعداد، تُرجع NULL = NULL القيمة true في المعامل IN. القيم الممكنة:

0 — تُرجع مقارنة قيم NULL في المعامل IN القيمة false.
1 — تُرجع مقارنة قيم NULL في المعامل IN القيمة true.

مثال لنفترض وجود الجدول null_in:

┌──idx─┬─────i─┐
│    1 │     1 │
│    2 │  NULL │
│    3 │     3 │
└──────┴───────┘

استعلام:

SELECT idx, i FROM null_in WHERE i IN (1, NULL) SETTINGS transform_null_in = 0;

النتيجة:

┌──idx─┬────i─┐
│    1 │    1 │
└──────┴──────┘

استعلام:

SELECT idx, i FROM null_in WHERE i IN (1, NULL) SETTINGS transform_null_in = 1;

النتيجة:

┌──idx─┬─────i─┐
│    1 │     1 │
│    2 │  NULL │
└──────┴───────┘

راجع أيضًا

معالجة NULL في عوامل التشغيل IN

traverse_shadow_remote_data_paths

اعبر البيانات المجمّدة (دليل الظل) بالإضافة إلى بيانات الجدول الفعلية عند تنفيذ استعلام system.remote_data_paths

union_default_mode

يحدّد وضع دمج نتائج استعلام SELECT. لا يُستخدم هذا الإعداد إلا مع UNION عند عدم تحديد UNION ALL أو UNION DISTINCT صراحةً. القيم الممكنة:

'DISTINCT' — يعرض ClickHouse الصفوف الناتجة عن دمج الاستعلامات بعد إزالة الصفوف المكررة.
'ALL' — يعرض ClickHouse جميع الصفوف الناتجة عن دمج الاستعلامات، بما في ذلك الصفوف المكررة.
'' — ينشئ ClickHouse استثناءً عند استخدامه مع UNION.

راجع الأمثلة في UNION.

unique_key_max_encoded_size

الحد الأقصى للحجم (بالبايت) للترميز الثنائي الذي يحافظ على الترتيب لصف واحد من UNIQUE KEY.

unknown_packet_in_send_data

إرسال حزمة غير معروفة بدلًا من حزمة البيانات رقم N

update_parallel_mode

يحدّد سلوك استعلامات التحديث المتوازية. القيم الممكنة:

sync - شغّل جميع استعلامات UPDATE بشكل تسلسلي.
auto - شغّل بشكل تسلسلي فقط استعلامات UPDATE التي توجد بينها تبعيات بين الأعمدة المحدَّثة في أحد الاستعلامات والأعمدة المستخدمة في التعبيرات في استعلام آخر.
async - لا تُزامِن استعلامات التحديث.

update_sequential_consistency

إذا كانت القيمة true، تُحدَّث مجموعة الأجزاء إلى أحدث إصدار قبل تنفيذ عملية التحديث.

url_base

URL الأساسي المستخدم لحل عناوين URL النسبية في دالة الجدول url ومحرك الجدول URL. عند تعيينه، تُحل عناوين URL النسبية على النحو التالي:

عنوان URL نسبي إلى المسار (مثل data.csv): يُدمج مع مسار URL الأساسي وفقًا للمعيار RFC 3986. ويُستبدل كل ما يأتي بعد آخر / في المسار الأساسي بعنوان URL النسبي، لذا فإن الشرطة المائلة اللاحقة مهمة: https://example.com/dir/ + data.csv = https://example.com/dir/data.csv، لكن https://example.com/dir + data.csv = https://example.com/data.csv. وإذا لم يكن للعنوان الأساسي مسار (مثل https://example.com)، يُدرج /: https://example.com/data.csv. كما تُطبَّع المقاطع النقطية (./ و ../) في عنوان URL النسبي: https://example.com/dir/ + ../a.csv = https://example.com/a.csv.
عنوان URL نسبي إلى المضيف (مثل /test/data.csv): يُحل استنادًا إلى scheme والمضيف في URL الأساسي.
عنوان URL نسبي إلى scheme (مثل //other.com/test/data.csv): يُحل باستخدام scheme الخاص بـ URL الأساسي.
مرجع يتضمن query فقط (مثل ?x=1): يُلحق بمسار URL الأساسي (مع استبدال أي query/fragment موجود).
مرجع يتضمن fragment فقط (مثل #frag): يُلحق بـ URL الأساسي مع الاحتفاظ بأي query string موجود (مع استبدال أي fragment موجود).
مرجع فارغ: يعيد URL الأساسي بدون fragment.

على سبيل المثال، إذا كانت قيمة url_base هي https://example.com/def/، فسيكون الناتج كما يلي:

data.csv يُحل إلى https://example.com/def/data.csv
/test/data.csv يُحل إلى https://example.com/test/data.csv
//other.com/test/data.csv يُحل إلى https://other.com/test/data.csv

use_async_executor_for_materialized_views

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

use_cache_for_count_from_files

يُفعّل التخزين المؤقت لعدد الصفوف أثناء العدّ من الملفات في دوال الجداول file/s3/url/hdfs/azureBlobStorage. مُفعّل افتراضيًا.

use_client_time_zone

استخدم المنطقة الزمنية الخاصة بالعميل لتفسير قيم سلاسل DateTime، بدلًا من استخدام المنطقة الزمنية الخاصة بالخادم.

use_compact_format_in_distributed_parts_names

يستخدم التنسيق المضغوط لتخزين الكتل الخاصة بعمليات INSERT في الخلفية (distributed_foreground_insert) إلى الجداول التي تستخدم المحرك Distributed. القيم الممكنة:

0 — يستخدم تنسيق الدليل user[:password]@host:port#default_database.
1 — يستخدم تنسيق الدليل [shard{shard_index}[_replica{replica_index}]].

عند استخدام use_compact_format_in_distributed_parts_names=0، لن تُطبَّق التغييرات في تعريف العنقود على عمليات INSERT في الخلفية.
عند استخدام use_compact_format_in_distributed_parts_names=1، فإن تغيير ترتيب العقد في تعريف العنقود سيؤدي إلى تغيير shard_index/replica_index، لذا انتبه.

use_concurrency_control

يراعي التحكم في التزامن على الخادم (راجع إعدادات الخادم العامة concurrent_threads_soft_limit_num وconcurrent_threads_soft_limit_ratio_to_cores). وإذا كان معطّلًا، فسيتيح استخدام عدد أكبر من الخيوط حتى لو كان الخادم مثقلًا بالحمل (وهذا غير موصى به للاستخدام العادي، ويكون مطلوبًا غالبًا للاختبارات). القيمة الافتراضية في Cloud: 0.

use_hash_table_stats_for_join_reordering

تمكين استخدام إحصاءات جدول التجزئة المجمّعة لتقدير الكاردينالية أثناء إعادة ترتيب JOIN

use_hedged_requests

يُمكّن منطق الطلبات التحوطية للاستعلامات البعيدة. ويتيح إنشاء عدة اتصالات مع نُسخ متماثلة مختلفة للاستعلام. يُنشأ اتصال جديد إذا تعذّر إنشاء الاتصال الحالي مع النسخة المتماثلة خلال hedged_connection_timeout أو إذا لم يتم استلام أي بيانات خلال receive_data_timeout. يستخدم الاستعلام أول اتصال يرسل حزمة Progress غير فارغة (أو حزمة Data إذا كان allow_changing_replica_until_first_data_packet); وتُلغى الاتصالات الأخرى. الاستعلامات التي تستخدم max_parallel_replicas > 1 مدعومة. مُفعّل افتراضيًا. القيمة الافتراضية في Cloud: 0.

use_hive_partitioning

عند تمكينه، يكتشف ClickHouse التقسيم بنمط Hive في المسار (/name=value/) في محركات الجداول الشبيهة بالملفات File/S3/URL/HDFS/AzureBlobStorage، ويتيح استخدام أعمدة partition كأعمدة افتراضية في query. وتحمل هذه الأعمدة الافتراضية الأسماء نفسها الموجودة في المسار المُقسَّم، ولكنها تبدأ بـ _.

use_iceberg_metadata_files_cache

إذا كان هذا الإعداد مفعّلًا، فقد تستخدم دالة الجدول Iceberg ومحرك تخزين Iceberg ذاكرة التخزين المؤقت لملفات البيانات الوصفية لـ Iceberg. القيم الممكنة:

0 - معطّل
1 - مُمكّن

use_iceberg_partition_pruning

استخدم استبعاد التقسيمات في Iceberg مع جداول Iceberg

use_index_for_in_with_subqueries

حاوِل استخدام فهرس إذا وُجد استعلام فرعي أو تعبير table في الجانب الأيمن من المعامل IN.

use_index_for_in_with_subqueries_max_values

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

use_join_disjunctions_push_down

يُمكّن من دفع الأجزاء المرتبطة بعامل OR من شروط JOIN إلى جهات الإدخال المقابلة (“الدفع الجزئي”). يتيح ذلك لمحركات التخزين إجراء التصفية في مرحلة مبكرة، مما قد يقلل كمية البيانات المقروءة. هذا التحسين يحافظ على دلالات الاستعلام، ولا يُطبَّق إلا إذا كان كل فرع OR على المستوى الأعلى يوفّر عبارة شرطية حتمية واحدة على الأقل للجهة المستهدفة.

use_legacy_to_time

عند التمكين، يتيح هذا الإعداد استخدام الدالة القديمة toTime، التي تحوّل قيمة date with time إلى تاريخ ثابت محدد مع الحفاظ على الوقت. بخلاف ذلك، تُستخدم دالة toTime الجديدة، التي تحوّل أنواعًا مختلفة من البيانات إلى النوع Time. كما تظل الدالة القديمة متاحة دائمًا أيضًا باسم toTimeWithFixedDate.

use_lightweight_primary_key_index_analysis

تحسين تحليل فهرس المفتاح الأساسي لجداول MergeTree ذات المفاتيح الأساسية الطويلة. عند تمكين هذا الإعداد، يعتمد وقت تنفيذ تحليل الفهرس أساسًا على مدى تعقيد عامل التصفية في الاستعلام (أي أعمدة المفتاح التي يستخدمها فعليًا)، وليس على طول المفتاح الأساسي. لذلك، فإن توسيع مفتاح الفرز يضيف كلفة إضافية شبه معدومة إلى تحليل الفهرس في الاستعلامات التي تُجري التصفية على عدد قليل فقط من أعمدته. القيم الممكنة:

0 — معطّل. تُعالَج جميع أعمدة المفتاح الأساسي أثناء تحليل الفهرس.
1 — مفعّل.

use_page_cache_for_disks_without_file_cache

استخدم ذاكرة التخزين المؤقت للصفحات في حيّز المستخدم للأقراص البعيدة التي لا تكون فيها ذاكرة التخزين المؤقت لنظام الملفات مفعّلة.

use_page_cache_for_local_disks

استخدم ذاكرة التخزين المؤقت للصفحات في حيّز المستخدم عند القراءة من الأقراص المحلية. يُستخدم هذا للاختبار، ومن غير المرجح أن يُحسّن الأداء عمليًا. يتطلب local_filesystem_read_method = ‘pread’ أو ‘read’. لا يؤدي ذلك إلى تعطيل ذاكرة تخزين الصفحات المؤقتة لنظام التشغيل؛ ويمكن استخدام min_bytes_to_use_direct_io لهذا الغرض. يؤثر فقط على الجداول العادية، وليس على دالة الجدول file() أو محرك الجدول File().

use_page_cache_for_object_storage

استخدم ذاكرة التخزين المؤقت للصفحات في حيّز المستخدم عند القراءة من دوال الجداول الخاصة بتخزين الكائنات (s3, azure, hdfs) ومحركات الجداول (S3, Azure, HDFS).

use_page_cache_with_distributed_cache

استخدم ذاكرة التخزين المؤقت للصفحات في حيّز المستخدم عند استخدام distributed cache.

use_paimon_partition_pruning

استخدم استبعاد التقسيمات لأقسام Paimon لدوال جداول Paimon

use_parquet_metadata_cache

إذا كان هذا الإعداد مفعّلًا، فقد يستخدم تنسيق Parquet ذاكرة التخزين المؤقت للبيانات الوصفية لملفات Parquet. القيم الممكنة:

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

use_partition_pruning

الأسماء البديلة: use_partition_key استخدم مفتاح التقسيم لاستبعاد التقسيمات أثناء تنفيذ الاستعلام في جداول MergeTree. القيم الممكنة:

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

use_primary_key

استخدام المفتاح الأساسي لاستبعاد الحبيبات أثناء تنفيذ الاستعلام في جداول MergeTree. القيم الممكنة:

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

use_query_cache

إذا كان هذا الإعداد مفعّلًا، فقد تستخدم استعلامات SELECT ذاكرة التخزين المؤقت للاستعلامات. ويحدّد المعاملان enable_reads_from_query_cache وenable_writes_to_query_cache بمزيد من التفصيل كيفية استخدام ذاكرة التخزين المؤقت. القيم الممكنة:

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

use_query_condition_cache

يُفعّل ذاكرة التخزين المؤقت لشرط الاستعلام. تخزّن ذاكرة التخزين المؤقت نطاقات الحبيبات في أجزاء البيانات التي لا تستوفي الشرط في عبارة WHERE، وتُعيد استخدام هذه المعلومات كفهرس مؤقت للاستعلامات اللاحقة. القيم الممكنة:

0 - معطّل
1 - مُمكّن

use_reader_executor

تجريبي. وجّه عمليات القراءة عبر مسار المعالجة الجديد ReaderExecutor بدلًا من التعشيق القديم لمخازن القراءة المؤقتة. ويعود إلى المسار القديم في التكوينات التي لا يزال المنفّذ لا يدعمها.

use_roaring_bitmap_iceberg_positional_deletes

استخدم roaring bitmap لعمليات الحذف حسب الموضع في Iceberg.

use_skip_indexes

استخدام فهارس تخطي البيانات أثناء تنفيذ الاستعلامات. القيم الممكنة:

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

use_skip_indexes_for_disjunctions

يقيّم مرشحات WHERE التي تجمع بين شرطي AND وOR باستخدام فهارس التخطي. مثال: WHERE A = 5 AND (B = 5 OR C = 5). إذا كان هذا الإعداد معطّلًا، فستظل فهارس التخطي تُستخدم لتقييم الشروط في WHERE، ولكن يجب أن تتضمن فقط عبارات مربوطة بـ AND. القيم الممكنة:

0 — مُعطّل.
1 — مُمكّن.

use_skip_indexes_for_top_k

تمكين استخدام فهارس تخطي البيانات لتصفية TopK. عند التمكين، إذا كان هناك فهرس MinMax لتخطي البيانات على العمود في الاستعلام ORDER BY <column> LIMIT n، فسيحاول المُحسِّن استخدام فهرس MinMax لتخطي الـ حبيبات غير المرتبطة بالنتيجة النهائية. ويمكن أن يقلّل ذلك من زمن استجابة الاستعلام. القيم الممكنة:

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

use_skip_indexes_if_final

يتحكّم هذا الإعداد في ما إذا كانت فهارس التخطي تُستخدَم عند تنفيذ استعلام باستخدام المعدِّل FINAL. قد تستبعد فهارس التخطي صفوفًا (حبيبات) تحتوي على أحدث البيانات، ما قد يؤدي إلى نتائج غير صحيحة في استعلام يستخدم المعدِّل FINAL. عند تمكين هذا الإعداد، تُطبَّق فهارس التخطي حتى مع المعدِّل FINAL، مما قد يحسّن الأداء، ولكن مع احتمال تفويت التحديثات الأخيرة. ينبغي تمكين هذا الإعداد بالتزامن مع الإعداد use_skip_indexes_if_final_exact_mode (وهو مُمكَّن افتراضيًا). القيم الممكنة:

0 — مُعطَّل.
1 — مُمكَّن.

use_skip_indexes_if_final_exact_mode

يتحكم هذا الإعداد في ما إذا كانت الحبيبات التي يعيدها فهرس التخطي تُوسَّع في الأجزاء الأحدث لضمان إرجاع نتائج صحيحة عند تنفيذ استعلام باستخدام المُعدِّل FINAL. قد يؤدي استخدام فهارس التخطي إلى استبعاد الصفوف (الحبيبات) التي تحتوي على أحدث البيانات، مما قد يسبب نتائج غير صحيحة. ويمكن لهذا الإعداد ضمان إرجاع نتائج صحيحة من خلال فحص الأجزاء الأحدث المتداخلة مع النطاقات التي يعيدها فهرس التخطي. يجب تعطيل هذا الإعداد فقط إذا كانت النتائج التقريبية المستندة إلى البحث في فهرس التخطي مقبولة للتطبيق. القيم الممكنة:

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

use_skip_indexes_on_data_read

تمكين استخدام فهارس تخطي البيانات أثناء قراءة البيانات. عند التمكين، تُقيَّم فهارس التخطي ديناميكيًا عند قراءة كل granule من البيانات، بدلًا من تحليلها مسبقًا قبل بدء تنفيذ الاستعلام. يمكن أن يقلل ذلك من زمن بدء الاستعلام. القيم الممكنة:

0 — معطّل.
1 — مُمكّن.

use_statistics

/// يُفضَّل على ‘allow_statistics_optimize’ حفاظًا على الاتساق مع ‘use_primary_key’ و ‘use_skip_indexes’ يسمح باستخدام الإحصاءات لتحسين الاستعلامات

use_statistics_cache

استخدم ذاكرة التخزين المؤقت للإحصاءات في الاستعلام لتجنّب العبء الإضافي الناتج عن تحميل إحصاءات جميع الأجزاء

use_statistics_for_part_pruning

استخدام الإحصاءات لاستبعاد الأجزاء أثناء تنفيذ الاستعلام. عند التمكين، سيعتمد استبعاد الأجزاء في استعلامات SELECT على إحصاءات الأعمدة (مثل إحصاءات MinMax) لاستبعاد الأجزاء التي لا يمكن أن تحتوي على بيانات مطابقة قبل قراءة أي بيانات. القيم الممكنة:

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

use_strict_insert_block_limits

عند التمكين، يفرض هذا الإعداد بدقة حدَّي الحجم الأدنى والأقصى لكتلة الإدراج. يتم إصدار كتلة عندما:

الحدود الدنيا (AND): يتم بلوغ كلٍّ من min_insert_block_size_rows و min_insert_block_size_bytes.
الحدود القصوى (OR): يتم بلوغ أيٍّ من max_insert_block_size_rows أو max_insert_block_size_bytes.

عند التعطيل، يتم إصدار كتلة عندما:

الحدود الدنيا (OR): يتم بلوغ min_insert_block_size_rows أو min_insert_block_size_bytes.

ملاحظة: إذا كانت إعدادات max أصغر من إعدادات min، فستكون للحدود القصوى الأولوية، وستُصدَر الكتل قبل بلوغ الحدود الدنيا. ملاحظة: يُعطَّل هذا الإعداد تلقائيًا لعمليات async inserts، لأن async inserts تُرفِق tokens لإزالة التكرار لكل entry، وهو ما لا يتوافق مع تقسيم الكتل المطلوب لفرض الحدود الصارمة. مُعطَّل افتراضيًا.

use_structure_from_insertion_table_in_table_functions

استخدم البنية المستمدة من جدول الإدراج بدلًا من استنتاج المخطط من البيانات. القيم الممكنة: 0 - معطّل، 1 - مُمكّن، 2 - تلقائي

use_text_index_header_cache

ما إذا كان سيتم استخدام ذاكرة تخزين مؤقتة لترويسة الفهرس النصي بعد فك تسلسلها. يمكن أن يؤدي استخدام ذاكرة التخزين المؤقتة لترويسة الفهرس النصي إلى تقليل زمن الاستجابة بشكل كبير وزيادة معدل النقل عند العمل مع عدد كبير من استعلامات الفهرس النصي.

use_text_index_like_evaluation_by_dictionary_scan

تمكين تقييم استعلامات LIKE/ILIKE عبر فحص قاموس الفهرس النصي المعكوس.

use_text_index_postings_cache

ما إذا كان يجب استخدام ذاكرة تخزين مؤقت لقوائم النشر الخاصة بالفهرس النصي بعد فك تسلسلها. يمكن أن يؤدي استخدام ذاكرة التخزين المؤقت لقوائم النشر الخاصة بالفهرس النصي إلى تقليل زمن الاستجابة بشكل كبير وزيادة معدل النقل عند العمل مع عدد كبير من استعلامات الفهرس النصي.

use_text_index_tokens_cache

ما إذا كان سيتم استخدام ذاكرة تخزين مؤقت لبيانات تعريف رموز الفهرس النصي بعد فك التسلسل. يمكن أن يؤدي استخدام ذاكرة التخزين المؤقت لرموز الفهرس النصي إلى تقليل زمن الاستجابة بشكل كبير وزيادة معدل النقل عند التعامل مع عدد كبير من استعلامات الفهرس النصي.

use_top_k_dynamic_filtering

يُمكّن تحسين التصفية الديناميكية عند تنفيذ استعلام ORDER BY <column> LIMIT n. عند تمكينه، سيحاول منفّذ الاستعلام تخطي الحبيبات والصفوف التي لن تكون ضمن صفوف top N النهائية في مجموعة النتائج. هذا التحسين ديناميكي بطبيعته، وتعتمد تحسينات زمن الاستجابة على توزيع البيانات ووجود شروط ترشيح أخرى في الاستعلام. القيم الممكنة:

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

use_top_k_dynamic_filtering_for_variable_length_types

يسمح لـ use_top_k_dynamic_filtering بالتطبيق عندما يكون عمود الفرز من نوع بيانات متغير الطول (مثل String وArray وMap وTuple الذي يحتوي على عناصر متغيرة الطول). في هذه الأنواع، قد تفوق تكلفة مقارنة العتبة لكل صف، التي ينفذها المرشح الديناميكي، مقدار التوفير الذي يحققه عندما تكون القيمة الدنيا المعجمية للعمود هي السائدة (مثل السلاسل الفارغة في معظم الحالات) ولا يمكن تخطي سوى عدد قليل من الحبيبات. في هذه الحالة، تسيء التصفية الديناميكية إلى زمن استجابة الاستعلام بدلًا من تحسينه. عندما تكون قيمة هذا الإعداد 0، يقتصر التصفية الديناميكية على الأعمدة التي تكون لقيمها سعة قصوى ثابتة في الذاكرة (الأعداد، وDate، وDateTime، وFixedString، وEnum، وNullable لهذه الأنواع، وTuple لهذه الأنواع). وعند ضبطه على 1، يُطبَّق التصفية الديناميكية على الأنواع متغيرة الطول أيضًا. القيم الممكنة:

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

use_uncompressed_cache

ما إذا كان سيتم استخدام ذاكرة التخزين المؤقت للكتل غير المضغوطة. يقبل 0 أو 1. القيمة الافتراضية هي 0 (مُعطّل). يمكن أن يؤدي استخدام ذاكرة التخزين المؤقت غير المضغوطة (فقط للجداول في عائلة MergeTree) إلى تقليل زمن الاستجابة بشكل كبير وزيادة معدل النقل عند العمل مع عدد كبير من الاستعلامات القصيرة. فعِّل هذا الإعداد للمستخدمين الذين يرسلون طلبات قصيرة ومتكررة. انتبه أيضًا إلى مَعلمة التهيئة uncompressed_cache_size (تُضبط فقط في ملف الإعدادات) — وهي حجم كتل ذاكرة التخزين المؤقت غير المضغوطة. تبلغ قيمتها الافتراضية 8 GiB. وتُملأ ذاكرة التخزين المؤقت غير المضغوطة حسب الحاجة، كما تُحذف تلقائيًا البيانات الأقل استخدامًا. بالنسبة إلى الاستعلامات التي تقرأ حجمًا كبيرًا نسبيًا من البيانات (مليون صف أو أكثر)، تُعطَّل ذاكرة التخزين المؤقت غير المضغوطة تلقائيًا لتوفير المساحة للاستعلامات الصغيرة فعلًا. وهذا يعني أنه يمكنك إبقاء الإعداد ‘use_uncompressed_cache’ مضبوطًا دائمًا على 1.

use_variant_as_common_type

يسمح باستخدام النوع Variant كنوع ناتج لدوال if/multiIf/array/map عندما لا يوجد نوع مشترك لأنواع الوسائط. مثال:

SET use_variant_as_common_type = 1;
SELECT toTypeName(if(number % 2, number, range(number))) as variant_type FROM numbers(1);
SELECT if(number % 2, number, range(number)) as variant FROM numbers(5);

┌─variant_type───────────────────┐
│ Variant(Array(UInt64), UInt64) │
└────────────────────────────────┘
┌─variant───┐
│ []        │
│ 1         │
│ [0,1]     │
│ 3         │
│ [0,1,2,3] │
└───────────┘

SET use_variant_as_common_type = 1;
SELECT toTypeName(multiIf((number % 4) = 0, 42, (number % 4) = 1, [1, 2, 3], (number % 4) = 2, 'Hello, World!', NULL)) AS variant_type FROM numbers(1);
SELECT multiIf((number % 4) = 0, 42, (number % 4) = 1, [1, 2, 3], (number % 4) = 2, 'Hello, World!', NULL) AS variant FROM numbers(4);

─variant_type─────────────────────────┐
│ Variant(Array(UInt8), String, UInt8) │
└──────────────────────────────────────┘

┌─variant───────┐
│ 42            │
│ [1,2,3]       │
│ Hello, World! │
│ ᴺᵁᴸᴸ          │
└───────────────┘

SET use_variant_as_common_type = 1;
SELECT toTypeName(array(range(number), number, 'str_' || toString(number))) as array_of_variants_type from numbers(1);
SELECT array(range(number), number, 'str_' || toString(number)) as array_of_variants FROM numbers(3);

┌─array_of_variants_type────────────────────────┐
│ Array(Variant(Array(UInt64), String, UInt64)) │
└───────────────────────────────────────────────┘

┌─array_of_variants─┐
│ [[],0,'str_0']    │
│ [[0],1,'str_1']   │
│ [[0,1],2,'str_2'] │
└───────────────────┘

SET use_variant_as_common_type = 1;
SELECT toTypeName(map('a', range(number), 'b', number, 'c', 'str_' || toString(number))) as map_of_variants_type from numbers(1);
SELECT map('a', range(number), 'b', number, 'c', 'str_' || toString(number)) as map_of_variants FROM numbers(3);

┌─map_of_variants_type────────────────────────────────┐
│ Map(String, Variant(Array(UInt64), String, UInt64)) │
└─────────────────────────────────────────────────────┘

┌─map_of_variants───────────────┐
│ {'a':[],'b':0,'c':'str_0'}    │
│ {'a':[0],'b':1,'c':'str_1'}   │
│ {'a':[0,1],'b':2,'c':'str_2'} │
└───────────────────────────────┘

use_variant_default_implementation_for_comparisons

يُمكّن أو يعطّل التنفيذ الافتراضي للنوع Variant في دوال المقارنة.

use_with_fill_by_sorting_prefix

الأعمدة التي تسبق أعمدة WITH FILL في جملة ORDER BY تُشكّل بادئة الفرز. وتُملأ الصفوف ذات القيم المختلفة في بادئة الفرز بشكل مستقل

validate_enum_literals_in_operators

إذا كان مفعّلًا، يتم التحقق من القيم الحرفية لـ enum في عوامل التشغيل مثل IN وNOT IN و== و!= مقابل نوع enum، ويُطرح استثناء إذا لم تكن القيمة الحرفية قيمة enum صالحة.

validate_mutation_query

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

validate_polygons

يُمكّن أو يعطّل إلقاء استثناء في الدالة pointInPolygon إذا كان المضلع متقاطعًا مع نفسه أو مماسًا لنفسه. القيم الممكنة:

0 — إلقاء الاستثناء معطّل. تقبل pointInPolygon المضلعات غير الصالحة وتُرجع لها نتائج قد تكون غير صحيحة.
1 — إلقاء الاستثناء مفعّل.

variant_throw_on_type_mismatch

عند تطبيق دالة على عمود Variant باستخدام آلية التنفيذ الافتراضية، يحدّد هذا الإعداد ما يحدث للصفوف التي يكون نوعها الفعلي غير متوافق مع الدالة:

true (الافتراضي) — إثارة استثناء.
false — إرجاع NULL لهذه الصفوف بدلاً من ذلك.

vector_search_filter_strategy

إذا كان استعلام vector search يتضمن عبارة WHERE، فإن هذا الإعداد يحدد ما إذا كان سيتم تقييمها أولًا (pre-filtering) أو ما إذا كان سيتم التحقق من vector similarity index أولًا (post-filtering). القيم الممكنة:

‘auto’ - post-filtering (قد تتغير الدلالات الدقيقة في المستقبل).
‘postfilter’ - استخدم vector similarity index لتحديد أقرب الجيران، ثم طبّق المرشحات الأخرى
‘prefilter’ - قيّم المرشحات الأخرى أولًا، ثم نفّذ بحث brute-force لتحديد الجيران.

vector_search_index_fetch_multiplier

الأسماء البديلة: vector_search_postfilter_multiplier يُضرَب عدد أقرب الجيران المُجلَبين من فهرس تشابه المتجهات في هذا الرقم. لا يُطبَّق هذا إلا عند التصفية اللاحقة مع predicates أخرى، أو إذا كان الإعداد ‘vector_search_with_rescoring = 1’.

vector_search_with_rescoring

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

وضع_انتظار_ظهور_التغييرات_بعد_الالتزام

انتظر حتى تصبح التغييرات المُلتزَم بها مرئية فعليًا في أحدث لقطة

wait_for_async_insert

إذا كانت القيمة true، فانتظر معالجة الإدراج غير المتزامن

wait_for_async_insert_timeout

مهلة الانتظار لمعالجة عملية الإدراج غير المتزامن

wait_for_part_commit_in_dependent_materialized_views

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

wait_for_window_view_fire_signal_timeout

مهلة انتظار إشارة إطلاق window view أثناء معالجة وقت الحدث

webassembly_udf_max_fuel

حدّ الوقود لكل عملية تنفيذ لمثيل WebAssembly UDF. تستهلك كل تعليمة WebAssembly قدرًا من الوقود. تُضرب القيمة في 1024 قبل تمريرها إلى بيئة التشغيل، لذا فإن webassembly_udf_max_fuel = 1 يعادل تقريبًا 1024 وحدة وقود. اضبطها على 0 لإلغاء أي حدّ. ينطبق ذلك فقط على الدوال التي يكون فيها الإعداد الخاص بكل دالة webassembly_udf_enable_fuel مضبوطًا على true، وهي القيمة الافتراضية.

webassembly_udf_max_input_block_size

الحد الأقصى لعدد الصفوف التي يتم تمريرها إلى WebAssembly UDF ضمن كتلة واحدة. اضبطه على 0 لمعالجة جميع الصفوف دفعة واحدة.

webassembly_udf_max_instances

الحد الأقصى لعدد مثيلات WebAssembly UDF التي يمكن تشغيلها بالتوازي لكل دالة.

webassembly_udf_max_memory

حد الذاكرة بالبايت لكل مثيل من WebAssembly UDF.

window_view_clean_interval

الفاصل الزمني لتنظيف window view، بالثواني، لتحرير البيانات القديمة.

window_view_heartbeat_interval

الفاصل الزمني لنبضات الحياة، بالثواني، للإشارة إلى أن استعلام watch ما يزال قيد التشغيل.

workload

اسم workload المُستخدم للوصول إلى الموارد

write_full_path_in_iceberg_metadata

يكتب المسارات الكاملة (بما في ذلك s3://) في ملفات البيانات الوصفية لـ Iceberg.

write_through_distributed_cache

لا يكون لهذا الإعداد تأثير إلا في ClickHouse Cloud. يتيح الكتابة إلى distributed cache (كما ستتولى distributed cache أيضًا الكتابة إلى S3)

write_through_distributed_cache_buffer_size

لا يسري هذا إلا في ClickHouse Cloud. يحدد حجم المخزن المؤقت لآلية write-through في distributed cache. إذا كانت القيمة 0، فسيُستخدم حجم المخزن المؤقت الذي كان سيُستخدم في حال عدم وجود distributed cache.

zstd_window_log_max

يسمح بتحديد الحد الأقصى لـ window log في ZSTD (لن يُستخدم مع عائلة MergeTree)

آخر تعديل في ٢٩ يونيو ٢٠٢٦

إعدادات جداول MergeTreeإعدادات MergeTree في `system.merge_tree_settings`

​add_http_cors_header

​additional_result_filter

​additional_table_filters

​aggregate_function_input_format

​aggregate_functions_null_for_empty

​aggregation_in_order_max_block_bytes

​aggregation_memory_efficient_merge_threads

​ai_function_credentials

​ai_function_embedding_max_batch_size

​ai_function_max_api_calls_per_query

​ai_function_max_input_tokens_per_query

​ai_function_max_output_tokens_per_query

​ai_function_max_retries

​ai_function_request_timeout_sec

​ai_function_retry_initial_delay_ms

​ai_function_throw_on_error

​ai_function_throw_on_quota_exceeded

​allow_aggregate_partitions_independently

​allow_archive_path_syntax

​allow_asynchronous_read_from_io_pool_for_merge_tree

​allow_calculating_subcolumns_sizes_for_merge_tree_reading

​allow_changing_replica_until_first_data_packet

​allow_create_index_without_type

​allow_custom_error_code_in_throwif

​allow_ddl

​allow_deprecated_database_ordinary

​allow_deprecated_error_prone_window_functions

​allow_deprecated_snowflake_conversion_functions

​allow_deprecated_syntax_for_merge_tree

​allow_distributed_ddl

​allow_drop_detached

​allow_dynamic_type_in_join_keys

​allow_execute_multiif_columnar

​allow_experimental_ai_functions

​allow_experimental_analyzer

​allow_experimental_cleanup_old_data_files_compaction

​allow_experimental_codecs

​allow_experimental_correlated_subqueries

​allow_experimental_database_glue_catalog

​allow_experimental_database_hms_catalog

​allow_experimental_database_iceberg

​allow_experimental_database_materialized_postgresql

​allow_experimental_database_paimon_rest_catalog

​allow_experimental_database_unity_catalog

​allow_experimental_delta_kernel_rs

​allow_experimental_delta_lake_writes

​allow_experimental_expire_snapshots

​allow_experimental_funnel_functions

​allow_experimental_geo_types_in_iceberg

​allow_experimental_hash_functions

​allow_experimental_iceberg_compaction

​allow_experimental_join_right_table_sorting

​allow_experimental_json_lazy_type_hints

​allow_experimental_kafka_offsets_storage_in_keeper

​allow_experimental_kusto_dialect

​allow_experimental_materialized_postgresql_table

​allow_experimental_nlp_functions

​allow_experimental_nullable_tuple_type

​allow_experimental_object_storage_queue_hive_partitioning

​allow_experimental_paimon_storage_engine

​allow_experimental_parallel_reading_from_replicas

​allow_experimental_polyglot_dialect

​allow_experimental_prql_dialect

​allow_experimental_text_index_lazy_apply

​allow_experimental_time_series_aggregate_functions

​allow_experimental_time_series_table

​allow_experimental_unique_key

​allow_experimental_window_view

​allow_experimental_ytsaurus_dictionary_source

​allow_experimental_ytsaurus_table_engine

​allow_experimental_ytsaurus_table_function

​allow_fuzz_query_functions

​allow_general_join_planning

​allow_get_client_http_header

​allow_hyperscan

​allow_iceberg_remove_orphan_files

​allow_insert_into_iceberg

​allow_introspection_functions

​allow_key_condition_coalesce_rewrite

​allow_limit_by_partitions_independently

add_http_cors_header

additional_result_filter

additional_table_filters

aggregate_function_input_format

aggregate_functions_null_for_empty

aggregation_in_order_max_block_bytes

aggregation_memory_efficient_merge_threads

ai_function_credentials

ai_function_embedding_max_batch_size

ai_function_max_api_calls_per_query

ai_function_max_input_tokens_per_query

ai_function_max_output_tokens_per_query

ai_function_max_retries

ai_function_request_timeout_sec

ai_function_retry_initial_delay_ms

ai_function_throw_on_error

ai_function_throw_on_quota_exceeded

allow_aggregate_partitions_independently

allow_archive_path_syntax

allow_asynchronous_read_from_io_pool_for_merge_tree

allow_calculating_subcolumns_sizes_for_merge_tree_reading

allow_changing_replica_until_first_data_packet

allow_create_index_without_type

allow_custom_error_code_in_throwif

allow_ddl

allow_deprecated_database_ordinary

allow_deprecated_error_prone_window_functions

allow_deprecated_snowflake_conversion_functions

allow_deprecated_syntax_for_merge_tree

allow_distributed_ddl

allow_drop_detached

allow_dynamic_type_in_join_keys

allow_execute_multiif_columnar

allow_experimental_ai_functions

allow_experimental_analyzer

allow_experimental_cleanup_old_data_files_compaction

allow_experimental_codecs

allow_experimental_correlated_subqueries

allow_experimental_database_glue_catalog

allow_experimental_database_hms_catalog

allow_experimental_database_iceberg

allow_experimental_database_materialized_postgresql

allow_experimental_database_paimon_rest_catalog

allow_experimental_database_unity_catalog

allow_experimental_delta_kernel_rs

allow_experimental_delta_lake_writes

allow_experimental_expire_snapshots

allow_experimental_funnel_functions

allow_experimental_geo_types_in_iceberg

allow_experimental_hash_functions

allow_experimental_iceberg_compaction

allow_experimental_join_right_table_sorting

allow_experimental_json_lazy_type_hints

allow_experimental_kafka_offsets_storage_in_keeper

allow_experimental_kusto_dialect

allow_experimental_materialized_postgresql_table

allow_experimental_nlp_functions

allow_experimental_nullable_tuple_type

allow_experimental_object_storage_queue_hive_partitioning

allow_experimental_paimon_storage_engine

allow_experimental_parallel_reading_from_replicas

allow_experimental_polyglot_dialect

allow_experimental_prql_dialect

allow_experimental_text_index_lazy_apply

allow_experimental_time_series_aggregate_functions

allow_experimental_time_series_table

allow_experimental_unique_key

allow_experimental_window_view

allow_experimental_ytsaurus_dictionary_source

allow_experimental_ytsaurus_table_engine

allow_experimental_ytsaurus_table_function

allow_fuzz_query_functions

allow_general_join_planning

allow_get_client_http_header

allow_hyperscan

allow_iceberg_remove_orphan_files

allow_insert_into_iceberg

allow_introspection_functions

allow_key_condition_coalesce_rewrite

allow_limit_by_partitions_independently