Merge pull request #10620 from den-crane/Docs/merge-tree-settings-cont

Doc. merge-tree-settings.md

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

@@ -65,7 +65,7 @@ ClickHouse искусственно выполняет `INSERT` дольше (д
 
 Значение по умолчанию: 1.
 
-Величина задержи (в миллисекундах) для `INSERT` вычисляется по формуле:
+Величина задержки (в миллисекундах) для `INSERT` вычисляется по формуле:
 
 ``` code
 max_k = parts_to_throw_insert - parts_to_delay_insert
@@ -75,6 +75,43 @@ 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/) записывает в 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}
 
 Время (в секундах) хранения неактивных кусков, для защиты от потери данных при спонтанной перезагрузке сервера или О.С.
@@ -92,4 +129,56 @@ delay_milliseconds = pow(max_delay_to_insert * 1000, k / max_k)
 
 Стандартное значение 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/) <!--hide-->