Redis 最优哈希集条目大小

Posted 2023-04-17

【中文标题】Redis 最优哈希集条目大小

【英文标题】：Redis optimal hash set entry size

【发布时间】：2014-07-07 18:45:04

【问题描述】：

我对 Redis 哈希集的最佳条目大小设置有一些疑问。

在此示例中 memory-optimization 他们使用 100 个哈希条目 每个键，但使用 hash-max-zipmap-entries 256 ？为什么不 hash-max-zipmap-entry 100 还是 128？

在 redis 网站（以上链接）上，他们使用的最大哈希条目大小为 100 个，但在这篇文章 instagram 中，他们提到了 1000 个条目。所以 这是否意味着最佳设置是乘积的函数 hash-max-zipmap-entries & hash-max-zipmap-value ?（即在这种情况下 Instagram 的哈希值比内存优化示例小？）

非常感谢您的 cmets/澄清。

【问题讨论】：

相关：groups.google.com/forum/#!topic/redis-db/9qM9iSeRAA4

【参考方案1】：

关键是，from here：

处理这些 [ziplist] 结构的紧凑版本会随着它们变长而变慢

和

[随着 ziplist 变长] 获取/更新 HASH 的单个字段，Redis 将不得不解码许多单个条目，并且 CPU 缓存不会那么有效

所以你的问题

此页面仅显示一个示例，我怀疑作者是否考虑过确切的值。在现实生活中，如果您想利用 ziplist，并且您知道每个哈希的条目数小于 100，那么将其设置为 100、128 或 256 将没有任何区别。 hash-max-zipmap-entries 只是您告诉 Redis 将编码从 ziplist 更改为 hash 的 LIMIT。

您的“hash-max-zipmap-entries 和 hash-max-zipmap-value 的乘积”的想法可能有些道理，但我在推测。更重要的是，首先你必须根据你想做的事情来定义“最优”。如果你想在一个大的 ziplist 中做很多 HSET/HGET，它会比你使用散列慢。但是，如果您从不获取/更新单个字段，只对键执行 HMSET/HGETALL，那么大型 ziplist 不会减慢您的速度。 Instagram 1000 是他们根据特定数据、用例和 Redis 函数调用频率得出的最佳数字。

【参考方案2】：

您鼓励我阅读这两个链接，并且您似乎在要求“哈希表大小的默认值”。

我认为不可能说一个数字对所有可能性都是通用的。所描述的机制类似于标准哈希映射。看http://en.wikipedia.org/wiki/Hash_table

如果你的hash表很小，这意味着许多不同的hash值都指向同一个数组，其中equals方法用于查找项目。

另一方面，大哈希表意味着它分配了大量内存以及许多空字段。但这可以很好地扩展，因为该算法使用 O(1) 大 O 表示法并且没有 equals 搜索该项目。

一般来说，恕我直言，表的大小取决于您希望放入表中的所有元素的总数，还取决于键的多样性。我的意思是，如果每个哈希都以“0001”开头，甚至 size=100000 都不会对您有所帮助。