1

我正在探索 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

任何帮助都会很棒。

谢谢！

4

1 回答 1

5

事实证明，我应该更好地阅读文档。

从聚合文档中描述FT.AGGREGATE他们提到的命令参数的部分LOAD {nargs} {property}，他们说：

从文档 HASH 对象加载文档字段。作为一般经验法则，应避免这种情况。聚合所需的字段应存储为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

正确定义架构后，我的原始查询有效。

于 2018-10-31T11:36:31.243 回答