Потоки Redis как чистая структура данных

[aigoncharov]

Позвольте немного поворчать: чем больше данных, тем, обычно, больше их дисперсия, так что далеко не факт, что эти 18мб будут расти линейно.
А в целом, интересная штука. Надо потыкать :)

[jshapen]

Потыкали?
У меня на реальных данных как-то все неодназначно по сравнению с сортированным набором.
На миллионе коллекций из 5 пар name-value выигрыш по памяти менее 2,5 раз (40 проти 90 мегабайт), а вот по скорости что-то непонятное — проигрыш в 3-4 раза.

[ainu]

А насколько быстрой будет аггрегация в данной структуре? Допустим, мы решили хранить в потоках лог запросов, включая время его выполнения (из nginx например). Или лог посещений страницы.
Насколько тяжелая операция подстчёта количества, сгруппированного по дням (или суммы времени выполнения, сгруппированного по часам)?

Другими словами, возможно ли выполнение операций, присущих столбцовым БД (Clickhouse например) в «потоках» с аналогичной стоимостью времени процессора?

[ainu]

Если, честно, пытаюсь придумать несколько кейсов кроме теннисистов. Лайки, например.

[F_AV_N]

Да для любых «плоских» (id и пары ключ: значение) неизменяемых данных (удаляемых «с хвоста») — отличная штука. А ещё в стримах есть группы воркеров с пометками получили-обработали, что позволяет делать эффективную оркестровку с распараллеливанием обработки, например.

[F_AV_N]

Как я понимаю, «нельзя просто так взять», и сагрегировать :)
Например — можно во внешней структуре (в приложении, или в Redis sorted set, если сохранить надо) создать список интервалов, потом для каждого в стриме взять диапазон и суммировать. Можно прямо в Редисе на lua скриптик написать (но тогда для много-данных лучше по интервалу за раз, он блокирующий).
Поиск — в момент, подсчёт — в памяти, так что д.б. недолго. Ну, для lua или UDS коннекта, без накладных на сеть.
Для оценки числа уников есть отдельные структуры (см. loglog). В принципе, Redis — штука отличная по скорости, но много ручной работы :)