A
Надо конечно проверить как он будет себя чувствовать в таком кейсе. В части аналитики понятное дело - отлично, но тащить по одной записи и постоянно - хз. Как проверю - отпишусь.
Size: a a a
2019 December 04
A
Ну все зависит от основных запросов все таки
Получение метрик по идентификатору устройств и фильтрация по нескольким колонкам.
A
Кх просто для пейджинга использовать плохая идея, это в кейсе с фильтрацией я имею ввиду.
OP
В гринпламе сегментировать по id устройств , партицнуть по времени, будете брать с каждого сегмента по последним данным из партиции
Д
Кх просто для пейджинга использовать плохая идея, это в кейсе с фильтрацией я имею ввиду.
RIAK TS посмотрите еще
Д
тоже тайм сериз
A
А как-то чистить в ts можно данные автоматически? что-то вроде того как в КХ движок ReplacingMergeTree делает, где по факту на диске спустя какое-то время хранится один экземпляр строки.
Д
А как-то чистить в ts можно данные автоматически? что-то вроде того как в КХ движок ReplacingMergeTree делает, где по факту на диске спустя какое-то время хранится один экземпляр строки.
у influx есть ретеншн полиси
A
у influx есть ретеншн полиси
Спасибо
K
Ещё можно timescale посмотреть. Это PG переделанная под TS
K
Под time series
PD
Всем привет. Подскажите, что можно использовать для персистентного хранения актуальных данных? Каждую секунду может приходить несколько десятков тысяч метрик от устройств. Требуется в любой момент времени получать последнюю метрику по какому-то конкретному устройству. Pg сейчас используется для этого, но для этой задачи от не очень походит.
Kafka + inmem + pg?
PD
А какие требования к надёжности?
A
Kafka + inmem + pg?
проблема с pg в автовакуме, мы сейчас пишем в несколько таблиц метричных в pg, потом раз в какое-то время фоновый процесс вычищает все, кроме последней метрики по каждому устройству.
PD
Это понятно, но в такой схеме pg нужен только как "бэкап" и время на автовакум не существенно.
Т.е. кафку читаем и пишем в банальную inmem key-value (взять готовый редис или просто написать hash-map).
И аггрегируеем пачками и пишем в PG.
При падении - забираем актуальное из PG+kafka (и это самое сложное).
Т.е. кафку читаем и пишем в банальную inmem key-value (взять готовый редис или просто написать hash-map).
И аггрегируеем пачками и пишем в PG.
При падении - забираем актуальное из PG+kafka (и это самое сложное).
A
kafka чтобы что? чтобы не положить редис?
A
> При падении - забираем актуальное из PG+kafka
Думали про такое, но смущает "время на прогрев"
Думали про такое, но смущает "время на прогрев"
A
Проблема с kv еще с фильтрацией, можно конечно на redis и это решить, но хочется более элегантного способа, нежели ловить факт падения redis и как-то его прогревать.