La longueur des noms a-t-elle un impact sur les performances de Redis ?

Question

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

Est-ce que cela est correct ou est-ce que cela a un impact sur les performances ?

Answer 1

La clé que vous voulez utiliser n'est pas si longue que ça.

L'exemple de clé que vous donnez est pour un ensemble, les méthodes de recherche d'ensemble sont O(1). Les opérations plus complexes sur un ensemble (SDIFF, SUNION, SINTER) sont O(N). Il y a de fortes chances que le remplissage de $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 de manière à ce que la clé soit simplement "foo", vous pouvez exécuter le test de la 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 du test GET pour 3 exécutions successives de la touche courte "foo" :

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

Voici la vitesse du 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

En changeant encore une fois la clé en "ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem : 1234567890" donne ceci :

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

Ainsi, même les clés vraiment très longues n'ont pas un grand impact sur la vitesse de redis. Et ceci est sur GET, une opération O(1). Des opérations plus complexes seraient encore moins sensibles à cela.

Je pense que le fait d'avoir des touches qui identifient clairement les valeurs qu'elles contiennent l'emporte largement sur les minuscules gains de vitesse que vous obtiendriez avec des touches abrégées.

Si vous voulez aller plus loin, il y a aussi un -r [keyspacelen] 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 code de test à la longueur que vous voulez.

Answer 2

Redis aime garder toutes les clés en mémoire. Plus la longueur moyenne de votre clé est longue, moins elle peut être conservée en mémoire. Donc oui, la longueur de la clé peut avoir un impact important sur les performances, mais probablement pas de manière significative dans le sens où vous êtes concerné. En d'autres termes, avec un petit espace de clés (par exemple, un espace qui tient facilement en mémoire), une clé de 128 octets et une clé de 16 octets n'auront pas des performances très différentes.

Answer 3

Je ne peux pas répondre à cette question avec certitude. Cependant, je peux poser quelques questions à ce sujet et proposer 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 tant est qu'elles puissent être utilisées. Ces impacts pourraient être dans le client, sur le réseau, ou sur le serveur. La première question à vous poser serait donc la suivante :

Quelle peut être la durée des clés et des valeurs entre Redis et vos clients ?

Recherche sur Redis , longueur des clés y limites me permet de trouver un article de blog intéressant sur Redis contre memcached ce qui peut commencer à répondre à votre question. La première réponse à cet article de blog semble avoir été écrite par Salvatore Sanfilipo, créateur de Redis (au début de l'automne dernier : 09/2010), suggérant qu'une version plus récente donnerait de bien meilleurs résultats. Deux commentaires plus bas de ce lien nous amènent à l'article de Salvatore. Benchmark Redis/memcached qui a été posté quelques jours après qu'il ait répondu au "blagger" original (qui semble être anonyme).

Cela ne répond pas aux questions (combien de temps peuvent durer les clés et à partir de quel moment il y a des impacts détectables sur les performances). Cependant, il nous donne un indice pour aborder la question.

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

On pourrait faire toutes sortes de suppositions. Nous pourrions regarder le code et essayer de le raisonner.

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

Answer 4

Je ne pense pas que la longueur du nom de la variable affectera les performances, la variable prendra la même place que n'importe quelle variable pour ce type de données, tant que vous ne dépassez pas la longueur maximale du nom.