Você não deve se preocupar com a execução do comando atual, mas com o impacto em todos os outros comandos, pois o Redis processa comandos usando um único thread (ou seja, enquanto um comando está sendo executado, todos os outros precisam aguardar até que a execução de um termine).
Enquanto
keys ou scan pode fornecer desempenho semelhante ou idêntico executado sozinho no seu caso, alguns milissegundos bloqueando o Redis diminuirão significativamente a E/S geral. Este é o principal motivo para usar
keys para fins de desenvolvimento e scan em ambientes de produção. OP disse:
"Embora as chaves ou a verificação possam fornecer desempenho semelhante ou idêntico executado sozinho no seu caso, alguns milissegundos bloqueando o Redis diminuirão significativamente a E/S geral." - Esta frase parece indicar que um comando bloqueia o Redis e o outro não, o que não pode ser o caso. Se eu tenho 100 resultados garantidos da minha chamada para o KEYS, de que forma é pior do que SCAN? Por que você acha que um comando é mais propenso a bloquear?
Deve haver uma boa diferença quando você pode paginar a pesquisa. Não é o mesmo ser forçado a obter 100 chaves em uma única passagem do que poder implementar a paginação e obter 100 chaves, 10 por 10 (ou 50 e 50). Essa interrupção muito pequena pode permitir que outros comandos enviados pela camada de aplicativo sejam processados pelo Redis . Veja o que a documentação oficial do Redis diz sobre isso:
Como esses comandos permitem iteração incremental, retornando apenas um pequeno número de elementos por chamada, eles podem ser usados em produção sem a desvantagem de comandos como KEYS ou SMEMBERS que podem bloquear o servidor por muito tempo (até vários segundos) quando chamados contra grandes coleções de chaves ou elementos
.
