名字的长度会影响 Redis 的表现吗？

我喜欢在 Redis 使用冗长的名称，例如 ABc0。

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

50812 次浏览
小开

我不认为变量名的长度会影响性能，只要你不超过最大名称长度，变量就会和数据类型的任何变量一样占据相同的位置。

小开

我不能肯定地回答这个问题。然而，我可以提出一些问题，并提供一些意见。

我认为，如果可以使用极长的键(名称)和/或值，那么它们显然会对整体性能产生影响。这些影响可能发生在客户机、网络或服务器上。所以你要问的第一个问题是:

Redis 和您的客户端之间的键和值可以保持多长时间？

搜索 雷迪斯，按键长度和 限制让我在 Redis VS memcached上有一个有趣的博客条目，它可能会开始回答你的问题。对这篇博文的第一反应似乎是由 Redis (去年秋初: 09/2010)的创始人 Salvatore Sanfilipo 写的，他认为更新的版本会显示出更好的结果。从那个链接下来的两个评论，我们到塞尔瓦托的 Redis/memcached 基准测试，这是几天后，他回应了最初的“黑客”(似乎是匿名的)。

这并没有回答这些问题(键可以有多长，以及在哪些点对性能有可检测的影响)。然而，它给了我们一个关于如何处理这个问题的线索。

这两篇文章的作者都编写了代码并对其进行了测试... ... 并绘制了结果图表。

我们可以做各种各样的猜测，我们可以查看代码并试图推理出来。

然而，处理这类问题最有意义的方法是编写一些代码来度量一个提议的使用模式... ... 还有一些代码用来测试另一个(例如，一系列关键字长度，从8个字符到... ... 你想要多长... ... 8千字节... 和测量它。

小开
最佳答案

你说的那把钥匙其实没那么长。

您给出的示例键为 set，set 查找方法为 O (1)。集合上更复杂的操作(SDIFF，SUNION，sINTER)是 O (N)。填充 $userId的操作很可能比使用较长的键更昂贵。

Redis 附带了一个名为 redis-benchmark的基准实用程序，如果您修改 src/Redis-bench mark.c 中的“ GET”测试，以便它们的键值只是“ foo”，那么您可以在 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 测试速度:

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

下面是再次修改源代码并将密钥更改为“ set-allBooksBelongToUser: 1234567890”后的 GET 测试速度:

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

再次将键改为“ ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlosumlosumloreipsumlosumlololoreipsumlololololololoreipsumloreipsumlosumlo

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

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

我认为，拥有能够清楚识别它们所持有的值的键，要大大超过从缩写键获得的任何微不足道的速度性能。

如果你想更进一步，在 redis 基准测试工具中还有一个 -r [keyspacelen]参数，它允许创建随机密钥(只要它们中有’: rand:’) ，你可以只增加测试代码中前缀的大小，以任何你想要的长度。

小开

Redis 喜欢掌握内存中的所有键。键的平均长度越长，内存中可以保存的内容就越少。因此，是的，键长度可以极大地影响性能，但可能不会对您所关心的方式产生重大影响。也就是说，对于一个小的密钥空间(例如一个容易放入内存的密钥空间) ，一个128字节的密钥和一个16字节的密钥的性能不会有很大的不同。


提交答案