Skip to main content

Что означает это исключение

ClickHouse выдает исключение Too many parts, когда INSERT привел бы к превышению настроенного ограничения на количество активных частей данных в таблице MergeTree. Исключение часто содержит сообщение Merges are processing significantly slower than inserts. Каждый синхронный INSERT создает как минимум одну часть данных. Если вставка содержит строки для нескольких значений партиций, ClickHouse может создать по одной части для каждой затронутой партиции. Фоновые слияния объединяют мелкие части в более крупные, но если новые части создаются быстрее, чем ClickHouse успевает их сливать, число активных частей продолжает расти. Исключение может быть вызвано одной из следующих настроек:
  • parts_to_throw_insert, которая ограничивает количество активных частей в одной партиции.
  • max_parts_in_total, которая ограничивает общее количество активных частей в таблице.

Определение причины

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

Устранение исключения

Батчи при синхронных вставках

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

Используйте асинхронные вставки

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

Проверьте ключ партиционирования

Используйте ключ партиционирования с низкой мощностью и избегайте партиционирования по таким значениям, как идентификаторы пользователей или запросов. ClickHouse выполняет слияние частей только в пределах одной партиции, поэтому большое количество партиций не позволяет эффективно выполнять слияние. Рекомендации см. в разделе Выбор ключа партиционирования.

Выявите узкие места при слиянии

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

Не используйте увеличение ограничений на части как основное решение

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

Проверьте восстановление

Снова выполните диагностический запрос после изменения стратегии вставки или схемы партиционирования. Число активных частей должно стабилизироваться, а затем уменьшиться по мере того, как фоновые слияния будут догонять накопившийся объём. Продолжайте отслеживать ошибки вставки, свободное место на диске и system.merges, пока отставание не будет устранено.
Последнее изменение 14 августа 2026 г.