Комментарии 5
Насколько я помню, sortedset'ы — самое медленное, что есть в редисе.
Не было мысли (в случае конечности весов, например только 1,2...10) создать десяток обычных очередей и опрашивать их по очереди, начиная с queue1?

ИМХО, вышло бы быстрее.
Upd: прозевал, что вес — это время события (timestamp?). Имхо, стоило бы усложнить систему очередей — да хоть создавать поминутные очереди и обрабатывать их в зависимости от текущего ts, но это позволило бы уйти от rangebyscore.
Предложение на каждую минуту (срабатывания события) заводить свою очередь?
Как предполагается получать ключи этих очередей? Скажем, если у нас был простой 5 минут, то нам надо получить 5 ключей листов и последовательно их обработать.
Я правильно понимаю?

Приблизительно так.
Простой можно проверять, например, по очереди, в которую сложены обработанные минуты.
Насколько я помню, оверхед на создание новой очереди минимален, а вот быстродействие будет таки O(1) (ну точнее, от количества запросов к очередям) у очереди против O(log(N)+M) в вашем варианте.

Подскажите, а как-нибудь решали проблему конкурентного чтения из SortedSet?
Или сканеры работают только в один поток?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.