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

Избегать Optimize Final

ClickHouse tables, использующие движок 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 ГБ в одну огромную часть
  • Это может привести к долгому времени объединения, нагрузке на память или даже ошибкам нехватки памяти
  • Эти большие части могут стать трудными для объединения, т.е. попытки объединить их дальше могут провалиться по указанным выше причинам. В случаях, когда объединения необходимы для правильного поведения времени выполнения запросов, это может привести к нежелательным последствиям, например, скоплению дубликатов для ReplacingMergeTree, увеличивая время выполнения запросов.

Позвольте фоновым объединениям выполнять работу​

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