Телеграмм чат группы scalability

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

источник

12:13пожаловаться #4

Ruslan Chekalov in Scalability Camp — чат про распределенные системы (и про HPC)

У меня такая трабла с кликхаусом, ему аналогично лучше писать батчи редко, чем по одной записи часто. Решил это средствами кафки, просто считываю батч раз в N времени

источник

12:15пожаловаться #5

Andrey Terekhov in Scalability Camp — чат про распределенные системы (и про HPC)

Ruslan Chekalov

Батч внесёт задержки или фрагментацию.
Вспомнил про Kinesis ещё кстати

источник

12:15пожаловаться #6

Andrey Terekhov in Scalability Camp — чат про распределенные системы (и про HPC)

Ruslan Chekalov

Да, если под требования попадает, мне этот вариант тоже нравится

источник

12:15пожаловаться #7

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)

Andrey Terekhov

Всем привет!
Подскажите, может есть подход под задачу — есть поток данных, нужно иметь возможность их держать в бд для аналитики (aws athena) и при этом иметь доступ к реалтайм данным. В athena не очень получается эффективно вставлять потоковые данные по событию — создаётся по файлику на s3 на каждый insert.
Подумал что можно прикрутить небольшой постгрес, партицировать посуточно и партиции старше 3х дней скидывать на s3 для athena.
При запросах с фронта бэк бы объединял результаты с двух баз с учётом какой временной период выбран.
Это прям кривой велосипед?)

Clickhouse?

источник

13:03пожаловаться #8

Andrey Terekhov in Scalability Camp — чат про распределенные системы (и про HPC)

Nikolay

Clickhouse?

Был бы management инстанс у амазона, то может быть взял его, да)

источник

13:05пожаловаться #9

Nikolay in Scalability Camp — чат про распределенные системы (и про HPC)

Andrey Terekhov

Был бы management инстанс у амазона, то может быть взял его, да)