Redis最佳哈希集条目大小

Question

关于Redis哈希集的最佳条目大小设置，我有一些问题。

1. 在本例中，内存优化每个键使用100个哈希条目，但使用散列-max-zipmap-条目256？为什么不散列-最大-zipmap-条目100或128？
2. 在redis网站上(上面的链接)，他们使用了最大哈希条目大小为100，但在这篇文章Instagram中，他们提到了1000个条目。那么，这是否意味着最优设置是散列-max-zipmap-条目&散列-max-zipmap-值的乘积的函数？(也就是说，在本例中，Instagram的哈希值比内存优化示例的哈希值小吗？)

非常感谢你的评论/澄清。

Answer 1

关键是，从这里开始

操纵这些ziplist结构的紧凑版本可能会变得缓慢，因为它们会增长得更长。

和

随着压缩器获取/更新散列单个字段的时间越来越长，Redis将不得不对多个单独的条目进行解码，而CPU缓存就不会那么有效了。

所以对于你的问题

1. 这一页只展示了一个例子，我怀疑作者是否考虑过确切的值。在现实生活中，如果您想要利用ziplist，并且您知道每个散列的条目数是<100，那么将其设置为100、128或256将没有什么区别。hash-max-zipmap-entries只是告诉Redis将编码从ziplist更改为散列的限制。
2. 也许在你的“哈希-最大-压缩映射-条目的产物-哈希-最大-压缩映射-值”的想法中可能有一些事实，但我在猜测。更重要的是，首先你必须根据你想要做的事情来定义“最优”。如果您想在大型ziplist中执行大量的HSET/HSET，它将比使用散列时慢。但是，如果您从来没有得到/更新单个字段只做HMSET/HGETALL上的一个键，大型拉链不会减慢您的速度。Instagram 1000是它们基于特定数据、用例和Redis函数调用频率的最佳数量。

Answer 2

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

我认为不可能说一个数字对所有可能性都是普遍的。所描述的机制类似于标准哈希映射。看看表格

如果哈希表的大小很小，则意味着许多不同的哈希值指向同一个数组，在该数组中使用equals方法查找项。

另一方面，大型哈希表意味着它将分配大量内存和许多空字段。但是，由于算法使用了O(1)大O表示法，并且没有相等的搜索项，所以这个算法的缩放性很好。

一般来说，IMHO的大小取决于您希望放入表中的所有元素的总数，也取决于键的多样性。我的意思是，如果每个散列都以"0001“开头，那么即使是size=100000也不会对您有所帮助。