#кейсы
Как мы сократили время 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.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 июля!