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

226

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.

redis naming-conventions

— fantaisie
source

205

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 .

— yojimbo87
source

1

scann'est pas l'option @EranH., c'est la meilleure pratique pour itérer les clés. scanest utilisé pour effectuer une itération incrémentielle sur une collection d'éléments.

— Kishor Pawar

2

@ yojimbo87 Il y aura donc deux commandes, disons que la première consiste à créer une clé comme - utilisateur: 808021: mot de passe = XYZ et la seconde consiste à mettre la clé dans le registre ou l'index (ensemble), mais que se passera-t-il lorsqu'une commande sera exécutée avec succès et autre obtient échoué signifie que les clés ont été créées mais ne sont pas entrées dans le registre.

— LoveToCode

1

@LoveToCode Vous pouvez utiliser une transaction qui devrait garantir que toutes ou aucune des opérations seront exécutées.

— yojimbo87

2

J'ai également remarqué que Redis Desktop Manager (un outil client Redis) traite également les deux points ':' comme séparateur et affiche plusieurs clés regroupées

— Adam Rotaru

1

Je suis d'avis que la valeur unique doit être la dernière. Rend facile de faire quelque chose comme:$redis->delete($redis->keys('user:password:*'));

— Crayons

26

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

— Le clou
source

Quelle est la meilleure convention de nom si vous avez plus de clés comme les paramètres régionaux, la catégorie, etc.? {ressource}: {clé} # {valeur}, {clé} # {valeur} => textes: locale # en, catégorie # 15? Ou vous avez une autre suggestion?

— fsasvari

1

Dans mon exemple, «bâtiment» n'est que le nom de la «collection», et 23 est le «id» personnalisé. Si vous avez un identifiant composite avec locale = en et catégorie = 15, l'id réel pourrait être {en, 15}, donc namespace: textes # {en, 15}, ou pour être plus verbeux: namespace: textes # {locale = en, catégorie = 15}. Mais ce n'est qu'une idée, je ne l'ai jamais utilisé comme ça. Attention à ne pas changer l'ordre des éléments id, car la clé ne sera bien sûr pas trouvée. En fait, au lieu d'encoder une telle complexité dans vos noms de clés, envisagez plutôt d'utiliser des structures de données redis. Jetez un œil à redis.io/topics/indexes

— The Nail

16

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.

— Akseli Palén
source

24

… Pratique, et d'une insécurité presque dégoûtante . Vous suppliez de vous en procurer curl http://example.com/api/user/1/password, ou similaire. (Je dis juste.)

— ELLIOTTCABLE

3

Les deux-points, les hachages et les barres obliques peuvent être utilisés pour désigner différents niveaux d'imbrication, par exempleUser#23:uploads:my/path/to/file.ext

— incarné

31

Veuillez ne jamais prendre la saisie de l'utilisateur comme clé dans la base de données.

— Lyle

1

J'aime la façon dont vous pensiez préférer les barres obliques parce que vous êtes développeur Web.

— Hector Ordonez

@ELLIOTTCABLE Merci, ajout d'une note sur les insécurités. Voyez-vous un problème dans cette approche si Redis est utilisé comme cache public en lecture seule?

— Akseli Palén

6

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.

— Jim Dennis
source

0

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.

— in vitro
source