ClickHouse/docs/ru/operations/settings/merge-tree-settings.md

Настройки MergeTree таблиц

Значения настроек для всех MergeTree таблиц можно посмотреть в таблице system.merge_tree_settings, их можно переопределить в config.xml в секции merge_tree, или задать в секции SETTINGS у каждой таблицы.

Пример переопределения в config.xml:

<merge_tree>
    <max_suspicious_broken_parts>5</max_suspicious_broken_parts>
</merge_tree>

Пример для определения в SETTINGS у конкретной таблицы:

CREATE TABLE foo
(
    `A` Int64
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS max_suspicious_broken_parts = 500;

Пример изменения настроек у конкретной таблицы командой ALTER TABLE ... MODIFY SETTING:

ALTER TABLE foo
    MODIFY SETTING max_suspicious_broken_parts = 100;

parts_to_throw_insert

Eсли число кусков в партиции превышает значение parts_to_throw_insert, INSERT прерывается с исключением Too many parts (N). Merges are processing significantly slower than inserts.

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

• Положительное целое число.

Значение по умолчанию: 300.

Для достижения максимальной производительности запросов SELECT необходимо минимизировать количество обрабатываемых кусков, см. Дизайн MergeTree.

Можно установить большее значение 600 (1200), это уменьшит вероятность возникновения ошибки Too many parts, но в тоже время вы позже обнаружите возможную проблему со слияниями (например, из-за недостатка места на диске) и деградацию производительности SELECT.

parts_to_delay_insert

Eсли число кусков в партиции превышает значение parts_to_delay_insert, INSERT искусственно замедляется.

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

• Положительное целое число.

Значение по умолчанию: 150.

ClickHouse искусственно выполняет INSERT дольше (добавляет ‘sleep’), чтобы фоновый механизм слияния успевал слиять куски быстрее, чем они добавляются.

max_delay_to_insert

Величина в секундах, которая используется для расчета задержки INSERT, если число кусков в партиции превышает значение parts_to_delay_insert.

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

• Положительное целое число.

Значение по умолчанию: 1.

Величина задержки (в миллисекундах) для INSERT вычисляется по формуле:

max_k = parts_to_throw_insert - parts_to_delay_insert
k = 1 + parts_count_in_partition - parts_to_delay_insert
delay_milliseconds = pow(max_delay_to_insert * 1000, k / max_k)

Т.е. если в партиции уже 299 кусков и parts_to_throw_insert = 300, parts_to_delay_insert = 150, max_delay_to_insert = 1, INSERT замедлится на pow( 1 * 1000, (1 + 299 - 150) / (300 - 150) ) = 1000 миллисекунд.

max_parts_in_total

Eсли суммарное число активных кусков во всех партициях таблицы превышает значение max_parts_in_total, INSERT прерывается с исключением Too many parts (N).

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

• Положительное целое число.

Значение по умолчанию: 100000.

Большое число кусков в таблице снижает производительность запросов ClickHouse и увеличивает время старта ClickHouse. Чаще всего это следствие неправильного дизайна (ошибки при выборе стратегии партиционирования -- слишком мелкие партиции).

replicated_deduplication_window

Количество хеш-сумм последних вставленных блоков, хранящихся в Zookeeper.

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

• Положительное целое число.

Значение по умолчанию: 100.

Команда Insert создает один или несколько блоков (кусков). При вставке в Replicated таблицы ClickHouse для дедупликации вставок записывает в Zookeeper хеш-суммы созданных кусков. Но хранятся хеш-суммы не всех кусков, а только последние replicated_deduplication_window. Наиболее старые хеш-суммы удаляются из Zookeeper. Большое число replicated_deduplication_window замедляет Insert-ы. Хеш-сумма рассчитывается от композиции имен и типов полей, а также данных вставленного куска (потока байт).

replicated_deduplication_window_seconds

Число секунд, после которых хеш-суммы вставленных блоков удаляются из Zookeeper.

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

• Положительное целое число.

Значение по умолчанию: 604800 (1 неделя).

Аналогично replicated_deduplication_window, задает, сколько времени хранить хеш-суммы блоков для дедупликции Insert-в. Хеш-суммы старше replicated_deduplication_window_seconds удаляются из Zookeeper, даже если их меньше чем replicated_deduplication_window.

old_parts_lifetime

Время (в секундах) хранения неактивных кусков, для защиты от потери данных при спонтанной перезагрузке сервера или О.С.

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

• Положительное целое число.

Значение по умолчанию: 480.

После слияния нескольких кусков в новый кусок, ClickHouse помечает исходные куски как неактивные и удаляет их после old_parts_lifetime секунд. Неактивные куски удаляются, если они не используются в текущих запросах, т.е. если счетчик ссылок куска – refcount равен нулю.

Неактивные куски удаляются не сразу, потому что при записи нового куска не вызывается fsync, т.е. некоторое время новый кусок находится только в оперативной памяти сервера (кеше О.С.). Т.о. при спонтанной перезагрузке сервера новый (смерженный) кусок может быть потерян или испорчен. В этом случае ClickHouse в процессе старта при проверке целостности кусков обнаружит проблему, вернет неактивные куски в список активных и позже заново их смержит. Сломанный кусок в этом случае переименовывается (добавляется префикс broken_) и перемещается в папку detached. Если проверка целостности не обнаруживает проблем в смерженном куске, то исходные неактивные куски переименовываются (добавляется префикс ignored_) и перемещаются в папку detached.

Стандартное значение Linux dirty_expire_centisecs - 30 секунд (максимальное время, которое записанные данные хранятся только в оперативной памяти), но при больших нагрузках на дисковую систему, данные могут быть записаны намного позже. Экспериментально было найдено время - 480 секунд, за которое гарантированно новый кусок будет записан на диск.

max_bytes_to_merge_at_max_space_in_pool

Максимальный суммарный размер кусков (в байтах) в одном слиянии, при наличии свободных ресурсов в фоновом пуле. max_bytes_to_merge_at_max_space_in_pool -- примерно соответствует максимально возможному размеру куска, созданного автоматическим фоновым слиянием.

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

• Положительное целое число.

Значение по умолчанию: 161061273600 (150ГБ).

Планировщик мержей периодически анализирует размер и количество кусков в партициях, и при достаточном количестве свободных ресурсов в фоновом пуле начинает фоновое слияние. Слияния происходят до тех пор, пока суммарный размер входных кусков не достигнет max_bytes_to_merge_at_max_space_in_pool.

Слияния, инициированные optimize final, не учитывают max_bytes_to_merge_at_max_space_in_pool и размеры кусков и слияют куски только с учетом наличия ресурсов в фоновом пуле, пока не останется один кусок в партиции.

max_bytes_to_merge_at_min_space_in_pool

Максимальный суммарный размер кусков (в байтах) в одном слиянии, при минимальных свободных ресурсах в фоновом пуле.

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

• Положительное целое число.

Значение по умолчанию: 1048576

max_bytes_to_merge_at_min_space_in_pool задает максимальный суммарный размер кусков, для которых можно начать слияние, несмотря на недостаток свободных ресурсов в фоновом пуле (дискового пространства). Это необходимо, чтобы уменьшить количество маленьких кусков и вероятность ошибки Too many parts. Слияния резервируют дисковое пространство, удваивая суммарный размер кусков в слиянии. Таким образом, при малом количестве свободного места на диске может сложится ситуация, что свободное место есть, но оно уже зарезервировано идущими слиянияними, поэтому другие слияния не могут начаться, и количество маленьких кусков в партиции растет с каждым инсертом.

merge_max_block_size

Количество строк в блоках, которые читаются из слияемых кусков.

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

• Положительное целое число.

Значение по умолчанию: 8192

Слияние читает строки из кусков блоками по merge_max_block_size строк, производит слияние и пишет результат в новый кусок. Читаемый блок помещается в оперативную память, т.е. merge_max_block_size влияет на размер оперативной памяти, необходимой для слияния. Таким образом, слияния могут потреблять большое количество оперативной памяти для таблиц, хранящих очень большие строки (если средний размер строки 100кб, то при слиянии 10 кусков будет использовано (100кб * 10 * 8192) =~ 8ГБ ОЗУ). Уменьшив merge_max_block_size, можно сократить размер оперативной памяти, необходимой для слияния.

max_part_loading_threads

Максимальное количество потоков, которые читают куски при старте ClickHouse.

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

• Положительное целое число.

Значение по умолчанию: auto (количество ядер процессора).

При старте ClickHouse читает все куски всех таблиц (читает файлы с метаданными кусков), чтобы построить в ОЗУ список всех кусков. В некоторых системах с большим количеством кусков этот процесс может занимать длительное время, и это время можно сократить, увеличив max_part_loading_threads (если при этом процессе есть недозагруженность CPU и диска).

{## Оригинальная статья ##}