我正在使用redis为我的Web应用程序实现社交流和通知系统。我是redis的新手，我对哈希及其效率有一些怀疑。
我读过这篇很棒的Instagram post 我计划实施类似的解决方案以实现最小存储。
正如他们在博客中提到的，他们确实喜欢这个
为了利用散列类型，我们将所有媒体ID分配到1000个桶中（我们只取ID，除以1000并丢弃剩余部分）。这决定了我们陷入的关键;接下来，在生成该密钥的散列内，介质ID是散列中内的查找键，用户ID是值。一个例子，给定媒体ID为1155315，这意味着它属于桶1155（1155315/1000 = 1155）：
HSET "mediabucket:1155" "1155315" "939"
HGET "mediabucket:1155" "1155315"
> "939"
所以，不要使用 1000个单独的密钥，而是将它存储在一个具有千个查找键的哈希中。 我怀疑是我们为什么不能将查找键值增加到更大的原因。
例如： Media ID of 1155315 will fall into mediabucket:115 by dividing it by 10000
甚至更大。
为什么他们使用一个带有1000个查找键的哈希桶来解决问题。为什么他们不能拥有一个具有100000个查找键的哈希桶。这与效率有关吗？
我需要您在我的网络应用程序中实现有效方法的建议。
P.S。请！不要说stackoverflow不是用于询问建议而我不知道在哪里可以找到帮助。
谢谢！
答案 0 :(得分：6)
是的，这与效率有关。
我们向Redis的核心开发人员之一总是有帮助的Pieter Noordhuis提出了意见，他建议我们使用Redis哈希。 Redis中的哈希是字典，可以非常有效地编码在内存中; Redis设置'hash-zipmap-max-entries'配置散列可以有效编码的最大条目数。我们发现这个设置最好在1000左右;任何更高的HSET命令都会引起明显的CPU活动。有关更多详细信息，请查看zipmap源文件。
小哈希以特殊方式（zipmaps）编码，这是内存效率高，但是操作O（N）而不是O（1）。因此，使用一个包含100k字段的zipmap而不是包含1k字段的100个zipmaps，您将获得无内存优势，但所有操作都会慢100倍。
答案 1 :(得分：2)
基本上，他们希望存储在单个哈希值中的值的数量不超过1000.可能，他们将Redis实例配置设置为与此数字（您的集合hash-zipmap-max-entries）很好地协作。
每次哈希值超过指定的元素数量或元素大小时，它都会被转换为真实的哈希表，并且内存保存将会丢失。
- http://redis.io/topics/memory-optimization
据我了解，你的问题是“为什么只有1000而不是更多？”嗯，这是因为他们必须在空间效率和速度之间做出选择。节省空间的表示具有操作复杂度O(N)，而非O(1)作为正常哈希值 - N倍慢，但占用的内存更少。
他们测试了不同的值，发现1000是一个很好的折衷解决方案 - 占用的空间不大，但仍然足够快。