DT
Для эвентстрима — очень хорош! А вот для дименшенов — не очень (
Size: a a a
2020 February 06
PD
Ну и вообще, как только у вас не "единое хранилище на все", то уже лучше использовать специализированные стораджи на каждую задачу, а не "полууниверсальные" типа игнайта.
PD
Для эвентстрима — очень хорош! А вот для дименшенов — не очень (
А для этого там MatView есть. Ну и вообще аггрегации быстро делает.
DT
Как это, не умеет? А AggregateMerge на что.
Насколько я в курсе, в кликхаусе Есть агрегация по ключу, но работает по шедулеру
PD
Не по шедулеру, а по пачке данных. Т.е. для OLTP не стоит, для OLAP с отставанием до секунды-двух - нормально.
DT
Не по шедулеру, а по пачке данных. Т.е. для OLTP не стоит, для OLAP с отставанием до секунды-двух - нормально.
Почему-то никогда об этом не думал. Спасибо за мысль, я попробую!
PD
Я сейчас как раз играю с быстрой key-value для OLTP и CH для нестандартных выборок, фильтров и аналитики.
DT
Я сейчас как раз играю с быстрой key-value для OLTP и CH для нестандартных выборок, фильтров и аналитики.
А как данные пересекать между собой потом?
PD
Пересекать - для чего?
DT
Ну, дашборд показать!
DT
Нотификацию выслать
DT
Писать k-v и в кликхаус в матвьюху параллельно?
PD
Да, конечно.
PD
Т.е. есть поток запросов на обновление, он прилетает на оркестратор, тот пишет всюду куда надо и обеспечивает гарантии.
Т.е примерно CQRS )
Т.е примерно CQRS )
PD
В обеих базах одни и те же данные.
DT
Т.е. есть поток запросов на обновление, он прилетает на оркестратор, тот пишет всюду куда надо и обеспечивает гарантии.
Т.е примерно CQRS )
Т.е примерно CQRS )
Оркестратор = флинк/спарк?
PD
(Так-то баз гораздо больше, так как key-value по штуке на сервис, а вот CH как раз с агрегацией данных из разных сервисов. Но это все не так существенно).
PD
Оркестратор = флинк/спарк?
Нет, конечно. Свое в идеологии Cadence.
DT
Почему нет, и почему конечно?
PD
Но это каждый сам себе придумывает.