⚠️ Почему ClickHouse не любит UPDATE

Одна из самых частых ошибок новичков — пытаться использовать ClickHouse как обычную транзакционную БД.

Например так:

• загрузили данные • потом начали часто обновлять строки • потом ещё и удалять по одной записи • потом удивились, почему всё стало работать тяжелее

Проблема в том, что ClickHouse изначально создавался не для такого сценария.

Он хорошо умеет:

• быстро писать большие пачки данных • быстро читать миллионы и миллиарды строк • быстро считать агрегаты • хорошо сжимать данные

То есть его сильная сторона — аналитика.

А вот частые UPDATE для него неудобны.

Почему? 🤔

Потому что ClickHouse лучше всего чувствует себя в модели:

добавили данные → сохранили → потом читаем и считаем

Это называется append-heavy подход.

То есть система любит, когда данные в основном добавляются, а не постоянно переписываются.

Когда ты делаешь UPDATE, для аналитического движка это почти всегда дорогая операция.

Почему она дорогая:

• нужно пересобрать куски данных • растёт фоновая нагрузка • усложняется хранение • увеличивается стоимость изменений • можно ухудшить скорость чтения и записи

Проще говоря:

для ClickHouse естественно читать и добавлять, а вот часто менять уже записанное — неестественно.

Именно поэтому ClickHouse плохо подходит для сценариев, где нужно:

• постоянно менять статусы • часто обновлять отдельные строки • делать много точечных DELETE • жить в логике “нашли запись → переписали запись”

Такие задачи обычно лучше решаются в OLTP-системах.

Например:

• PostgreSQL • MySQL • Oracle

А ClickHouse лучше ставить туда, где нужна аналитика:

• отчёты • дашборды • витрины • логи • события • большие исторические данные

Но тогда возникает вопрос 👇

А что делать, если данные всё-таки меняются?

Обычно архитектура строится так:

OLTP база → ETL / CDC → ClickHouse

То есть:

• в боевой системе данные живут и меняются • потом изменения передаются в аналитический слой • а в ClickHouse они уже складываются в удобном для аналитики виде

🧠 Архитектурная мысль

ClickHouse не надо ставить на место системы, которая живёт постоянными UPDATE.

Его место — аналитический слой.

Там, где нужно не “переписать одну строку”, а “быстро посчитать метрику по 800 млн записей”.

Вывод

ClickHouse не любит UPDATE не потому, что он “слабый”.

Наоборот.

Он очень сильный — просто в другой задаче.

Его суперсила:

• быстрое чтение • быстрые агрегации • большие объёмы данных • аналитическая нагрузка

Поэтому если у тебя система про постоянные изменения строк — это не лучший кандидат для ClickHouse.

А если у тебя система про аналитику на больших объёмах — тут ClickHouse чувствует себя отлично.