Sí, los conjuntos ordenados son muy rápidos y potentes. Parecen una mejor combinación para sus requisitos que SORT operaciones. La complejidad del tiempo a menudo se malinterpreta. O(log(N)) es muy rápido y escala muy bien. Lo usamos para decenas de millones de miembros en un conjunto ordenado. La recuperación y la inserción son submilisegundos.
Use ZRANGEBYSCORE key min max WITHSCORES [LIMIT offset count] para obtener sus resultados.
Dependiendo de cómo almacene las marcas de tiempo como 'puntuaciones', ZREVRANGEBYSCORE podría ser mejor.
Un pequeño comentario sobre las marcas de tiempo:conjunto ordenado SCORES que no necesitan una parte decimal deben usar 15 dígitos o menos. Entonces el SCORE tiene que permanecer en el rango de -999999999999999 a 999999999999999. Nota:estos límites existen porque el servidor de Redis realmente almacena la puntuación (flotante) como una representación de cadena redis internamente.
Por lo tanto, recomiendo este formato, convertido a Zulu Time:-20140313122802 para segunda precisión. Puede agregar 1 dígito para una precisión de 100 ms, pero no más si usted no quiere pérdida de precisión. Por cierto, sigue siendo un float64, por lo que la pérdida de precisión podría estar bien en algunos escenarios, pero su caso se ajusta al rango de "precisión perfecta", así que eso es lo que recomiendo.
Si sus datos vencen dentro de los 10 años, también puede omitir los tres primeros dígitos (CCY de CCYY), para lograr una precisión de 0,0001 segundos.
Sugiero puntajes negativos aquí, para que pueda usar el ZRANGEBYSCORE más simple en lugar de REV uno. Puede usar -inf como la puntuación inicial (menos infinito) y LIMIT 0 100 para obtener los 100 mejores resultados.
Dos members de conjuntos ordenados (o 'keys' pero eso es ambiguo ya que el conjunto ordenado también es una clave en sí mismo) puede compartir una score , no hay problema, los resultados dentro de una score idéntica son alfabéticos.
Espero que esto ayude, TW
Editar después del chat
El OP quería recopilar datos (usando un ZSET ) de diferentes claves (GET /SET o HGET /HSET llaves). JOIN puede hacer eso por ti, ZRANGEBYSCORE no se puede. La forma preferida de hacer esto es un simple script Lua. El script Lua se ejecuta en el servidor. En el siguiente ejemplo, uso EVAL para simplificar, en producción usaría SCRIPT EXISTS , SCRIPT LOAD y EVALSHA . La mayoría de las bibliotecas de clientes tienen una lógica de contabilidad incorporada, por lo que no carga el script cada vez.
Aquí hay un example.lua :
local r={}
local zkey=KEYS[1]
local a=redis.call('zrangebyscore', zkey, KEYS[2], KEYS[3], 'withscores', 'limit', 0, KEYS[4])
for i=1,#a,2 do
r[i]=a[i+1]
r[i+1]=redis.call('get', a[i])
end
return r
Lo usa así (ejemplo sin procesar, no codificado para el rendimiento) :
redis-cli -p 14322 set activity:1 act1JSON
redis-cli -p 14322 set activity:2 act2JSON
redis-cli -p 14322 zadd feed 1 activity:1
redis-cli -p 14322 zadd feed 2 activity:2
redis-cli -p 14322 eval '$(cat example.lua)' 4 feed '-inf' '+inf' 100
Resultado:
1) "1"
2) "act1JSON"
3) "2"
4) "act2JSON"
