Redis设置vs散列

在许多Redis教程中(比如这个 ),数据存储在一个集合中,但是多个值组合在一起形成一个string(例如,一个用户帐户可能被存储在集合中作为两个条目“user:1000:username” “用户:1000:密码”)。

不过,Redis也有哈希。 似乎有一个“用户:1000”哈希,其中包含一个“用户名”条目和一个“密码”条目更有意义。 而不是连接string来访问一个特定的值,你可以直接在哈希中访问它们。

那为什么不用它呢? 这些只是老的教程? 还是Redis哈希有性能问题?

Redis哈希值可以存储更复杂的数据,就像你在你的问题中提出的那样。 我完全使用它们来存储具有需要caching的多个属性的对象(具体来说,是电子商务网站上特定产品的库存数据)。 当然,我可以使用连接的string – 但是这增加了我的客户端代码的不必要的复杂性,更新单个字段是不可能的。

你可能是对的 – 教程可能只是从哈希引入之前。 他们清楚地devise用于存储对象表示: http : //oldblog.antirez.com/post/redis-weekly-update-1.html

我猜想一个问题是Redis在插入一个新项目(n个命令,其中n是哈希中的字段数目)和简单的String SET命令相比时必须服务的命令的数量。 我还没有发现这是一个服务,每天大约有一百万次冲击Redis。 对我来说使用正确的数据结构比可忽略的性能影响更重要。

(另外,请参阅我的有关Redis集与Redisstring的评论 – 我认为你的问题是指string,但如果我错了,请纠正我的错误!)

哈希是在Redis中存储数据的最有效的方法之一,甚至可以在有效的时候推荐它们使用。

http://redis.io/topics/memory-optimization

尽可能使用散列

小哈希编码在一个非常小的空间,所以你应该尝试使用散列表示你的数据每一次都是可能的。 例如,如果在Web应用程序中有代表用户的对象,而不是使用名称,姓氏,电子邮件,密码的不同密钥,则使用带有所有必填字段的单个散列。