3

Redis 小书解释了如何通过电子邮件地址查找用户 ID，以便您可以通过用户 ID 查找用户哈希并获取完整的用户对象。它实际上是通过电子邮件地址对用户的索引。每次插入新用户时，您只需添加到查找哈希中，如下所示：

set users:9001 "{id: 9001, email: leto@dune.gov, ...}"
hset users:lookup:email leto@dune.gov 9001

在我看来，此操作涉及 Redis 必须执行的哈希内的隐藏查找，以提取所需电子邮件字段的值。可能有数千个电子邮件字段，我们只要求其中一个。

如何在索引键中使用电子邮件，如下所示：

set users:9001 "{id: 9001, email: leto@dune.gov, ...}"
set users:lookup:email:leto@dune.gov 9001

因为这在 Redis 小书中没有建议，所以我认为这不是最佳实践。

谁能解释为什么第一种方法更好？它们实际上是一样的吗？

谢谢，我正在学习Redis。

4

1 回答 1

5

在我看来，每种方法都有自己的优点和缺点：

哈希方法：

  • 您可以相当快地获得所有电子邮件（键）或 ID（值）的列表（O(N)，其中 N 是地图中的条目数）
  • 对于少量条目，它将非常节省内存（虽然很小，可能不适用于任何实际用例）
  • 您被限制为 2^32-1 个条目（同样，可能不是问题，除非您计划让地球上的大多数人使用您的应用程序）
  • 稍微慢一点，因为 redis 需要进行两次 O(1) 查找而不是一次...
  • 对分片不友好，因为它们都将在同一个 redis 实例中。

关键方法：

  • 条目数量没有限制
  • 尽可能快
  • 只能使用KEYO(n) 获取所有用户的列表（对于数据库中的每个条目 - 对于实时环境来说是一个很大的禁忌）
  • 分片友好

这些都是我能想到的差异。除非出于某种原因我需要列出所有用户，否则我倾向于使用 key 方法，只是因为它更直接并且可以通过分片更好地扩展。

顺便说一句，如果可以避免，我可能不会将 JSON 数据存储为用户数据，因为将字段存储在哈希中可能会更节省内存。此外，您可以只获取和设置您真正需要的字段，而不是整个 blob。也可以在没有事务的情况下以原子方式对哈希进行增量，这很有用。但这一切都取决于您的数据......如果您有一个大型嵌套结构，那么将其序列化并将其放入其中可能是最简单的，而不是创建许多不同的本机结构并将它们链接在一起。

于 2013-03-13T22:21:47.240 回答