问题描述
我喜欢在 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.
这篇关于名称长度是否会影响 Redis 中的性能?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!