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

Question

The Little Book of 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)(对于数据库中的每个条目 - 对于实时环境来说是一个很大的禁忌)
• 分片友好

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

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