Si desea velocidad, debe prepararse tanto como sea posible al almacenar la estructura o 'caché' en redis. Si almacena los productos en un HSET y agregue los contadores de categoría (uno por categoría) junto con su miembro de 'datos de producto' en este HSET , puede usar HINCRBY para incrementar/decrementar los contadores.
En general (diseñando un caché de Redis para sus necesidades):debe intentar evitar la recuperación de datos que no necesita.
Recomiendo usar un script de Lua para almacenar (/actualizar/eliminar) y recuperar su informe agregado. Los scripts de Lua se ejecutan en el servidor Redis. ServiceStack los admite (SCRIPT LOAD + EVALSHA o simplemente EVAL ), y también puede probar el módulo de cliente BookSleeve C# (que usamos, y es un poco más rápido. 'más rápido' :un buen diseño de datos de redis es lo primero, por supuesto). El cliente BookSleeve C# se centra en la canalización de redis de subprocesos múltiples, que es probablemente lo que desea cuando se trata de grandes conjuntos de datos. La canalización también debería ser posible con ServiceStack.
Si las categorías y los productos tienen un ID de número entero, también puede combinarlo con un ZSET , donde puede utilizar el ID como campo de puntuación. Con un ZRANGEBYSCORE puede obtener directamente el 'registro'. Esta técnica es segura siempre que su identificación use 15 dígitos o menos, y no use la parte decimal de la 'puntuación'. Por lo tanto, el ID debe 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.
Espero que esto ayude, TW
