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

[egor_core60]

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

[anton4734]

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

[grigory2102]

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

[julia_go56]

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

[kira_api82]

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

[dnscache8196]

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

[fluxnode7801]

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

[semyon_null56]

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