例如：考虑一个哈希（我们称之为事件）有两个可搜索的属性：user_id（数字）和名称（文本）。
但是，每当我需要按名称过滤事件时，我都会手头有 user_id。所以我想知道每个用户有一个事件索引而不是所有用户的一个大事件索引是否有意义。
根据我对 Redis 和 RediSearch 的基本了解：
- 所有用户的所有事件的一个索引：
- 前缀：“事件：”
- 关键示例：事件：123，事件：456
- 优点：更容易。
- 缺点：每当我需要搜索名为“foo”和 user_id 100 的事件时，RediSearch 需要使用 user_id 查找事件块，然后过滤名称。哈希需要在同一个分片中或使用协调器。
- 每个用户为其事件创建一个索引：
- 前缀：“events:%USER_ID%:”，即“events:789”，其中 789 是用户 ID
- 关键示例：事件：789:123
- 优点：较小的索引可以获得更好的性能，并且可以轻松分发。
- 缺点：更难维护。如果有 1mi 的用户，我们有 1mi 的索引，不知道这是否有问题。