Quali sono le normali convenzioni di denominazione per le chiavi in redis? Ho visto valori separati da :ma non sono sicuro di quale sia la normale convenzione o perché.
Per un utente faresti qualcosa come ...
user:00
se l'ID dell'utente era 00
Sei in grado di richiedere solo l'inizio della chiave per restituire tutti gli utenti?
Spero principalmente di evitare eventuali problemi futuri ricercando i modi in cui funzionano le persone e perché le hanno scelte.
Risposte:
Quali sono le normali convenzioni di denominazione per le chiavi in redis? Ho visto valori separati da: ma non sono sicuro di quale sia la normale convenzione o perché.
Sì, il segno dei due punti :è una convenzione durante la denominazione delle chiavi. In questo tutorial sul sito web di redis è indicato: prova a seguire uno schema. Ad esempio "tipo-oggetto: id: campo" può essere una buona idea, come in "utente: 1000: password". Mi piace usare i punti per i campi multi-parole, come in "comment: 1234: reply.to".
Sei in grado di richiedere solo l'inizio della chiave per restituire tutti gli utenti?
Se intendi qualcosa come interrogare direttamente tutte le chiavi che iniziano con user:c'è un comando keys per quello. Questo comando deve tuttavia essere utilizzato solo a scopo di debug poiché è O (N) perché cerca in tutte le chiavi impostate nel database.
La soluzione più appropriata per questo problema è quella di creare una chiave dedicata users, per esempio, che memorizzerà tutte le chiavi degli utenti, ad esempio, nell'elenco o impostando la struttura dei dati.
$redis->delete($redis->keys('user:password:*'));
Usiamo i due punti (:) come separatore dello spazio dei nomi e un hash (#) per le parti id delle chiavi, ad esempio:
logistics:building#23
Una convenzione sembra essere due punti (:) ma io sono uno sviluppatore web quindi personalmente preferisco la barra (/) per il separatore. La barra è già un separatore così importante all'interno degli URL che sono destinati a essere individuatori di risorse uniformi, quindi un tipo di chiave per le risorse. Perché adottare un approccio diverso con i due punti (:)? Aiuta qualcosa?
Considera questo esempio:
Abbiamo un'API RESTful per oggetti giocattolo. Ce n'è uno:
http://example.com/api/toy/234
Dove lo abbiamo archiviato? Usiamo Redis e barre quindi la chiave è ovvia:
toy/234
Questa è la chiave unica per il giocattolo. La chiave ora può essere utilizzata anche sul lato client:
{
key: "toy/234",
color: "red",
url: function () {
return API_BASE_URL + this.key;
}
}
Un utente richiede un oggetto con chiave toy/666. Come ottenerlo da Redis? Un esempio relativo a Node.js:
redis.get(key, function reply_callback(error, toystring) {
var toy = JSON.parse(toystring);
...
}
Non è necessario convertire le barre in due punti e viceversa. Conveniente, non credi?
Nota: assicurarsi sempre che l'utente sia in grado di accedere solo alle cose che intendevi. L'approccio raw URL-to-key sopra è anche in grado di recuperare user/1/password, come notato dai commentatori. Questo non dovrebbe essere un problema se si utilizza Redis come cache pubblica di sola lettura.
curl http://example.com/api/user/1/password, o simili. (Solo dicendo.)
User#23:uploads:my/path/to/file.ext
Non so ancora se ci siano davvero "best practice" diffuse per la denominazione dei tasti Redis.
Ho sperimentato l'uso di caratteri ASCII NUL come miei separatori (poiché Redis e Python sono entrambi puliti a 8 bit). Sembra un po 'brutto se stai guardando i tasti grezzi, ma l'idea è di nasconderlo dietro uno strato di astrazione. I simboli di due punti e di pipe sono ovvie alternative purché i componenti del tuo spazio dei nomi siano garantiti o non li usino o sei disposto a codificare ogni componente secondo necessità. Tuttavia, se dovessi codificarli, vorrai sviluppare il livello di astrazione ed evitare comunque di visualizzare le chiavi non elaborate ... il che mi ha riportato a usare semplicemente \ 0 nel mio ragionamento.
Sarò interessante vedere se ci sono altre opinioni su questo.
Per il tuo caso, mi sembra che HSET / HGET si adatterebbe meglio. C'è anche il comando HKEYS .
Tutti questi comandi hanno la stessa complessità di GET / SET / KEYS, quindi perché non usarli?
Potresti avere questa struttura quindi:
o:
Basta estrarre l'ID dell'utente e usarlo come chiave hash. Personalmente preferisco questo approccio perché sembra più bello e puoi anche facilmente cercare gli ID utente esistenti.
scannon è l'opzione @EranH., è la migliore pratica per iterare le chiavi.scanviene utilizzato per iterare in modo incrementale una raccolta di elementi.