Oui, les ensembles triés sont très rapides et puissants. Ils semblent mieux correspondre à vos besoins que SORT opérations. La complexité temporelle est souvent mal comprise. O(log(N)) est très rapide et s'adapte très bien. Nous l'utilisons pour des dizaines de millions de membres dans un ensemble trié. La récupération et l'insertion sont inférieures à la milliseconde.
Utilisez la clé ZRANGEBYSCORE key min max WITHSCORES [LIMIT offset count] pour obtenir vos résultats.
Selon la façon dont vous stockez les horodatages en tant que "scores", ZREVRANGEBYSCORE peut être préférable.
Une petite remarque sur les horodatages :Ensemble trié SCORES qui n'ont pas besoin de partie décimale doivent utiliser 15 chiffres ou moins. Donc le SCORE doit rester dans la plage -999999999999999 à 999999999999999. Remarque :ces limites existent car le serveur Redis stocke en fait le score (flottant) sous forme de chaîne redis en interne.
Je recommande donc ce format, converti en Zulu Time :-20140313122802 pour la seconde précision. Vous pouvez ajouter 1 chiffre pour une précision de 100 ms, mais pas plus si vous ne voulez aucune perte de précision. Soit dit en passant, il s'agit toujours d'un float64, donc la perte de précision peut convenir dans certains scénarios, mais votre cas correspond à la plage de "précision parfaite", c'est donc ce que je recommande.
Si vos données expirent dans les 10 ans, vous pouvez également ignorer les trois premiers chiffres (CCY de CCYY) pour obtenir une précision de 0,0001 seconde.
Je suggère des scores négatifs ici, vous pouvez donc utiliser le plus simple ZRANGEBYSCORE au lieu du REV une. Vous pouvez utiliser -inf comme score de départ (moins l'infini) et LIMIT 0 100 pour obtenir les 100 meilleurs résultats.
Deux ensembles members triés (ou 'keys' mais c'est ambigu puisque l'ensemble trié est aussi une clé en soi) peut partager un score , ce n'est pas un problème, les résultats dans un score identique sont alphabétiques.
J'espère que cela vous aidera, TW
Modifier après le chat
L'OP voulait collecter des données (en utilisant un ZSET ) à partir de différentes clés (GET /SET ou HGET /HSET clés). JOIN peut le faire pour vous, ZRANGEBYSCORE ne peut pas. La manière préférée de le faire est un simple script Lua. Le script Lua est exécuté sur le serveur. Dans l'exemple ci-dessous, j'utilise EVAL pour plus de simplicité, en production, vous utiliseriez SCRIPT EXISTS , SCRIPT LOAD et EVALSHA . La plupart des bibliothèques clientes ont une logique de comptabilité intégrée, vous n'avez donc pas à télécharger le script à chaque fois.
Voici 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
Vous l'utilisez comme ceci (exemple brut, non codé pour la performance) :
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
Résultat :
1) "1"
2) "act1JSON"
3) "2"
4) "act2JSON"
