Est-ce que le nom a un impact sur la performance de Redis?

La clé dont vous parlez n’est pas si longue.

La clé que vous donnez comme exemple est 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 $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 qu’il ne s’agisse que de “foo”, vous pouvez exécuter le test de clé courte après une make install :

 diff --git a/src/redis-benchmark.cb/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 ultérieures de la touche “foo”:

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

Voici la vitesse de test GET après modification de la source et modification de 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é à “ipsumlore-kipsumlore-diphosporiphosporiphosporiphospor-radioporédelipiphLoripalipsliporiphénolipérylsipènoriphoriquesiphlorophéniquesiphlorophénolipiphloriques

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

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

Je pense que le fait d’avoir des touches identifiant clairement les valeurs qu’elles contiennent l’emporte largement sur les performances minuscules que vous obtiendriez des clés abrégées.

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

Redis aime garder toutes les clés en mémoire. Plus votre longueur de clé moyenne est longue, moins vous pouvez en conserver en mémoire. Donc, oui, la longueur de la clé peut avoir un impact considérable sur les performances, mais probablement pas de manière significative en ce qui concerne votre préoccupation. Autrement dit, avec un petit espace de touches (par exemple, un espace qui se glisse facilement dans la mémoire), une clé de 128 octets et une clé de 16 octets ne fonctionneront pas de manière très différente.

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

Je pense qu’il est évident que des clés extrêmement longues (noms) et / ou des valeurs auront un impact sur les performances si elles peuvent être utilisées. Ces impacts peuvent être sur le client, sur le réseau ou sur le serveur. La première question à vous poser serait donc la suivante:

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

En cherchant sur Redis , la longueur de la clé et les limites, je trouve un article de blog intéressant sur Redis vs memcached qui pourrait 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 nous ont permis de trouver le benchmark Redis / memcached de Salvatore 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 durer et à quels points y a-t-il des impacts détectables sur les performances). Cependant, cela nous donne une idée de l’approche de la question.

Les auteurs de ces deux articles ont écrit le 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 manière la plus significative d’aborder une question de ce type consiste à écrire du code pour mesurer un modèle d’utilisation proposé … et un autre à en tester un autre (par exemple, une gamme de longueurs de clés allant de 8 caractères à … long 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 n’importe quelle variable pour ce type de données dans la mesure où vous ne dépassez pas la longueur maximale du nom.