redis - Redis 集合与哈希

Question

在许多 Redis 教程（例如这个）中，数据存储在一个集合中，但多个值组合在一个字符串中（即用户帐户可能作为两个条目存储在集合中，“user:1000:username”和“用户：1000：密码”）。

但是，Redis 也有哈希。似乎拥有一个“user:1000”散列会更有意义，其中包含一个“用户名”条目和一个“密码”条目。您无需连接字符串来访问特定值，而是直接在哈希中访问它们。

那么为什么不使用那么多呢？这些只是旧教程吗？还是 Redis 哈希有性能问题？

Answer 1

Redis 哈希非常适合存储更复杂的数据，就像您在问题中建议的那样。我正是用它们来存储具有多个需要缓存的属性的对象（特别是电子商务网站上特定产品的库存数据）。当然，我可以使用串联的字符串——但这会给我的客户端代码增加不必要的复杂性，并且无法更新单个字段。

你可能是对的——这些教程可能只是在引入哈希之前。它们显然是为存储对象表示而设计的：http: //oldblog.antirez.com/post/redis-weekly-update-1.html

我想一个问题是与简单的 String SET 命令相比，插入新项目时 Redis 必须服务的命令数量（n 个命令，其中 n 是哈希中的字段数）。我还没有发现这对每天访问 Redis 约 100 万次的服务来说是个问题。对我来说，使用正确的数据结构比对性能的影响可以忽略不计更重要。

（另外，请参阅我关于 Redis Sets 与 Redis Strings 的评论 - 我认为您的问题是指字符串，但如果我错了，请纠正我！）

Answer 2

哈希是在 Redis 中存储数据的最有效方法之一，甚至建议尽可能有效地使用它们。

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

尽可能使用哈希

小散列被编码在一个非常小的空间中，因此您应该尝试尽可能使用散列来表示您的数据。例如，如果您在 Web 应用程序中有代表用户的对象，而不是对姓名、姓氏、电子邮件、密码使用不同的键，而是使用包含所有必填字段的单个哈希。

Answer 3

用例比较：

Sets 提供了一个语义接口来将数据作为一个集合存储在 Redis 服务器中。此类数据的用例更多用于分析目的，例如有多少人浏览产品页面以及有多少人最终购买了该产品。

哈希提供了一个语义接口来在 Redis 服务器中存储简单和复杂的数据对象。例如，用户资料、产品目录等。

参考：学习 Redis