Ако искате скорост, трябва да се подготвите колкото е възможно повече, когато съхранявате структурата или 'кеша' в redis. Ако съхранявате продуктите в HSET , и добавете броячите на категории (по един за категория) до члена на „продуктови данни“ в този HSET , можете да използвате HINCRBY за увеличаване/намаляване на броячите.
Като цяло (проектиране на Redis кеш за вашите нужди):трябва да се опитате да предотвратите извличането на данни, които не са ви необходими.
Препоръчвам да използвате Lua скрипт за съхраняване (/актуализиране/изтриване), както и за извличане на обобщения ви отчет. Lua скриптовете се изпълняват на Redis сървъра. ServiceStack ги поддържа (SCRIPT LOAD + EVALSHA или просто EVAL ), а можете също да опитате клиентския модул BookSleeve C# (който ние използваме и е малко по-бърз. 'faster' :добрият дизайн на redis-данните е на първо място, разбира се). Клиентът BookSleeve C# се фокусира върху многонишковия редис конвейер, което вероятно е това, което искате, когато работите с големи набори от данни. Конвейерът трябва да е възможен и със ServiceStack.
Ако категориите и продуктите имат целочислен идентификатор, можете също да го комбинирате с ZSET , където можете да използвате идентификатора като поле за оценка. С ZRANGEBYSCORE можете директно да получите „записа“. Тази техника е безопасна, стига идентификационните ви данни да използват 15 цифри или по-малко и да не използвате десетичната част на „резултата“. Така че идентификационният номер трябва да остане в диапазона -999999999999999 до 999999999999999. Забележка:Тези ограничения съществуват, защото Redis сървърът всъщност съхранява резултата (float) като представяне на redis-низ вътрешно.
Надявам се това да помогне, TW
