基于RediSearch实现分面搜索：多字段聚合统计可行性及性能咨询

背景与需求 #

现有数据模型：

{
  id: string;
  name: string;
  description: string;
  price: number;
  brand: string;
  size: string;
  color: string;
}

需要通过RediSearch获取指定查询结果集中多个字段的数值统计，期望输出格式如下：

{
  brand: {
    nike: 6,
    adidas: 3,
    reebok: 2
  },
  size: {
    sm: 2,
    md: 4,
    lg: 3,
    xl: 2
  },
  color: {
    blue: 4,
    black: 4,
    white: 2,
    gray: 1
  }
}

已知可通过单字段聚合查询获取单个字段的统计：

FT.AGGREGATE products "*" GROUPBY 1 @brand REDUCE COUNT 0 AS count

但字段较多时需多次查询，百万级数据集下担心性能不佳，因此有以下疑问：

• 是否支持同时对多字段进行聚合？
• 若不支持，有无更优方案？
• 该操作在内存数据库中是否真的性能开销过大？

解答 #

1. 是否支持多字段同时聚合？ #

RediSearch（含最新稳定版本）不支持单次FT.AGGREGATE请求同时对多个独立字段执行GROUPBY聚合，一次请求仅能针对一组字段做分组统计，无法同时输出多个字段各自的频次分布结果。

2. 更优方案 #

• 管道（Pipeline）批量提交请求：将多个单字段聚合请求打包进Redis管道，一次性发送给服务器执行。管道能大幅减少网络往返次数，相比逐个发送请求，百万级数据集下的效率提升非常明显。
• 预计算统计结果：
  • 若统计无需强实时性，可定期（如分钟/小时级）执行全量聚合，将结果存入Redis的Hash或JSON结构中，业务直接读取预计算结果即可。
  • 若需准实时，可通过Redis Stream或键空间通知监听数据的增删改操作，实时更新预计算的统计值，避免全量扫描。
• Lua脚本服务器端合并执行：基于RedisStack（RediSearch+RedisJSON），编写Lua脚本在服务器端一次性执行多个聚合逻辑，合并结果后返回。需注意控制脚本复杂度，避免阻塞Redis主线程。

3. 内存数据库中的性能开销 #

百万级数据集下，单字段FT.AGGREGATE的GROUPBY COUNT操作本身开销极低——RediSearch的索引基于内存结构，分组统计直接在内存中遍历匹配文档，无磁盘IO开销。真正的性能瓶颈来自多次请求的网络往返和大结果集的传输。通过管道或Lua脚本合并请求后，开销会大幅降低，完全能满足多数业务的实时统计需求。

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