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

129

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?

Tortue en cours d'exécution
la source

Réponses:

198

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.

Ted Naleid
la source
6
et combien d'espace cela prend-il? si j'ai 1 million de ces clés vraiment longues, sera-ce beaucoup plus gros en mémoire ou persistant sur le disque?
Derek Organ
9
@Derek Organ oui, cela aurait certainement un impact sur la mémoire occupée, donc si vos clés représentent une partie importante de ce que vous stockez et que vous rencontrez des limitations de mémoire, vous voudrez peut-être être moins verbeux. Je pense que vous devez trouver un équilibre entre la convivialité et les considérations d'espace. Le temps de recherche global n'est pas beaucoup plus long avec les clés, mais l'espace occupé le serait.
Ted Naleid
Nous utilisons généralement les longueurs de clé les plus courtes possibles et déplaçons la «lisibilité» vers nos objets de domaine et leurs méthodes. Nous utilisons également des espaces de noms courts dans nos clés pour faciliter la maintenance et l'inspection directement dans Redis.
xentek
26

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.

bmatheny
la source
4
Redis est par définition un magasin tout-en-mémoire, donc la première phrase me laisse perplexe.
Lee Grissom
5
@bmatheny, si je comprends bien votre requête, Redis est fondamentalement un magasin en mémoire, et il prend également en charge la persistance
Najeeb
5

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.

Jim Dennis
la source
-7

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.

aime l'informatique
la source
6
Charlie: ce ne sont pas vraiment des "variables" ce sont des clés. Pour les clés entre 1 et 30 ou 100, voire 255 caractères, il se peut qu'il n'y ait pas d'impact détectable sur les performances. Créez des clés de quelques kilo-octets ... ou jusqu'à des dizaines de kilo-octets et j'imagine que vous serez en mesure de mesurer un impact sur les performances (à un moment donné entre 1K et 70K, vous aurez une surcharge réseau supplémentaire car la taille de la clé sera dépasser votre MTU et les données devront être fractionnées sur plusieurs paquets ... entraînant au moins une surcharge de TCP et de réassemblage).
Jim Dennis