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

[vaultaddict]

Полгода назад тимлид продал бизнесу историю «уходим с Postgres на ClickHouse, аналитика будет летать». Аналитика реально летает, дашборды которые крутились по 40 секунд теперь 0.8с. Но Postgres мы так и не выключили, он держит весь операционный контур. По факту теперь две базы вместо одной. Это норма или мы что-то не так спроектировали?

[k8s2000]

Это абсолютно норма и более того — единственно вменяемый вариант. CH это OLAP, колоночник под агрегации, а ваш транзакционный контур (заказы, юзеры, платежи) на нём жить не может. Никто в здравом уме не выключает OLTP базу после внедрения аналитики.

[svelte_nerd]

Классика. «Заменим Postgres на ClickHouse» в 9 из 10 случаев превращается в «добавим ClickHouse рядом с Postgres». Вопрос только как вы их синхронизируете.

[rbacker]

Через Debezium + Kafka, CDC с логического слота. Лаг обычно 2-5 секунд, иногда прыгает до минуты под нагрузкой.

[jpearce]

А почему не MaterializedPostgreSQL движок прямо в CH? Он сам вычитывает WAL и реплицирует. Мы так сделали, выкинули полпайплайна.

[mystiga]

Потому что MaterializedPostgreSQL до сих пор помечен как experimental и на проде с ним весело. У нас он разъезжался при ALTER TABLE на исходнике, ловили молча пропавшие строки. Debezium хоть и тяжелее, но предсказуемее.

[asynclover]

+ за Debezium. Experimental в CH это не «почти готово», это «работает пока ты не дышишь на схему».

[boblee]

А никто не смотрел в сторону TimescaleDB чтобы вообще одну базу оставить? Получается расширение к Postgres, и колоночное сжатие там есть.

[marianna]

Смотрели. На time-series и умеренных объёмах Timescale топ, мы его юзаем под метрики. Но когда дошли до 2+ млрд строк и тяжёлых group by по 10 колонкам — CH рвёт его в разы. Это разные весовые категории.

[wasmsre]

Подтверждаю цифрами: тот же запрос (агрегация по 800М строк) Timescale 6.2с, ClickHouse 0.3с. Но Timescale удобнее эксплуатировать, потому что это твой родной Postgres со всеми инструментами.