Настройки сервера use_*

Эти настройки настраивают сервер ClickHouse и автоматически сгенерированы на основе исходного кода ClickHouse.

Метод хранения заголовков частей данных в ZooKeeper. Эта настройка применяется только к семейству MergeTree. Ее можно указать:

Глобально в разделе merge_tree файла config.xml

ClickHouse использует эту настройку для всех таблиц на сервере. Вы можете изменить настройку в любой момент. При изменении настройки существующие таблицы меняют свое поведение.

Для каждой таблицы

При создании таблицы укажите соответствующую настройку движка. Поведение существующей таблицы с этой настройкой не меняется, даже если глобальная настройка изменится.

Возможные значения

• 0 — Функциональность отключена.
• 1 — Функциональность включена.

Если use_minimalistic_part_header_in_zookeeper = 1, то реплицируемые таблицы хранят заголовки частей данных в компактном виде, используя один znode. Если таблица содержит много столбцов, такой способ хранения значительно уменьшает объем данных, хранящихся в ZooKeeper.

Включает отдельную arena jemalloc для выделения памяти под кэш (mark cache, кэш несжатых данных, page cache). Изолирует данные кэша от выделений памяти при обработке запросов, уменьшая фрагментацию памяти.

Доступно только в ClickHouse Cloud. Если параметр включен, таблицы system.*_log работают на SharedMergeTree через конвейер на базе S3. Для каждого журнала <log> при запуске автоматически создаются следующие объекты:

• system.<log>_s3 — таблица на базе S3, которая служит прямой целью для flush; каждый вызов SYSTEM FLUSH LOGS записывает сюда новый файл с партициями.
• system.<log>_s3queue — таблица S3Queue (ordered mode), которая подхватывает файлы из <log>_s3 и передает строки дальше по конвейеру. Каждый узел обрабатывает только свои файлы через партиционирование на основе partition_regex.
• system.<log>_mv — MATERIALIZED VIEW, которое направляет строки из <log>_s3queue в итоговую таблицу SharedMergeTree.
• system.<log> — итоговая таблица SharedMergeTree, в которой накапливаются строки и к которой выполняются запросы.

При изменении схемы или настроек затронутая таблица переименовывается в <log>_0, <log>_1 и т. д. и создается заново — в соответствии с текущим поведением ротации SystemLog.

Требуется, чтобы в конфигурации сервера был задан <shared_log_pipeline><endpoint>. См. также: shared_log_pipeline.enable_sync_flush, shared_log_pipeline.flush_timeout_seconds.