Non dovresti preoccuparti dell'esecuzione corrente del comando, ma dell'impatto su tutti gli altri comandi, poiché Redis elabora i comandi utilizzando un singolo thread (cioè mentre un comando viene eseguito, tutti gli altri devono attendere fino al termine dell'esecuzione).
Mentre keys o scan potrebbe fornirti prestazioni simili o identiche eseguite da solo nel tuo caso, alcuni millisecondi che bloccano Redis ridurranno significativamente l'I/O complessivo.
Questo è il motivo principale per utilizzare keys per scopi di sviluppo e scan sugli ambienti di produzione.
OP ha detto:
"Mentre le chiavi o la scansione potrebbero fornire prestazioni simili o identiche eseguite da sole nel tuo caso, alcuni millisecondi che bloccano Redis diminuiranno significativamente l'I/O complessivo." - Questa frase sembra indicare che un comando blocca Redis e l'altro no, il che non può essere il caso. Se mi vengono garantiti 100 risultati dalla mia chiamata a KEYS, in che modo è peggio di SCAN? Perché ritieni che un comando sia più incline al blocco?
Dovrebbe esserci una buona differenza quando puoi impaginare la ricerca. Non è lo stesso essere costretti a ottenere 100 chiavi in un unico passaggio che essere in grado di implementare l'impaginazione e ottenere 100 chiavi, 10 per 10 (o 50 e 50). Questa piccolissima interruzione può consentire a Redis di elaborare altri comandi inviati dal livello dell'applicazione . Guarda cosa dice la documentazione ufficiale di Redis a riguardo:
Poiché questi comandi consentono l'iterazione incrementale, restituendo solo un piccolo numero di elementi per chiamata, possono essere utilizzati in produzione senza lo svantaggio di comandi come KEYS o SMEMBERS che possono bloccare il server per molto tempo (anche diversi secondi) se chiamati contro grandi raccolte di chiavi o elementi
.
