Redéfinir les conventions de nommage des clés?

Quelle est la convention de dénomination 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 en mesure d'interroger uniquement le début de la clé pour renvoyer tous les utilisateurs?

J'espère simplement éviter tout problème futur en recherchant les méthodes qui fonctionnent pour les gens et pourquoi ils les ont choisis.

Quelle est la convention de dénomination 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.

Oui, le signe deux-points :est une convention pour nommer les clés. Dans ce tutoriel sur le site Web de redis, il est indiqué: Essayez de vous en tenir à un schéma. Par exemple, "object-type: id: field" peut être une bonne idée, comme dans "user: 1000: password". J'aime utiliser des points pour les champs de plusieurs mots, comme dans "commentaire: 1234: reply.to".

Êtes-vous en mesure d'interroger uniquement le début de la clé pour renvoyer tous les utilisateurs?

Si vous voulez dire quelque chose comme interroger directement toutes les clés qui commence par user:il y a une commande de touches pour cela. Cette commande ne doit cependant être utilisée qu'à des fins de débogage car elle est O (N) car elle recherche dans toutes les clés stockées dans la base de données.

La solution la plus appropriée à ce problème consiste à créer une clé dédiée, nommons est users, qui stockera toutes les clés des utilisateurs, par exemple, dans une structure de données de liste ou de jeu .

Nous utilisons un deux-points (:) comme séparateur d'espace de noms et un hachage (#) pour les parties id des clés, par exemple:

logistics:building#23

Une convention semble être deux points (:) mais je suis développeur web, donc je préfère personnellement la barre oblique (/) pour le séparateur. La barre oblique est déjà un séparateur si important dans les URL qui sont censées être des localisateurs de ressources uniformes, donc des clés pour les ressources. Pourquoi adopter une approche différente avec deux points (:)? Est-ce que ça aide quelque chose?

Considérez cet exemple:

Nous avons une API RESTful pour les objets jouets. Il y en a un:

http://example.com/api/toy/234 

Où l'avons-nous stocké? Nous utilisons Redis et slashs donc la clé est évidente:

toy/234

C'est la clé unique du jouet. La clé peut désormais également être utilisée côté client:

{
    key: "toy/234",
    color: "red",
    url: function () {
        return API_BASE_URL + this.key;
    }
}

Un utilisateur demande un objet avec clé toy/666. Comment l'obtenir auprès de Redis? Un exemple lié à Node.js:

redis.get(key, function reply_callback(error, toystring) {
    var toy = JSON.parse(toystring);
    ...
}

Pas besoin de convertir les barres obliques en deux points et vice versa. Pratique, tu ne crois pas?

Remarque: assurez-vous toujours que l'utilisateur ne peut accéder qu'aux éléments que vous vouliez. L'approche URL-à-clé brute ci-dessus peut également être récupérée user/1/password, comme l'ont noté les commentateurs. Cela ne devrait pas poser de problème si vous utilisez Redis comme cache public en lecture seule.

Je ne sais pas s'il existe vraiment encore de "meilleures pratiques" répandues pour la dénomination des clés Redis.

J'ai expérimenté l'utilisation de caractères ASCII NUL comme séparateurs (puisque Redis et Python sont tous deux propres en 8 bits). Cela a l'air un peu moche si vous regardez des clés brutes, mais l'idée est de les cacher derrière une couche d'abstraction. Les deux-points et les symboles de tuyau sont des alternatives évidentes tant que les composants de votre espace de nom sont garantis de ne pas les utiliser ou que vous êtes prêt à encoder chaque composant si nécessaire. Cependant, si vous les encodiez, vous voudriez développer la couche d'abstraction et éviter de voir les clés brutes de toute façon ... ce qui m'a ramené à l'utilisation de \ 0 dans mon raisonnement.

Je serai intéressant de voir si d'autres opinions sont exprimées à ce sujet.

Pour votre utilisation, il me semble que HSET / HGET conviendrait mieux. Il existe également la commande HKEYS .

Toutes ces commandes ont la même complexité que GET / SET / KEYS, alors pourquoi ne pas les utiliser?

Vous pourriez alors avoir cette structure:

• utilisateurs> 00> valeur
• utilisateurs> 01> valeur

ou:

• utilisateurs: nom d'utilisateur> 00> valeur
• utilisateurs: nom d'utilisateur> 01> valeur

Il suffit d'extraire l'ID de l'utilisateur et de l'utiliser comme clé de hachage. Personnellement, je préfère cette approche car elle est plus agréable et vous pouvez également facilement rechercher des ID utilisateur existants.