redis - 使用哈希

我正在使用 redis 为我的 Web 应用程序实现社交流和通知系统。我是 redis 的新手，我对哈希值及其效率有一些疑问。

我读过这篇很棒的文章Instagram 帖子 http://instagram-engineering.tumblr.com/post/12202313862/storing-hundreds-of-millions-of-simple-key-value-pairs我计划实施他们类似的解决方案以实现最小存储。

正如他们的博客中提到的，他们确实喜欢这样

为了利用哈希类型，我们将所有媒体 ID 放入 1000 个桶中（我们只取出 ID，除以 1000 并丢弃余数）。这决定了我们属于哪个键；接下来，在该键所在的哈希中，媒体 ID 是查找键within哈希值，用户 ID 就是值。举个例子，假设媒体 ID 为 1155315，这意味着它属于存储桶 1155 (1155315 / 1000 = 1155)：

HSET "mediabucket:1155" "1155315" "939"
HGET "mediabucket:1155" "1155315"
> "939"

所以而不是有1000 个独立钥匙他们将其存储在具有一千个查找键的一个哈希. And my doubt这就是为什么我们不能将查找键值增加到更大。

For eg: Media ID of 1155315 will fall into mediabucket:115 by dividing it by 10000甚至比这个还要大。

为什么他们选择使用一个包含 1000 个查找键的哈希桶。为什么他们不能有一个包含 100000 个查找键的哈希桶。这与效率?

我需要您的建议来在我的网络应用程序中实现有效的方法。

附：请！不要说 stackoverflow 不是用来寻求建议的，我不知道在哪里可以找到帮助。

Thanks!

是的，这和效率有关。

我们向总是乐于助人的 Redis 核心开发人员之一 Pieter Noordhuis 寻求意见，他建议我们使用 Redis 哈希。 Redis 中的哈希是可以在内存中非常高效地编码的字典； Redis 设置“hash-zipmap-max-entries”配置哈希在仍能有效编码的情况下可以拥有的最大条目数。我们发现此设置在 1000 左右最佳；任何更高的值和 HSET 命令都会导致明显的 CPU 活动。有关更多详细信息，您可以查看 zipmap 源文件。

小散列以特殊方式（zipmap）进行编码，这种方式内存效率高，但操作复杂度为 O(N) 而不是 O(1)。因此，使用一个包含 100k 字段的 zipmap，而不是使用 100 个包含 1k 字段的 zipmap，您不会获得任何内存优势，但所有操作都会慢 100 倍。