名称长度是否会影响 Redis 中的性能?

本文介绍了名称长度是否会影响 Redis 中的性能?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我喜欢在 Redis 中使用冗长的名称，例如 set-allBooksBelongToUser:$userId.

I like to use verbose names in Redis, for instance set-allBooksBelongToUser:$userId.

这样可以吗，还是会影响性能?

Is this ok or does that impact performance?

推荐答案

您所说的密钥实际上并没有那么长.

The key you're talking about using isn't really all that long.

您提供的示例键用于集合，集合查找方法为 O(1).集合(SDIFF、SUNION、SINTER)上更复杂的操作是 O(N).与使用更长的密钥相比，填充 $userId 的成本可能更高.

The example key you give is for a set, set lookup methods are O(1). The more complex operations on a set (SDIFF, SUNION, SINTER) are O(N). Chances are that populating $userId was a more expensive operation than using a longer key.

Redis 自带了一个名为 redis-benchmark 的基准测试工具，如果你修改 src/redis-benchmark.c 中的GET"测试，让它们的 key 只是foo"，你可以运行make install 后的快捷键测试:

Redis comes with a benchmark utility called redis-benchmark, if you modify the "GET" test in src/redis-benchmark.c so that they key is just "foo", you can run the short key test after a 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);

这是 3 次后续运行的快捷键foo"的 GET 测试速度:

Here's the GET test speed for 3 subsequent runs of the short key "foo":

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

这里是再次修改源码，把key改成set-allBooksBelongToUser:1234567890"后的GET测试速度:

Here's the GET test speed after modifying the source again and changing the key to "set-allBooksBelongToUser:1234567890":

60240.96 requests per second 60606.06 requests per second 58479.53 requests per second

再次改变键 ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem:1234567890" 给出了这样的:

Changing the key yet again to "ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem:1234567890" gives this:

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

所以即使是非常长的键也不会对redis的速度产生很大的影响.这是在 GET 上，一个 O(1) 操作.更复杂的操作对此更不敏感.

So even really really long keys don't have a large impact on the speed of redis. And this is on GET, a O(1) operation. More complex operations would be even less sensitive to this.

我认为，拥有能够清楚地识别出它们所持有的值的键，远胜于您从缩写键中获得的任何微不足道的速度性能.

I think that having keys that clearly identify what values they hold greatly outweighs any minuscule speed performance you'd get out of abbreviated keys.

如果您想更进一步，在 redis-benchmark 实用程序上还有一个 -r [keyspacelen] 参数，可以让它创建随机密钥(只要它们有 ':rand:'在它们中)，您可以将测试代码中前缀的大小增加到您想要的任何长度.

If you wanted to take this further, there's also a -r [keyspacelen] parameter on the redis-benchmark utility that lets it create random keys (as long as they have ':rand:' in them), you could just increase the size of the prefix in the testing code to whatever length you wanted.