Comments 6
Случаем не подскажете в чем преимущество использования Postgresql + fdw + clickhouse перед Postgresql + TimescaleDB?
+2
Каждый найдёт своё. Очень многое зависит от вашего сетапа, экспертизы, используемых решений, хранимых данных.
Продукты очень похожие, однако distributed timescaledb появился позже и я его пока не трогал. Пока из видимых плюсов — clickhouse проще обновлять, его можно подцепить к kafka. Но это, опять же, исключительно исходя из нашего опыта испольования, когда в вашем стеке есть kafka.
UPD Если раскроете чуть больше данных по проекту — то можно будет уже что-то посоветоват.
Продукты очень похожие, однако distributed timescaledb появился позже и я его пока не трогал. Пока из видимых плюсов — clickhouse проще обновлять, его можно подцепить к kafka. Но это, опять же, исключительно исходя из нашего опыта испольования, когда в вашем стеке есть kafka.
UPD Если раскроете чуть больше данных по проекту — то можно будет уже что-то посоветоват.
0
Меня интересовал именно ваш опыт, может нюансы какие.
И, вы уж извините, но ваш текст выглядит как очень растянутое «не знаю».
И, вы уж извините, но ваш текст выглядит как очень растянутое «не знаю».
+1
Похоже стоит ответить развёрнетее. Вы частично правы — это было «не знаю», но сугубо по одному из пунктов.
Итак, мы используем все инструменты — Postgresql, Clickhouse и TimescaleDB. Да, я знаю, что это плагин к Postgresql, но он настолько не вписывается в ванильный postgresql, что даже процедура дампа и загрузки дампа у него своя.
Так вот если у вас в проекте есть postgresql и вам нужны временные ряды — то timescaledb отличное решение — все будет в одной базе, связка Postgresql + Clickhouse проиграет timescaledb просто потому, что там будет сетевое взаимодействие. Плюс удобство и сила PL/pgSQL. Однако кому интересны такие сетапы?
Когда мы готовимся у себя в команде к внедрению Clickhouse — то подразумеваем сразу кластер с шардирование и репликацией, с множеством узлов. Ну и соответствующие объемы данных. И вот тут мы как раз подходим к тому, что пока у нас не было возможности опробовать Distributed Hypertables, так как появились они позднее. Это как раз и есть моё «не знаю».
Ну и опять хочется отметить, всё зависит от проекта. Например, в Clickhouse есть интересные вещи, за которые я его люблю — это Kafka Engine, когда Clickhouse выступает как консьюмер. Соответственно в проекте, где уже есть Kafka как шина данных — я предложу использовать Clickhouse. Так же нельзя забывать и про Materialized View в Clickhouse, которые асинхонно преобразует сырые данные в готовые преагрегаты. Мне очень нравится такой подход.
Итак, мы используем все инструменты — Postgresql, Clickhouse и TimescaleDB. Да, я знаю, что это плагин к Postgresql, но он настолько не вписывается в ванильный postgresql, что даже процедура дампа и загрузки дампа у него своя.
Так вот если у вас в проекте есть postgresql и вам нужны временные ряды — то timescaledb отличное решение — все будет в одной базе, связка Postgresql + Clickhouse проиграет timescaledb просто потому, что там будет сетевое взаимодействие. Плюс удобство и сила PL/pgSQL. Однако кому интересны такие сетапы?
Когда мы готовимся у себя в команде к внедрению Clickhouse — то подразумеваем сразу кластер с шардирование и репликацией, с множеством узлов. Ну и соответствующие объемы данных. И вот тут мы как раз подходим к тому, что пока у нас не было возможности опробовать Distributed Hypertables, так как появились они позднее. Это как раз и есть моё «не знаю».
Ну и опять хочется отметить, всё зависит от проекта. Например, в Clickhouse есть интересные вещи, за которые я его люблю — это Kafka Engine, когда Clickhouse выступает как консьюмер. Соответственно в проекте, где уже есть Kafka как шина данных — я предложу использовать Clickhouse. Так же нельзя забывать и про Materialized View в Clickhouse, которые асинхонно преобразует сырые данные в готовые преагрегаты. Мне очень нравится такой подход.
+1
Вот теперь интересно, спасибо.
А по подробней?
Дык Continuous Aggregates TimesacleDB и она как раз Materialized View. В тч real-time
Ну и соответствующие объемы данных
А по подробней?
Materialized View в Clickhouse, которые асинхонно преобразует сырые данные в готовые преагрегаты.
Дык Continuous Aggregates TimesacleDB и она как раз Materialized View. В тч real-time
+1
Про объемы — сложно сравнить сколько бы такое весило в других базах, но в clickhouse данные занимают обычно от десятка терабайт. Есть инстансы поменьше — но там обычно просто репликация настроена, не кластер c шардами.
Я поэтому и сказал, что продукты похожи.
Дык Continuous Aggregates TimesacleDB и она как раз Materialized View. В тч real-time
Я поэтому и сказал, что продукты похожи.
0
Sign up to leave a comment.
Обновлены Docker-образы с clickhouse-exporter и clickhouse_fdw