0

例如：考虑一个哈希（我们称之为事件）有两个可搜索的属性：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 的索引，不知道这是否有问题。
4

1 回答 1

2

@jonathan 这取决于您的性能要求和可用内存。

如果内存不是问题（两次索引同一个文档）并且您希望将延迟减少到最低限度，那么这听起来像是一个可选选项。

需要注意的是，创建这么多索引会在 GC 上产生开销，因此您应该只在用户级索引非常静态或短暂存在时才考虑它，并且您可以将其定义为TEMPORARY（可以无限超时）

见：https ://oss.redis.com/redisearch/Commands/#ftcreate

于 2021-09-04T08:44:45.640 回答