Redis中最快的伪索引是什么？

Question

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。

Answer 1

正如我所看到的，每种方法都有其自身的优点和缺点：

哈希方法：

• 您可以相当快速地获得所有电子邮件（密钥）或ID（值）的列表（O（N），其中N是地图中的条目数）
• 对于少量条目，它将具有相当大的内存效率（虽然很小，可能不适用于任何实际用例）
• 您仅限于2 ^ 32-1个条目（再次，可能不是问题，除非您计划在地球上的大多数人使用您的申请）
• 稍微较慢，因为redis需要进行两次O（1）查找而不是一次...边缘差异，如果完全可见的话。
• 不是友好的分片，因为它们都将在同一个redis实例中。

关键方法：

• 参赛人数无限制
• 尽快
• 只能使用KEY获取所有用户的列表，这是O（n）（对于数据库中的每个条目 - 对于实时环境来说是一个很大的禁忌）
• Shard friendly

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

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