> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Устранение исключения "Too many parts" в ClickHouse

> Узнайте, как диагностировать и устранить исключение "Too many parts": объединять вставки в батчи, использовать асинхронные вставки и выбирать подходящий ключ партиционирования.

<div id="what-the-exception-means">
  ## Что означает это исключение
</div>

ClickHouse выдает исключение `Too many parts`, когда `INSERT` привел бы к превышению настроенного ограничения на количество активных частей данных в таблице `MergeTree`. Исключение часто содержит сообщение `Merges are processing significantly slower than inserts`.

Каждый синхронный `INSERT` создает как минимум одну часть данных. Если вставка содержит строки для нескольких значений партиций, ClickHouse может создать по одной части для каждой затронутой партиции. Фоновые слияния объединяют мелкие части в более крупные, но если новые части создаются быстрее, чем ClickHouse успевает их сливать, число активных частей продолжает расти.

Исключение может быть вызвано одной из следующих настроек:

* [`parts_to_throw_insert`](/docs/ru/reference/settings/merge-tree-settings/parts-to#parts_to_throw_insert), которая ограничивает количество активных частей в одной партиции.
* [`max_parts_in_total`](/docs/ru/reference/settings/merge-tree-settings/max-parts#max_parts_in_total), которая ограничивает общее количество активных частей в таблице.

<div id="diagnose-the-cause">
  ## Определение причины
</div>

Используйте следующий запрос, чтобы найти партиции с наибольшим количеством активных частей:

```sql theme={null}
SELECT
    database,
    table,
    partition_id,
    count() AS active_parts,
    sum(rows) AS rows,
    formatReadableSize(sum(bytes_on_disk)) AS size_on_disk
FROM system.parts
WHERE active
  AND database = '<database_name>'
  AND table = '<table_name>'
GROUP BY
    database,
    table,
    partition_id
ORDER BY active_parts DESC;
```

Чтобы проверить ограничение для всей таблицы, задаваемое параметром `max_parts_in_total`, подсчитайте все активные части в таблице:

```sql theme={null}
SELECT
    database,
    table,
    count() AS active_parts,
    sum(rows) AS rows,
    formatReadableSize(sum(bytes_on_disk)) AS size_on_disk
FROM system.parts
WHERE active
  AND database = '<database_name>'
  AND table = '<table_name>'
GROUP BY
    database,
    table;
```

К распространённым причинам относятся:

* Частые небольшие синхронные вставки.
* Ключ партиционирования с большой мощностью.
* Вставки, содержащие строки для множества значений партиций.
* Фоновые слияния, которые не успевают выполняться из-за ограниченной пропускной способности хранилища, недостатка свободного места на диске или конкуренции за ресурсы.

Вы можете проверить текущие слияния в [`system.merges`](/docs/ru/reference/system-tables/merges) и просмотреть записи серверного журнала, чтобы выявить ошибки слияния.

<div id="resolve-the-exception">
  ## Устранение исключения
</div>

<div id="batch-synchronous-inserts">
  ### Батчи при синхронных вставках
</div>

Группируйте строки в батчи на клиенте перед вставкой. Каждый батч должен содержать не менее 1 000 строк, а в идеале — 10 000–100 000 строк. Старайтесь выполнять примерно одну синхронную операцию `INSERT` в секунду. Меньшее число более крупных вставок создает меньше частей и уменьшает объем работы для фоновых слияний.

<div id="use-asynchronous-inserts">
  ### Используйте асинхронные вставки
</div>

Если батчинг на стороне клиента непрактичен, используйте [асинхронные вставки](/docs/ru/concepts/best-practices/selecting-an-insert-strategy#asynchronous-inserts), чтобы ClickHouse мог группировать входящие данные в батчи на сервере:

```sql theme={null}
INSERT INTO <table_name>
SETTINGS
    async_insert = 1,
    wait_for_async_insert = 1
VALUES (...);
```

Оставьте `wait_for_async_insert = 1`, чтобы ClickHouse подтверждал вставку только после успешной записи данных.

<div id="review-the-partitioning-key">
  ### Проверьте ключ партиционирования
</div>

Используйте ключ партиционирования с низкой мощностью и избегайте партиционирования по таким значениям, как идентификаторы пользователей или запросов. ClickHouse выполняет слияние частей только в пределах одной партиции, поэтому большое количество партиций не позволяет эффективно выполнять слияние. Рекомендации см. в разделе [Выбор ключа партиционирования](/docs/ru/concepts/best-practices/partitioning-keys).

<div id="investigate-merge-bottlenecks">
  ### Выявите узкие места при слиянии
</div>

Если вставки уже правильно объединены в батчи, проверьте производительность хранилища, доступное дисковое пространство и конкурирующие фоновые задачи. Скорость слияния зависит от системы хранения, движка таблицы, ключа сортировки, сжатия и доступных ресурсов CPU и I/O.

<div id="avoid-increasing-part-limits-as-the-primary-fix">
  ### Не используйте увеличение ограничений на части как основное решение
</div>

Увеличение `parts_to_throw_insert` или `max_parts_in_total` не устраняет причину чрезмерного создания частей. Более высокие ограничения могут отсрочить исключение, но также увеличить нагрузку на файловую систему и метаданные и снизить производительность запросов. Изменяйте эти настройки только после того, как определите причину и убедитесь, что у системы достаточно ресурсов.

<div id="verify-the-recovery">
  ## Проверьте восстановление
</div>

Снова выполните диагностический запрос после изменения стратегии вставки или схемы партиционирования. Число активных частей должно стабилизироваться, а затем уменьшиться по мере того, как фоновые слияния будут догонять накопившийся объём. Продолжайте отслеживать ошибки вставки, свободное место на диске и [`system.merges`](/docs/ru/reference/system-tables/merges), пока отставание не будет устранено.