我正在探索RediSearch,我想我应该给聚合功能一个镜头,并且遇到障碍。
我似乎无法获得良好的结果。
出于测试目的,我创建了一个基本索引/架构,如下所示:
FT.CREATE test SCHEMA field TEXT
FT.ADD test 1A 1 FIELDS field hello
FT.ADD test 2A 1 FIELDS field hello
FT.ADD test 3A 1 FIELDS field hello
FT.ADD test 4A 1 FIELDS field world
接下来,我发出了以下查询:
FT.AGGREGATE test "*" GROUPBY 1 @field REDUCE COUNT 0 AS agg
我的期望是得到的结果表明hello
发生了3次,world
发生了一次……但是我得到了以下结果:
1) (integer) 1
2) 1) "field"
2) (nil)
3) "agg"
4) "4"
我认为这很简单...但是我显然做错了什么。
此外,以下是MODULE LIST
命令的输出:
1) 1) "name"
2) "ft"
3) "ver"
4) (integer) 10300
2) 1) "name"
2) "ReJSON"
3) "ver"
4) (integer) 10001
任何帮助都是超级帮助。
谢谢!
答案 0 :(得分:1)
事实证明,我应该更好地阅读文档。
在aggregations documentation中描述FT.AGGREGATE
命令参数的部分中,他们提到LOAD {nargs} {property}
,并说:
从文档哈希对象中加载文档字段。这应该是 一般而言,应避免使用。汇总所需的字段 应该存储为 SORTABLE , 具有非常低延迟的聚合管道。 LOAD 会影响性能 大量查询的数量,因为每个已处理的记录都需要 对redis键执行HMGET的等效命令,当 在数以百万计的键上执行,相当于非常长的处理时间。
从原始问题的查询示例中我可以得出:
FT.AGGREGATE test "*" GROUPBY 1 @field REDUCE COUNT 0 AS agg
由于模式定义没有将field
定义为SORTABLE
,因此我必须LOAD
“字段”才能对其进行汇总。
FT.AGGREGATE test "*" LOAD 1 @field GROUPBY 1 @field REDUCE COUNT 0 AS agg
但是,由于根据文档LOAD
会影响性能,因此我应该将我要聚合的字段定义为SORTABLE
。
FT.CREATE test SCHEMA field TEXT SORTABLE
在正确定义架构的情况下,我的原始查询有效。