web-dev-qa-db-fra.com

La longueur du nom affecte-t-elle les performances dans Redis?

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

Est-ce correct ou cela affecte-t-il les performances?

120
Running Turtle

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). Les chances sont que le peuplement $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 sorte que leur clé soit juste "foo", vous pouvez exécuter le test de touche 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 à nouveau modifié 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

Changer de nouveau la clé en "ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlore

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

Ainsi, même des touches 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 clés qui identifient clairement les valeurs qu'elles détiennent l'emporte largement sur les performances de vitesse minuscules que vous obtiendriez des clés abrégées.

Si vous voulez 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 code de test à la longueur souhaitée.

181
Ted Naleid

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

26
bmatheny

Je ne peux pas répondre à cette question avec certitude. 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 pouvaient être utilisées. Ces impacts peuvent être sur le client, sur le réseau ou sur le serveur. La première question à tirer de la vôtre serait donc:

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

La recherche sur Redis, longueur de clé et limites me donne 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 montrerait des résultats nettement meilleurs. Deux commentaires de ce lien nous relient à Salvatore Redis/memcached Benchmark qui a été publié 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 être 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 regarder le code et essayer de le raisonner.

Cependant, la façon 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 voulez-vous longtemps ... 8 kilo-octets?) ... et la mesurer.

4
Jim Dennis