Всем привет, какие есть лучшие практики для задачи репликации postgres

-> clickhouse? Т.е., работает основная база на pg, а для аналитики сбоку стоит Clickhouse с +- актуальными данными.
Как-то сходу не гуглится/дукдучится. Т.е., нашёл несколько ссылок - https://github.com/mkabilov/pg2ch, https://pypi.org/project/synch/ и ещё что-то. Но как-то не завелись они с полпинка, а сходу лезть в дебаг не хотелось бы.
Кто что использует для такой задачи?

Движок есть postgresql уже в кх

Я тоже только изучаю. С Oracle данные в Clickhouse перегонял с помощью DATAX А еще есть JDBC Bridge

Ага, вот им и перетянул данные, но как это делать "на постоянной основе", т.е., чтобы WAL синхронизировался?

Или имеете в виду - создавать БД на движке postgres и (как-то) реплицировать?

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

Ага, спасибо за ответ. Просто слышал в подкасте, что CH хорошо подходит для всякой аналитики, есть там какие-то плюшки, которых нет в PG, вот и решил попробовать в качестве эксперимента.

вот вышеуказанное и придется заводить лезьте в дебаг =) ну или ждите когда зарелизят https://github.com/ClickHouse/ClickHouse/pull/20470

Я б понимал бы, если вы будете преобразовывать данные и хранить в КХ для аналитики уже processed data из постгри. :)

думаю вам в clickhouse рано =) думаю у вас данных столько нет ...

ну шо как сразу обрубаити (сорказмь)

Например - в postgres есть ограничение на уникальный ключ/констрейнт для секционированных таблиц, если ключ секционирования задан выражением. А в кликхаусе этого ограничения нет.

А какой "порог входа" в CH (в строках)? :)

ну =) зато в clickhouse вообще UNIQUE KEYS нет =)

Use-case смотрите свой, дело даж не в технической стороне вопроса, а в целесообразности использования подхода :)

Да? А что тогда такое PRIMARY KEY в DDL - это не то, что я думаю? =)

он не в строках чтобы все получилось, ситуация должна быть так "мы ХОРОШО (на низком уровне) знаем как работает наша текущая БД и понимаем почему она тормозит на нашем use case и понимаем почему в clickhouse будет работать быстрее" а все остальное "ой я слышал clickhouse модный" либо "ой давайте все аналитические данные сразу в clickhouse будем хранить" обычно не очень хорошо кончается =)

С постгрей отчасти "импортозамещение" канает %)

Спасибо за ответ, вполне резонно.

вот вообще не то =) PRIMARY KEY это вот прямо PRIMARY KEY а не UNIQUE CLUSTERED INDEX как в MySQL и UNIQUE B-Tree INDEX как в Postgre

Ага, интересно... Наверное, в кликхаус мне действительно рано (-:

если у вас сейчас postgres и хочется в рамках аналитики поиграться в этой экосистеме посмотрите в сторону CItus Columnar Extension https://www.citusdata.com/

Спасибо, посмотрю.

пора уже закопать стюардессу :)

никого не слушайте, юзайте кликхайс, но на вашем месте я бы подождал релиза MaterializePostgreSQL, собственно я сам и жду :)

А почему вы говорите это мне, а не топикстартеру?

никого не слушайте, юзайте кликхайс, но на вашем месте я бы подождал релиза MaterializePostgreSQL, собственно я сам и жду :)

спасибо. исправился

Да, MaterializePostgreSQL был бы то, что надо. К счастью, особой спешки у меня нет, так что можно и подождать. А пока делаю очередной подход к https://github.com/long2ice/synch , но что-то он не хочет работать с postgres, то одни ошибки, то другие, то третьи...

если вам сейчас нужно "поиграться" с целью изучения, а не продакшен версия, то можете скачать репозиторий, вмёржить указанный выше пулреквест и по инструкции собрать из исходников то что вам нужно уже сейчас. а когда выйдет официальная версия с поддержкой MaterializePostgreSQL, то просто обновиться на неё. это на слуйчай если с другими способами совсем никак не сложится

Как вариант, да, спасибо за подсказку.