λ
зио может запускаться в k8s кластере)
Size: a a a
2021 February 23
БЁ
у сука
EK
Колоночная БД что с ней не так? Какое отношение она к ивенты имеет или ты её как лог хочешь юзать?
А в чем проблема кассандры для ES? EntityId как партишен кей, time как clustering
SP
А кстати. Vertx кто то трогал? Челы говорят что сделало вторую акку (блин может и не надо было?))
λ
Борщевик Ёбаный
у сука
а дальше любые паттерны какие хочешь, хоть истио, хоть кафку)
SP
А в чем проблема кассандры для ES? EntityId как партишен кей, time как clustering
А еще можно в постгресе по тацмстампу хранить
БЁ
а дальше любые паттерны какие хочешь, хоть истио, хоть кафку)
заказываю паттерн билдер
ΛВ
зио может запускаться в k8s кластере)
в смысле как обычное жвм приложение?
ΛВ
или там чета напрямую?
T
А еще можно в постгресе по тацмстампу хранить
постгрес в мультимастере, ну такое
лучше уж кассандру
лучше уж кассандру
λ
в смысле как обычное жвм приложение?
Ну да)
SP
Как много жвм приложений
EK
А еще можно в постгресе по тацмстампу хранить
Постгрес не сможет быстро дать эвенты по энтитиИд. Либо я не понял шутейку
T
Постгрес не сможет быстро дать эвенты по энтитиИд. Либо я не понял шутейку
не факт что кассандра быстрее отдаст на рид, особенно недавно записанное
M
А в чем проблема кассандры для ES? EntityId как партишен кей, time как clustering
а потом ты хочешь эвенты застримить для обработки куда-нибудь и приехали
M
для кассандры CDC не очень рабочий
M
Борщевик Ёбаный
а ещё нетфликс умеет варить мультикластер кафку, где ты условно по ключубалансишься сначала в кластер кафки
это как будто скейлится
это как будто скейлится
немного сомневаюсь, что будет работать нормально, потому что регистр топиков он по идее строго консистентный и там что-то вроде рафта или паксоса надо гонять на каждое создание
EK
не факт что кассандра быстрее отдаст на рид, особенно недавно записанное
Я не знаю, я дата инжиниринг не понимаю сердцем, только на работе притворяюсь. Предполагал, что ,если речь о больших данных, то выгоднее хранить связанные данные вместе, как это делают column-oriented, а не искать их по индексу. Понятно, что для небольших объёмов более важны мелкие детали БД, чем принцип
M
Ну можно держать топики с аггрешированными данными например по какому то признаку
Не понял. Можешь объяснить?