#кейсы

Как мы сократили время OPTIMIZE в ClickHouse почти в 2 раза

Есть таблица на ReplacingMergeTree, для которой регулярно выполнялся:

OPTIMIZE TABLE schema.table FINAL SETTINGS optimize_throw_if_noop = 1;

Поначалу всё работало отлично. Но со временем таблица выросла примерно до 200 ГБ (в сжатом виде).

В какой-то момент начались инциденты.

📌Что произошло

Таблица была непартиционированной, поэтому OPTIMIZE FINAL каждый раз фактически проходил по всей таблице. Когда объем данных вырос, оптимизация перестала укладываться в таймаут драйвера с ClickHouse. На графике это видно как серию падений DAG (оранжевая область).

Чтобы восстановить работу, пришлось просто увеличить timeout драйвера. Выполнение стабилизировалось, но появилась другая проблема – каждая оптимизация стала занимать 3–4 часа. По итогу Time to Market у нас пошел по одному месту.

📌Решение

Так как нужно было удалять дубли в рамках ключа, применили хеш-партиционирование по ключу сортировки разбив её на 16 частей:

PARTITION BY cityHash64(id) % 16

После этого:

  1. пересобрали таблицу;
  2. выполнили EXCHANGE TABLE;
  3. оптимизация стала выполняться параллельно по каждой партиции отдельно, а не по всей таблице сразу.

📌Итог

📊 На графике хорошо видно три этапа:

🟠 Инциденты – OPTIMIZE перестал укладываться в таймаут и начал падать. 🔵 Временное решение – Увеличили timeout соединения. Проблема исчезла, но время выполнения выросло до 3–4 часов. 🔴 Я тут как раз пересобирал таблицу 🟢 Окончательное решение – Перешли на хеш-партиционирование.

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

Понятное дело, что мы можем еще поработать над параллельностью, над кодеками самих колонок, разложить не на 16 частей, а например на 32 и т.д. но важно понимать это инцидент, а не полноценная задача. Соответсвенно нужно сделать быстро и чтобы работало исправно, как только и тут зайдём на SLA в 2 часа, то начнём думать что делать дальше, вплоть до того чтобы оставлять только нужные данные, а остальные отправлять в архив.

**_____________________

Хочешь изучить Python и SQL записывайся на 1й поток "Буткемпик" через** @bootcampych_bot****, старт через 2 дня – 1 июля!

#кейсы
Как мы сократили время OPTIMIZE в ClickHouse почти в 2 раза
Есть таблица на ReplacingMergeTree, для которой регулярно выполнялся:
OPTIMIZE TABLE schema | Сетка — социальная сеть от hh.ru