redis - 使用哈希 [英] redis - Using Hashes

问题描述

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

我已经阅读了这个真棒 Instagram的帖子
我计划实现他们的类似解决方案最小化存储。

正如他们的博客中所提到的，他们这样做是这样的。

要利用哈希类型，我们将所有我们的媒体ID存储到1000的桶中（我们只需取ID，除以1000，丢弃余数）。这决定了我们陷入的关键接下来，在该密钥的散列中，媒体ID是哈希中的查找密钥，用户ID是该值。一个例子，由于媒体ID为1155315，这意味着它属于第1155卷（1155315/1000 = 1155）：

  HSETmediabucket：11551155315939
 HGETmediabucket：11551155315
> 939
  

所以，而不是拥有 1000个单独的密钥，它们正在存储在一个具有千个查找键的哈希中。而我的怀疑是为什么我们无法将查找键值增加到更大的位置。

例如： 媒体ID为1155315将落入mediabucket：115除以10000
或甚至更大。

为什么他们用一个具有1000个查找键的哈希桶进行安置。为什么他们不能有一个具有100000查询键的哈希桶。这是否与效率相关？

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

PS请！不要说stackoverflow不是要求建议，我不知道在哪里找到帮助。

谢谢！

解决方案

是的，这与效率有关。

我们问过永远有用的Pieter Noordhuis，Redis的核心开发人员之一，他的投入，他建议我们使用Redis哈希。 Redis中的哈希是可以非常有效地在内存中编码的字典; Redis设置'hash-zipmap-max-entries'配置哈希可以在有效编码的情况下具有的最大条目数。我们发现这个设置最好是1000左右;任何更高的和HSET命令将导致明显的CPU活动。有关详细信息，可以查看zipmap源文件。

小哈希值以特殊方式编码（zipmaps），即记忆效率高，但使O（N）代替O（1）。所以，使用一个zip贴图，100k字段，而不是100个zipmaps与1k字段，你没有获得记忆的好处，但所有的操作都慢了100倍。

I'm implementing a social stream and a notification system for my web application by using redis. I'm new to redis and I have some doubts about hashes and their efficiency.

I've read this awesome Instagram post and I planned to implement their similar solution for minimal storage.

As mentioned in their blog, they did like this

To take advantage of the hash type, we bucket all our Media IDs into buckets of 1000 (we just take the ID, divide by 1000 and discard the remainder). That determines which key we fall into; next, within the hash that lives at that key, the Media ID is the lookup key within the hash, and the user ID is the value. An example, given a Media ID of 1155315, which means it falls into bucket 1155 (1155315 / 1000 = 1155):

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

So Instead of having 1000 seperate keys they are storing it in one hash with thousand lookup keys. And my doubt is why can't we increase the lookup key values to even more larger.

For eg: Media ID of 1155315 will fall into mediabucket:115 by dividing it by 10000 or even greater than that.

Why are they settling with one hash bucket with 1000 lookup keys. Why can't they have one hash bucket with 100000 lookup keys. Is that related to efficiency?

I need your suggestion for implementing the efficient method in my web application.

P.S. Please! don't say that stackoverflow is not for asking suggestions and I don't know where to find help.

Thanks!

解决方案

Yes, it's related to efficiency.

We asked the always-helpful Pieter Noordhuis, one of Redis’ core developers, for input, and he suggested we use Redis hashes. Hashes in Redis are dictionaries that are can be encoded in memory very efficiently; the Redis setting ‘hash-zipmap-max-entries’ configures the maximum number of entries a hash can have while still being encoded efficiently. We found this setting was best around 1000; any higher and the HSET commands would cause noticeable CPU activity. For more details, you can check out the zipmap source file.

Small hashes are encoded in a special way (zipmaps), that is memory efficient, but makes operations O(N) instead of O(1). So, with one zipmap with 100k fields instead of 100 zipmaps with 1k fields you gain no memory benefits, but all your operations get 100 times slower.

这篇关于redis - 使用哈希的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！