Redis最佳哈希集条目大小

Question

我有一些关于Redis哈希集合最佳入口大小设置的问题。

1. 在这个例子memory-optimization中，他们每个键使用100个哈希条目，但使用hash-max-zipmap-entries 256？为什么不是hash-max-zipmap-entries 100或128？
2. 在redis网站（上面的链接）中，他们使用了最大的哈希条目大小为100，但在这篇文章instagram中，他们提到了1000个条目。那么这是否意味着最佳设置是hash-max-zipmap-entries和hash-max-zipmap-value的乘积函数？（即在这种情况下，Instagram具有比内存优化示例更小的哈希值？）

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

- user28958

---

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

Answer 1

关键在于，从这里开始：

随着这些[ziplist]结构变得越来越长，操作它们的紧凑版本可能变得缓慢。

以及

当ziplists变得越来越长时，获取/更新HASH的单个字段将需要解码许多单个条目，并且CPU缓存效果不佳。

所以回答你的问题：

1. 这个页面只是展示一个例子，我怀疑作者没有考虑具体的数值。在实际应用中，如果你想利用ziplists，并且你知道每个哈希表的条目数小于100，则将其设置为100、128或256没有任何区别。hash-max-zipmap-entries仅是超过此限制时，你告诉Redis从ziplist更改编码为哈希表的限制。

2. 你的"hash-max-zipmap-entries和hash-max-zipmap-value的乘积"的想法可能有一定的道理，但我只是推测。更重要的是，首先你必须根据你想要做什么来定义"最优"。如果你想在一个大的ziplist中进行大量的HSET/HGET操作，那么它会比使用哈希表慢。但是，如果你从不获取/更新单个字段，只对一个键进行HMSET/HGETALL操作，大型ziplists不会减慢你的速度。Instagram的1000是基于他们特定的数据、用例和Redis函数调用频率的最佳数量。

- poshest

Answer 2

你鼓励我阅读了两个链接，看起来你正在询问“哈希表大小的默认值”。

我认为不可能有一个适用于所有情况的通用数字。所描述的机制类似于标准哈希映射。请参考http://en.wikipedia.org/wiki/Hash_table

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

另一方面，大型哈希表意味着它分配了大量的内存以及许多空字段。但是，由于算法使用O（1）大O符号，并且没有对项进行equals搜索，因此这很好地扩展。

总的来说，表的大小在我看来取决于您希望放入表中的所有元素的总数，也取决于关键字的多样性。我的意思是，如果每个哈希都以“0001”开头，即使大小为100000也无济于事。

- Martin Podval