La longueur du nom a-t-elle un impact sur les performances dans Redis?

J'aime utiliser des noms verbeux dans Redis, par exemple set-allBooksBelongToUser:$userId.

Est-ce correct ou cela a-t-il un impact sur les performances?

La clé dont vous parlez n'est pas vraiment longue.

L'exemple de clé que vous donnez est pour un ensemble, les méthodes de recherche d'ensemble sont O (1). Les opérations les plus complexes sur un ensemble (SDIFF, SUNION, SINTER) sont O (N). Il est probable que le remplissage $userIdétait une opération plus coûteuse que l'utilisation d'une clé plus longue.

Redis est livré avec un utilitaire de référence appelé redis-benchmark, si vous modifiez le test "GET" dans src / redis-benchmark.c afin que leur clé soit juste "foo", vous pouvez exécuter le test de clé courte après un make install:

diff --git a/src/redis-benchmark.c b/src/redis-benchmark.c
--- a/src/redis-benchmark.c
+++ b/src/redis-benchmark.c
@@ -475,11 +475,11 @@
         benchmark("MSET (10 keys)",cmd,len);
         free(cmd);

-        len = redisFormatCommand(&cmd,"SET foo:rand:000000000000 %s",data);
+        len = redisFormatCommand(&cmd,"SET foo %s",data);
         benchmark("SET",cmd,len);
         free(cmd);

-        len = redisFormatCommand(&cmd,"GET foo:rand:000000000000");
+        len = redisFormatCommand(&cmd,"GET foo");
         benchmark("GET",cmd,len);
         free(cmd);

Voici la vitesse de test GET pour 3 exécutions suivantes de la touche courte "foo":

59880.24 requests per second
58139.53 requests per second
58479.53 requests per second

Voici la vitesse de test GET après avoir modifié à nouveau la source et changé la clé en "set-allBooksBelongToUser: 1234567890":

60240.96 requests per second
60606.06 requests per second
58479.53 requests per second

Changement de la clé une fois de plus en "ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlore

58479.53 requests per second
58139.53 requests per second
56179.77 requests per second

Ainsi, même les touches vraiment très longues n'ont pas un impact important sur la vitesse des redis. Et c'est sur GET, une opération O (1). Des opérations plus complexes y seraient encore moins sensibles.

Je pense qu'avoir des clés qui identifient clairement les valeurs qu'elles détiennent l'emporte largement sur les performances de vitesse minuscules que vous obtiendriez avec des clés abrégées.

Si vous vouliez aller plus loin, il y a aussi un -r [keyspacelen] paramètre sur l'utilitaire redis-benchmark qui lui permet de créer des clés aléatoires (tant qu'elles contiennent ': rand:'), vous pouvez simplement augmenter la taille du préfixe dans le tester le code à la longueur souhaitée.

Redis aime garder toutes les clés en mémoire. Plus la longueur moyenne de votre clé est longue, moins la mémoire peut être conservée. Alors oui, la longueur des clés peut avoir un impact considérable sur les performances, mais probablement pas de manière significative de la manière dont vous êtes concerné. Autrement dit, avec un petit espace de clés (par exemple, celui qui tient facilement dans la mémoire), une clé de 128 octets et une clé de 16 octets ne fonctionneront pas de façon très différente.

Je ne peux pas répondre avec certitude à cette question. Cependant, je peux poser quelques questions à ce sujet et faire quelques observations.

Je pense qu'il est évident que des clés (noms) et / ou des valeurs extrêmement longues auraient un impact sur les performances globales si elles peuvent être utilisées. Ces impacts peuvent être sur le client, sur le réseau ou sur le serveur. Donc, la première question à faire glisser hors de la vôtre serait:

Combien de temps les clés et les valeurs peuvent-elles rester entre Redis et vos clients?

La recherche sur Redis , la longueur des clés et les limites me rapporte une entrée de blog intéressante sur Redis vs Memcached qui peut commencer à répondre à votre question. La première réponse à cette entrée de blog semble avoir été écrite par Salvatore Sanfilipo, créateur de Redis (début de l'automne dernier: 09/2010), suggérant qu'une version plus récente donnerait des résultats nettement meilleurs. Deux commentaires en bas de ce lien nous à Redis / Memcached Benchmark de Salvatore qui a été posté quelques jours après avoir répondu au "blagger" original (qui semble être anonyme).

Cela ne répond pas aux questions (combien de temps les clés peuvent-elles durer et à quels points y a-t-il des impacts détectables sur les performances). Cependant, cela nous donne un indice sur l'approche de la question.

Les auteurs de ces deux articles ont écrit du code et l'ont testé ... et ont représenté graphiquement les résultats.

Nous pourrions faire toutes sortes de suppositions. Nous pourrions examiner le code et essayer de le raisonner.

Cependant, la manière la plus significative d'aborder une question de ce type est d'écrire du code pour mesurer un modèle d'utilisation proposé ... et d'autres pour en tester un autre (par exemple une plage de longueurs de clé allant de 8 caractères à ... comment longtemps voulez-vous ... 8 kilo-octets?) ... et le mesurer.

Je ne pense pas que la longueur du nom de la variable affectera les performances, la variable prendra la même place que toute variable prendra pour ce type de données dans la mesure où vous ne dépassez pas la longueur maximale du nom.