我对Redis哈希集的最佳条目大小设置有一些疑问。
在此示例memory-optimization中，它们使用100个哈希条目 每个键但使用hash-max-zipmap-entries 256？为什么不 hash-max-zipmap-entries 100或128？
在redis网站（上面的链接）上，他们使用了最大哈希条目大小 100，但在这篇文章instagram中，他们提到了1000个条目。所以 这是否意味着最佳设置是产品的函数 hash-max-zipmap-entries＆amp; hash-max-zipmap-value？（即在这种情况下 Instagram的哈希值比内存优化示例小？）
非常感谢您的评论/澄清。
答案 0 :(得分：0)
您鼓励我阅读这两个链接，似乎您要求“哈希表大小的默认值”。
我认为不可能说一个数字对所有可能性都是通用的。所描述的机制类似于标准散列映射。看http://en.wikipedia.org/wiki/Hash_table
如果散列表的大小很小，则意味着许多不同的散列值指向同一个数组，其中 equals 方法用于查找项目。
另一方面，大型哈希表意味着它会分配大量内存以及许多空字段。但是这可以很好地扩展，因为算法使用O（1）大O表示法，并且没有等于搜索项目。
一般来说，表IMHO的大小取决于您希望放入表中的所有元素的总数，它还取决于密钥的多样性。我的意思是，如果每个哈希以“0001”开头，甚至大小= 100000都不会对你有帮助。
答案 1 :(得分：0)
关键是，from here：
操纵这些[ziplist]结构的紧凑版本会随着它们变长而变慢
和
[随着ziplists变长]获取/更新HASH的各个字段，Redis必须解码许多单独的条目，并且CPU缓存不会那么有效
那么你的问题
此页面只显示了一个示例，我怀疑作者对确切的值进行了很多考虑。在现实生活中，如果你想利用ziplists，并且你知道每个哈希的条目数<100，那么将它设置为100,128或256将没有任何区别。 hash-max-zipmap-entries只是您告诉Redis将编码从ziplist更改为哈希值的限制。
您的＆＃34; hash-max-zipmap-entries＆amp;产品中可能有一些道理。散列-MAX-zipmap值＆＃34;想法，但我猜测。更重要的是，首先你必须定义＆＃34;最佳＆＃34;根据你想做的事情。如果你想在一个大的ziplist中做很多HSET / HGET，它会比你使用哈希更慢。但是，如果你永远不会获得/更新单个字段，只需要在密钥上进行HMSET / HGETALL，那么大型拉链列表不会减慢你的速度。 Instagram 1000是基于THEIR特定数据，用例和Redis函数调用频率的最佳数字。