Внедрили ClickHouse, а Postgres всё равно никуда не делся. Так и должно быть?

[lonelygoblin]

Главная боль CH даже не скорость, а то что он плохо переваривает UPDATE/DELETE. Если у вас данные правятся задним числом — готовьте ReplacingMergeTree и молитвы на фоновые мержи.

[k8s2000]

О да, про ReplacingMergeTree отдельная песня. Дубли висят пока мерж не пройдёт, и народ в дашбордах видит двойные суммы. Пришлось везде FINAL лепить, а это минус вся скорость.

[RedisNinja]

FINAL это антипаттерн на больших таблицах, ты по сути убиваешь весь смысл колоночника. Лучше argMax по версии или дедуп на этапе запроса. Но да, в Postgres это просто UPDATE и не паришься.

[matguyvr]

Сижу читаю и вспоминаю как мы это всё прошли. Главный вывод за 3 года: не «или-или», а «правильный инструмент под правильную нагрузку». Проблема только в том что теперь надо держать в команде людей которые шарят и за Postgres, и за CH.

[gdgdgd]

А можно тупой вопрос — а если просто реплику Postgres поднять и аналитику гонять на ней, чтобы прод не трогать? Зачем сразу второй движок.

[roman2026]

Можно, и для многих этого достаточно. Реплика снимает нагрузку с мастера, но НЕ меняет план выполнения — тяжёлый seq scan по миллиарду строк останется тяжёлым и на реплике. CH тащит за счёт колоночного хранения и SIMD, реплика так не умеет.

[cohenst1]

Короче резюме треда: CH рядом с Postgres — это фича, а не баг. Кто ждал что одна база закроет и OLTP и OLAP, тот не читал про CAP, простите за занудство

[qcdeed]

Спасибо всем, успокоили. Значит живём с зоопарком дальше, просто допилю мониторинг лага CDC и уберу FINAL где смогу.

[sainty]

Ситуация абсолютно стандартная и правильная. ClickHouse и Postgres решают принципиально разные задачи: один оптимизирован под колоночное хранение и аналитические скany, другой — под транзакционную целостность и точечные операции. Держать обе базы — это не архитектурный провал, это зрелое решение. Проблемы начинаются не когда баз две, а когда граница между ними размыта и бизнес-логика начинает лезть в аналитическую базу напрямую.

[FpgaDev]

@mystiga, полностью согласен насчёт MaterializedPostgreSQL. Мы тоже попробовали его в экспериментальном кластере — пока схема не меняется, работает красиво, но первый же ALTER TABLE с добавлением ненулевого поля без дефолта положил репликацию и молча. Никакого алерта, просто строки перестали приходить. Обнаружили через неделю, когда аналитики заметили расхождение в цифрах. Debezium сложнее в настройке, зато у него есть внятные метрики лага и dead letter queue.