Les conventions de nommage des clés Redis?
Quelle est la convention d'appellation normale pour les clés dans redis? J'ai vu des valeurs séparées par : mais je ne sais pas quelle est la convention normale, ni pourquoi.
pour un utilisateur feriez-vous quelque chose comme...
user:00
si l'identifiant de l'utilisateur était 00
Êtes-vous capable d'interroger pour juste le début de la clé pour retourner tous les utilisateurs?
j'espère surtout pour éviter tout problème futur en recherchant les façons qui fonctionnent pour les gens et pourquoi ils les ont choisis.
4 réponses
Quelle est la convention d'appellation normale pour les clés dans redis? J'ai vu valeurs séparées par : Mais je ne suis pas sûr de ce que la convention normale est, ou pourquoi.
Oui, deux-points : est une convention de nommage des touches. Dans ce tutoriel sur le site redis est écrit: essayez de vous en tenir à un schéma. Par exemple "object-type:id:champ" peut être
une bonne idée, comme dans "user: 1000: password". J'aime utiliser points pour
champs de plusieurs mots, comme dans " comment: 1234: reply.to".
Êtes-vous en mesure d'interroger pour juste le début de la clé pour retourner tous les utilisateurs?
si vous voulez dire quelque chose comme demander directement pour toutes les clés qui commence par user: il y a une commande clés pour cela. Cette commande ne doit cependant être utilisée qu'à des fins de débogage puisque c'est O(N) parce qu'il cherche dans toutes les clés de la base de données.
la solution la plus appropriée pour ce problème est de créer la clé dédiée, le nom est users , qui stockera toutes les clés utilisateurs, par exemple, dans liste ou ensemble structure de données.
nous utilisons deux points (:) comme séparateur d'espace de noms et un hachage (#) pour id-parties de clés, par exemple:
logistics:building#23
Une convention semble être les deux-points (:) mais je suis un développeur web donc, personnellement, je préfère la barre oblique (/) pour le séparateur. Slash est déjà si important séparateur dans les URLs qui sont censés être localisateurs de ressources Uniformes sorte de clés pour les ressources. Pourquoi adopter une approche différente avec colon (:)? Est-ce que ça aide quelque chose?
considérons cet exemple:
Nous avons une "1519150920 de" repos API pour les objets jouets. Il y en a un:
http://example.com/api/toy/234
où l'avons-nous stocké? Nous utilisons Redis et slashes de sorte que la clé est évidente:
toy/234
C'est la clé unique pour le jouet. La clé peut maintenant être utilisée aussi du côté du client:
{
key: "toy/234",
color: "red",
url: function () {
return API_BASE_URL + this.key;
}
}
Un utilisateur demande un objet avec la touche toy/666 . Comment L'obtenir de Redis? nœud.exemple relatif à js:
redis.get(key, function reply_callback(error, toystring) {
var toy = JSON.parse(toystring);
...
}
pas besoin de convertissez slashes en colons et vice versa. Pratique, vous ne pensez pas?
Note: assurez-vous toujours que l'utilisateur est en mesure d'accéder uniquement à ce que vous avez prévu. l'approche brute URL-to-key ci-dessus est capable de récupérer user/1/password aussi, comme l'ont noté les commentateurs. Cela ne devrait pas poser de problème si vous utilisez Redis comme cache en lecture seule.
Je ne sais pas s'il existe vraiment des" pratiques exemplaires " répandues pour la désignation des clés Redis.
j'ai expérimenté l'utilisation de caractères ASCII NUL comme séparateurs (depuis Redis et Python sont tous les deux 8-bit clean). Il semble un peu moche si vous regardez des clés brutes, mais l'idée est de le cacher derrière une couche d'abstraction. Les symboles de côlon et de pipe sont des alternatives évidentes tant que les composants de votre espace de nom sont soit garantis de ne pas les utiliser ou vous êtes prêt à encoder chaque composant au besoin. Cependant, si vous voulez les encoder, vous devriez développer la couche d'abstraction et éviter de regarder les clés brutes de toute façon ... ce qui m'a ramenée à l'utilisation de \0 dans mon raisonnement.
il sera intéressant de voir si d'autres opinions sont exprimées à ce sujet.