RediSearch中使用动态索引是否合理？分用户创建事件索引可行性问询

结论 #

你的场景下（查询时必带user_id），按用户拆分专属索引的方案是可行的，但百万级索引的资源开销需要根据实际部署规模评估，也可以根据用户量级选择折中方案。 #

关于百万级索引的风险说明 #

RediSearch单个索引的元数据内存开销通常在5KB_{20KB区间，100万索引的元数据总开销约为5GB}20GB：

• 如果是集群部署，分摊到多个分片节点后，单节点的索引元数据压力很小，不会有明显问题
• 如果是单实例部署，会出现内存占用过高、索引管理类命令（比如FT.LIST）执行变慢的问题

不同场景选型建议 #

• 用户量级小于10万：优先选择按用户拆分专属索引
  • 单用户索引规模极小，查询时不需要额外过滤user_id，性能比全局索引高30%以上
  • 单用户的所有事件key前缀统一，天然可以路由到同一个集群分片，不需要协调器跨分片查询，延迟更稳定
• 用户量级达到百万级：推荐二选一中庸方案
  1. 分片聚合索引：按user_id固定前缀分组，比如取user_id末两位拆分出100个聚合索引，每个索引承载1万左右用户的事件数据，既把索引总数控制在极低水平，又比全局索引的查询性能高一倍以上
  2. 优化后的全局索引：保留全局索引，给user_id设置为高优先级排序的数值索引，查询时使用语法FT.SEARCH events "@user_id:[100 100] @name:foo"，RediSearch会优先走user_id索引过滤掉99%以上的无效数据，剩余的name过滤开销可以忽略，性能和分用户索引差距不大，且维护成本极低

额外优化建议 #

如果选择按用户拆分索引，可以加冷用户索引自动清理逻辑，超过指定时间没有新事件的用户直接删除对应索引，需要查询时再自动重建，大幅减少无效索引的内存占用。

内容的提问来源于stack exchange，提问作者Jonathan