♻️ ReplacingMergeTree — когда в ClickHouse всё-таки нужны обновления

🔥 Главная мысль

ClickHouse не любит классические UPDATE.

Но это не значит, что в нём вообще нельзя моделировать изменение данных.

Один из самых частых способов — ReplacingMergeTree.

Если сказать совсем просто:

ReplacingMergeTree позволяет хранить несколько версий строки, а потом во время merge оставлять только одну — обычно последнюю или с наибольшей версией.

🟢 Плюсы:

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

Пример плюса: если у тебя есть справочник клиентов, и по одному client_id иногда приезжают новые версии строки, ReplacingMergeTree позволяет в итоге оставить последнюю версию.

🔴 Минусы:

• дубликаты исчезают не сразу • merge идёт в фоне • при чтении без FINAL дубликаты могут быть видны • люди часто ждут от него “мгновенный UPDATE”, а это не так

Пример минуса: ты вставил новую версию записи и сделал SELECT, а старая запись ещё видна. Это нормально для ReplacingMergeTree, потому что merge мог ещё не успеть выполниться.

🧪 Живые примеры

Когда ReplacingMergeTree особенно уместен:

• дедупликация событий • актуальные справочники • CDC-сценарии • модель “пришла новая версия строки”

Когда он не идеален:

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

Простой сценарий:

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

Для ClickHouse это естественнее, чем переписывать старую строку “по месту”.

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

В больших компаниях ReplacingMergeTree часто используют как компромисс:

не делать тяжёлые UPDATE, а моделировать изменение данных через append-only вставки новых версий.

Что это даёт:

• лучше соответствует природе ClickHouse • проще грузить данные батчами • удобно для CDC и исторических потоков

⚠️ Риски:

• злоупотреблять FINAL • забыть про версионность • ожидать мгновенного удаления дублей • не учитывать стоимость чтения в “сыром” состоянии

Самая частая ошибка — ожидать от ReplacingMergeTree поведения обычной транзакционной БД.

✅ Вывод

ReplacingMergeTree — это не “обычный UPDATE в ClickHouse” ♻️

Это способ моделировать обновления через новые версии строк.

Для дедупликации и CDC это очень полезно. Для классической транзакционной логики — уже не лучший путь ⚡️