Перейти к основному содержанию
Перейти к основному содержанию

Не используйте OPTIMIZE FINAL

Таблицы ClickHouse, использующие движок MergeTree, хранят данные на диске в виде неизменяемых частей, которые создаются каждый раз при вставке данных.

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

Со временем фоновые процессы объединяют более мелкие части в более крупные, чтобы уменьшить фрагментацию и улучшить производительность запросов.

Простые слияния

Хотя может быть заманчиво выполнить это слияние вручную, используя:

OPTIMIZE TABLE <таблица> FINAL;

в большинстве случаев следует избегать выполнения операции OPTIMIZE FINAL, так как она запускает ресурсоёмкие процессы, которые могут повлиять на производительность кластера.

OPTIMIZE FINAL vs FINAL

OPTIMIZE FINAL — это не то же самое, что FINAL, который иногда необходимо использовать, чтобы получить результаты без дубликатов, например, с ReplacingMergeTree. Как правило, FINAL допустимо использовать, если в ваших запросах фильтрация идёт по тем же столбцам, что и в первичном ключе.

Почему этого следует избегать?​

Это дорого по ресурсам​

Выполнение OPTIMIZE FINAL заставляет ClickHouse слить все активные части в одну часть, даже если крупные слияния уже происходили. Это включает:

  1. Декомпрессию всех частей
  2. Слияние данных
  3. Повторную компрессию
  4. Запись итоговой части на диск или в объектное хранилище

Эти шаги интенсивно используют CPU и I/O и могут сильно нагружать систему, особенно при работе с большими наборами данных.

Игнорируются защитные лимиты​

Обычно ClickHouse избегает слияния частей размером более ~150 ГБ (настраивается через max_bytes_to_merge_at_max_space_in_pool). Но OPTIMIZE FINAL игнорирует этот механизм защиты, что означает:

  • Может быть предпринята попытка слить несколько частей по 150 ГБ в одну огромную часть
  • Это может привести к длительным операциям слияния, дефициту памяти или даже ошибкам out-of-memory (OOM)
  • Такие крупные части могут стать сложными для дальнейшего слияния, то есть попытки объединить их далее будут завершаться сбоем по описанным выше причинам. В случаях, когда слияния необходимы для корректного поведения запросов во время выполнения, это может привести к нежелательным последствиям, таким как накапливание дубликатов для ReplacingMergeTree, что снижает производительность выполнения запросов.

Пусть фоновые слияния делают свою работу​

ClickHouse уже выполняет интеллектуальные фоновые слияния, чтобы оптимизировать хранение и эффективность выполнения запросов. Они инкрементальные, учитывают использование ресурсов и соблюдают настроенные пороговые значения. Если у вас нет какой-то очень специфической потребности (например, нужно финализировать данные перед заморозкой таблицы или экспортом), лучше доверить управление слияниями самому ClickHouse.