Si vous voulez de la vitesse, vous devez vous préparer autant que possible lors du stockage de la structure ou du "cache" dans redis.Si vous stockez les produits dans un HSET , et ajoutez les compteurs de catégorie (un par catégorie) à côté de votre membre "données produit" dans ce HSET , vous pouvez utiliser HINCRBY pour incrémenter/décrémenter les compteurs.
En général (concevoir un cache Redis pour vos besoins) :vous devriez essayer d'empêcher la récupération de données dont vous n'avez pas besoin.
Je recommande d'utiliser un script Lua pour stocker (/mettre à jour/supprimer) ainsi que pour récupérer votre rapport agrégé. Les scripts Lua sont exécutés sur le serveur Redis. ServiceStack les supporte (SCRIPT LOAD + EVALSHA ou simplement EVAL ), et vous pouvez également essayer le module client BookSleeve C# (que nous utilisons et qui est un peu plus rapide. 'faster' :une bonne conception des données redis vient bien sûr en premier). Le client BookSleeve C# se concentre sur le pipelining redis multithread, ce qui est probablement ce que vous voulez lorsque vous traitez de grands ensembles de données. Le pipelining devrait également être possible avec ServiceStack.
Si les catégories et les produits ont un ID entier, vous pouvez également le combiner avec un ZSET , où vous pouvez utiliser l'ID comme champ de score. Avec un ZRANGEBYSCORE vous pouvez obtenir directement le « record ». Cette technique est sûre tant que vos ID utilisent 15 chiffres ou moins et n'utilisez pas la partie décimale du « score ». Ainsi, l'ID doit rester dans la plage -999999999999999 à 999999999999999. Remarque :ces limites existent car le serveur Redis stocke en fait le score (flottant) sous la forme d'une représentation de chaîne redis en interne.
J'espère que cela vous aidera, TW
