Не трябва да се интересувате от текущото изпълнение на командата, а от въздействието върху всички други команди, тъй като Redis обработва команди с помощта на една нишка (т.е. докато се изпълнява една команда, всички останали трябва да изчакат, докато изпълнението на едната приключи).
Докато keys или scan може да ви осигури подобна или идентична производителност, изпълнявана самостоятелно във вашия случай, някои милисекунди блокирането на Redis значително ще намали общия I/O.
Това е основната причина да използвате keys за целите на разработката и scan в производствени среди.
OP каза:
„Докато ключовете или сканирането може да ви осигурят подобна или идентична производителност, изпълнявана самостоятелно във вашия случай, няколко милисекунди блокиране на Redis значително ще намалят общия I/O.“ - Това изречение изглежда показва, че едната команда блокира Redis, а другата не, което не може да бъде така. Ако имам гарантирани 100 резултата от моето обаждане до KEYS, с какво е по-лошо от SCAN? Защо смятате, че една команда е по-склонна към блокиране?
Трябва да има добра разлика, когато можете да пагинирате търсенето. Не е същото да си принуден да получиш 100 ключа в един проход, отколкото да можеш да приложиш пагинация и да получиш 100 ключа, 10 по 10 (или 50 и 50). Това много малко прекъсване може да позволи на други команди, изпратени от слоя на приложението, да бъдат обработвани от Redis . Вижте какво казва официалната документация на Redis за това:
Тъй като тези команди позволяват постепенна итерация, връщайки само малък брой елементи на извикване, те могат да се използват в производството без недостатъка на команди като KEYS или SMEMBERS, които могат да блокират сървъра за дълго време (дори няколко секунди), когато се извикат срещу големи колекции от ключове или елементи
.
