Redis 集合与哈希答案

【问题标题】：Redis set vs hashRedis 集合与哈希
【发布时间】：2012-11-13 11:18:10
【问题描述】：

在许多 Redis 教程（例如this one）中，数据存储在一个集合中，但多个值组合在一起形成一个字符串（即一个用户帐户可能作为两个条目存储在集合中，“user:1000 :username" 和 "user:1000:password")。

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

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

【问题讨论】：

我认为您指的是命令 SET，它实际上是使用字符串数据类型。它只是一个键/值对，而不是实际的 Sets 数据类型（使用 SADD 添加到集合中）。
你是对的，它使用的是 SET 命令。我没有意识到这是一个单独的数据类型，但这是有道理的。
不知道性能差异，写小基准测试github.com/logrusorgru/redisbm 但是不同的hash参数（比如字段数）返回不同的结果。并且 set/get 并不总是较慢。

标签： redis

【解决方案1】：

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

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

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

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

【讨论】：

嗨，迈克，有两个问题。首先，每天 100 万次点击大约是 12 次请求/秒，使用 Redis 基准，您可以在低端 EC2 机器上看到 30K 或在高端笔记本电脑上看到 120K。每秒超过 12 次怎么样？你认为如果你每秒有几千个 SET 会比 HASH 更好吗？第二个问题是关于您所说的“n 个命令，其中 n 是哈希中的字段数”，如果您需要存储具有两个参数的项目，它将是 SET 的 2 倍，用于单独存储与哈希相同，如果它做同样的事情。你确定 HASH 对 Redis 的影响与它的领域一样多吗？ tnx

【解决方案2】：

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

尽可能使用哈希

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

【讨论】：

【解决方案3】：

用例比较：

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

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

【讨论】：