mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-15 03:53:41 +00:00
185 lines
15 KiB
Markdown
185 lines
15 KiB
Markdown
# Настройки MergeTree таблиц {#merge-tree-settings}
|
||
|
||
Значения настроек для всех MergeTree таблиц можно посмотреть в таблице `system.merge_tree_settings`, их можно переопределить в `config.xml` в секции `merge_tree`, или задать в секции `SETTINGS` у каждой таблицы.
|
||
|
||
Пример переопределения в `config.xml`:
|
||
|
||
``` text
|
||
<merge_tree>
|
||
<max_suspicious_broken_parts>5</max_suspicious_broken_parts>
|
||
</merge_tree>
|
||
```
|
||
|
||
Пример для определения в `SETTINGS` у конкретной таблицы:
|
||
|
||
``` sql
|
||
CREATE TABLE foo
|
||
(
|
||
`A` Int64
|
||
)
|
||
ENGINE = MergeTree
|
||
ORDER BY tuple()
|
||
SETTINGS max_suspicious_broken_parts = 500;
|
||
```
|
||
|
||
Пример изменения настроек у конкретной таблицы командой `ALTER TABLE ... MODIFY SETTING`:
|
||
|
||
``` sql
|
||
ALTER TABLE foo
|
||
MODIFY SETTING max_suspicious_broken_parts = 100;
|
||
```
|
||
|
||
## parts\_to\_throw\_insert {#parts-to-throw-insert}
|
||
|
||
Eсли число кусков в партиции превышает значение `parts_to_throw_insert`, INSERT прерывается с исключением `Too many parts (N). Merges are processing significantly slower than inserts`.
|
||
|
||
Возможные значения:
|
||
|
||
- Положительное целое число.
|
||
|
||
Значение по умолчанию: 300.
|
||
|
||
Для достижения максимальной производительности запросов `SELECT` необходимо минимизировать количество обрабатываемых кусков, см. [Дизайн MergeTree](../../development/architecture.md#merge-tree).
|
||
|
||
Можно установить большее значение 600 (1200), это уменьшит вероятность возникновения ошибки `Too many parts`, но в тоже время вы позже обнаружите возможную проблему со слияниями (например, из-за недостатка места на диске) и деградацию производительности `SELECT`.
|
||
|
||
## parts\_to\_delay\_insert {#parts-to-delay-insert}
|
||
|
||
Eсли число кусков в партиции превышает значение `parts_to_delay_insert`, `INSERT` искусственно замедляется.
|
||
|
||
Возможные значения:
|
||
|
||
- Положительное целое число.
|
||
|
||
Значение по умолчанию: 150.
|
||
|
||
ClickHouse искусственно выполняет `INSERT` дольше (добавляет ‘sleep’), чтобы фоновый механизм слияния успевал слиять куски быстрее, чем они добавляются.
|
||
|
||
## max\_delay\_to\_insert {#max-delay-to-insert}
|
||
|
||
Величина в секундах, которая используется для расчета задержки `INSERT`, если число кусков в партиции превышает значение [parts\_to\_delay\_insert](#parts-to-delay-insert).
|
||
|
||
Возможные значения:
|
||
|
||
- Положительное целое число.
|
||
|
||
Значение по умолчанию: 1.
|
||
|
||
Величина задержки (в миллисекундах) для `INSERT` вычисляется по формуле:
|
||
|
||
``` code
|
||
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 {#max-parts-in-total}
|
||
|
||
Eсли суммарное число активных кусков во всех партициях таблицы превышает значение `max_parts_in_total`, INSERT прерывается с исключением `Too many parts (N)`.
|
||
|
||
Возможные значения:
|
||
|
||
- Положительное целое число.
|
||
|
||
Значение по умолчанию: 100000.
|
||
|
||
Большое число кусков в таблице снижает производительность запросов ClickHouse и увеличивает время старта ClickHouse. Чаще всего это следствие неправильного дизайна (ошибки при выборе стратегии партиционирования -- слишком мелкие партиции).
|
||
|
||
## replicated\_deduplication\_window {#replicated-deduplication-window}
|
||
|
||
Количество хеш-сумм последних вставленных блоков, хранящихся в Zookeeper.
|
||
|
||
Возможные значения:
|
||
|
||
- Положительное целое число.
|
||
|
||
Значение по умолчанию: 100.
|
||
|
||
Команда `Insert` создает один или несколько блоков (кусков). При вставке в Replicated таблицы ClickHouse для [дедупликации вставок](../../engines/table-engines/mergetree-family/replication.md) записывает в Zookeeper хеш-суммы созданных кусков. Но хранятся хеш-суммы не всех кусков, а только последние `replicated_deduplication_window`. Наиболее старые хеш-суммы удаляются из Zookeeper.
|
||
Большое число `replicated_deduplication_window` замедляет `Insert`-ы. Хеш-сумма рассчитывается от композиции имен и типов полей, а также данных вставленного куска (потока байт).
|
||
|
||
## replicated\_deduplication\_window\_seconds {#replicated-deduplication-window-seconds}
|
||
|
||
Число секунд, после которых хеш-суммы вставленных блоков удаляются из Zookeeper.
|
||
|
||
Возможные значения:
|
||
|
||
- Положительное целое число.
|
||
|
||
Значение по умолчанию: 604800 (1 неделя).
|
||
|
||
Аналогично [replicated_deduplication_window](#replicated-deduplication-window), задает, сколько времени хранить хеш-суммы блоков для дедупликции `Insert`-в. Хеш-суммы старше `replicated_deduplication_window_seconds` удаляются из Zookeeper, даже если их меньше чем `replicated_deduplication_window`.
|
||
|
||
## old\_parts\_lifetime {#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}
|
||
|
||
Максимальный суммарный размер кусков (в байтах) в одном слиянии, при наличии свободных ресурсов в фоновом пуле.
|
||
`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 {#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 {#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 {#max-part-loading-threads}
|
||
|
||
Максимальное количество потоков, которые читают куски при старте ClickHouse.
|
||
|
||
Возможные значения:
|
||
|
||
- Положительное целое число.
|
||
|
||
Значение по умолчанию: auto (количество ядер процессора).
|
||
|
||
При старте ClickHouse читает все куски всех таблиц (читает файлы с метаданными кусков), чтобы построить в ОЗУ список всех кусков. В некоторых системах с большим количеством кусков этот процесс может занимать длительное время, и это время можно сократить, увеличив `max_part_loading_threads` (если при этом процессе есть недозагруженность CPU и диска).
|
||
|
||
{## [Оригинальная статья](https://clickhouse.tech/docs/ru/operations/settings/merge-tree-settings/) ##}
|