Избегайте `OPTIMIZE FINAL`

Страница о том, почему следует избегать конструкции OPTIMIZE FINAL в ClickHouse

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

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

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

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

OPTIMIZE TABLE <table> FINAL;

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

OPTIMIZE FINAL и 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
• Такие крупные части может быть сложно сливать дальше, то есть попытки их дальнейшего слияния будут завершаться неудачей по указанным выше причинам. Если слияния нужны для корректного поведения во время выполнения запроса, это может привести к нежелательным последствиям, например к накоплению дубликатов в ReplacingMergeTree, что снижает производительность запросов.

​

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

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