How does the length of the redis key name affect performance?

the key name is too long, and the performance is not good. Everyone says that it is too short to memorize and read. I looked at the longest key I used. Is it long? How much does it affect performance? How to evaluate it? Is how to test performance?

Apr.01,2021

official articles: Redis keys chapter of An introduction to Redis data types and abstractions
original text:

Redis keys are binary safe, this means that you can use any binary sequence as a key, from a string like "foo" to the content of a JPEG file. The empty string is also a valid key.

A few other rules about keys:

  • Very long keys are not a good idea. For instance a key of 1024 bytes is a bad idea not only memory-wise, but also because the lookup of the key in the dataset may require several costly key-comparisons. Even when the task at hand is to match the existence of a large value, hashing it (for example with SHA1) is a better idea, especially from the perspective of memory and bandwidth.
  • Very short keys are often not a good idea. There is little point in writing "u1000flw" as a key if you can instead write "user:1000:followers". The latter is more readable and the added space is minor compared to the space used by the key object itself and the value object. While short keys will obviously consume a bit less memory, your job is to find the right balance.
  • Try to stick with a schema. For instance "object-type:id" is a good idea, as in "user:1000". Dots or dashes are often used for multi-word fields, as in comment:1234:reply.to or comment:1234:reply-to .

The maximum allowed key size is 512 MB.

I translated this article:
Redis in-depth series-introduction to 0x014:Redis data types and concepts 0x001 Redis key chapter

Redis's key is bit-safe, which means you can use any binary sequence as key, from strings like foo to the contents of a JPEG file. Even an empty string is fine.

there are some other rules about key:

  • very long key is not recommended. A 1024 bytes is a very bad idea, not only because of memory waste, but also because it costs more to search for comparisons in a dataset. When you are dealing with matching a very large value, it is better to use the hash value of this value from a memory and bandwidth perspective (for example, using SHA1 ).
  • very short key is usually not recommended. When writing keys like u100flw, there is a small point that we can use user:1000:followers instead. The increased footprint for key objects and value objects is secondary to the fact that it is more readable. When a short key can significantly reduce space footprint, your job is to find the right balance
  • try to fix a secret room. For example, object-type:id is a good idea. It is usually used for fields with multiple characters, such as comment:1234:reply.to , or comment:1234:reply-to .
  • maximum key allows 512MB

the above is for reference only

The key used by

can be as short as possible while ensuring that it can indicate what data is stored.
for example, key= "article_view_top_10" represents the 10 most viewed articles.
50 characters is long. I've used redis for such a long time, and I really haven't used such a long key.
the dike of thousands of miles is destroyed by the ant nest, and the impact on the performance is mostly, which has not been evaluated. A long key means more memory, which means it takes more time to find a match, and in many cases, just follow the specification.

MySQL Query : SELECT * FROM `codeshelper`.`v9_news` WHERE status=99 AND catid='6' ORDER BY rand() LIMIT 5
MySQL Error : Disk full (/tmp/#sql-temptable-64f5-1e46b17-438ff.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")
MySQL Errno : 1021
Message : Disk full (/tmp/#sql-temptable-64f5-1e46b17-438ff.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")
Need Help?