Redis - 使用哈希表

Question

我正在使用Redis为我的Web应用程序实现社交流和通知系统。我对Redis不是很熟悉，对哈希及其效率有些疑问。

我阅读了这篇精彩的Instagram帖子，并计划实现类似于他们的最小存储解决方案。

正如他们博客中提到的那样，他们像这样做：

为了利用哈希类型，我们将所有媒体ID分成1000个桶（只需取ID，除以1000并丢弃余数）。这确定了我们落入哪个键；接下来，在该键所在的哈希内，媒体ID是哈希内的查找键，而用户ID是值。例如，给定Media ID 1155315，这意味着它落入桶1155（1155315 / 1000 = 1155）：

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

所以，他们不是使用1000个单独的键，而是将其存储在一个具有千个查找键的哈希表中。我的疑问是为什么我们不能增加查找键值到更大。

例如：将1155315的媒体ID除以10000后会落入mediabucket:115中甚至更大。

为什么他们只使用一个具有1000个查找键的哈希桶？为什么不能使用一个具有100000个查找键的哈希桶？这是否与效率有关？

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

P.S.请！不要说stackoverflow不适合提出建议，我不知道在哪里寻求帮助。

谢谢！

- rnk

Answer 1

是的，这与效率有关。

我们向Redis核心开发人员之一，总是乐于助人的Pieter Noordhuis寻求帮助，他建议我们使用Redis哈希。在Redis中，哈希是可以在内存中非常高效地编码的字典；Redis设置“hash-zipmap-max-entries”配置哈希表最大条目数，同时保持高效编码。我们发现，该设置最好在1000左右；如果更高，HSET命令将导致明显的CPU活动。有关更多详细信息，请参阅zipmap源文件。

小哈希以特殊方式（zipmaps）进行编码，这是存储效率很高的一种方式，但会使操作变为O(N)，而不是O(1)。因此，使用具有100k个字段的一个zipmap而不是具有1k个字段的100个zipmap不会获得任何记忆优势，但所有操作都会变慢100倍。

- Sergio Tulentsev

---

谢谢，那我就选1000吧 :) - rnk

Answer 2

基本上，他们希望单个哈希中存储的值的数量不超过1000。可能，他们设置了Redis实例配置以使其与此数字良好配合（他们设置hash-zipmap-max-entries）。

每次哈希超过指定的元素或元素大小时，它都会转换为真正的哈希表，内存节省也会丢失。

-- http://redis.io/topics/memory-optimization 据我所知，你的问题是“为什么恰好是1000而不是更多？”嗯，这是因为他们必须在空间效率和速度之间选择。空间效率表示操作复杂度为O（N），而不是普通哈希的O（1） - 它比普通哈希慢N倍，但占用的内存较少。

他们测试了不同的值，并发现1000是一个很好的折衷方案 - 占用空间不多，但仍然足够快。

- scriptin

---

谢谢，那我就选1000吧 :) - rnk

@rnk 你可以测试哪个值最适合你的任务。 - scriptin