Возникли проблемы с работой агрегатов.

Я нахожусь в процессе изучения 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 встречается три раза, а 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

Любая помощь будет супер.

Спасибо!


redis redisearch
person Tombatron    schedule 30.10.2018    source источник
comment
Пожалуйста, попробуйте после определения поля как SORTABLE во время создания схемы.   -  person Itamar Haber    schedule 31.10.2018
comment
Кроме того, рассмотрите возможность обновления до RediSearch версии 1.4.1, которая была выпущена ранее сегодня.   -  person Itamar Haber    schedule 31.10.2018
comment
@ItamarHaber Я обновился до последней версии Redis и RediSearch И создал свойство, которое собирал, на SORTABLE. Создание свойства SORTABLE, похоже, помогло. Я что-то пропустил в документации?   -  person Tombatron    schedule 31.10.2018
comment
Другой способ сделать это, не возвращаясь к использованию сортируемых полей, - настроить тайм-аут (в настоящее время глобальный) - это в основном классический компромисс между пространством и временем.   -  person Itamar Haber    schedule 31.10.2018

Ответы (1)


arrow_upward
5
arrow_downward

Получается, что надо было лучше читать документацию.

Из раздела в документации по агрегатам, где описываются FT.AGGREGATE параметры команды, упоминаются LOAD {nargs} {property}, где они сказать:

Загружайте поля документа из объектов HASH документа. Этого следует избегать в соответствии с общим эмпирическим правилом. Поля, необходимые для агрегации, должны храниться как SORTABLE, где они доступны для конвейера агрегации с очень низкой задержкой. LOAD значительно снижает производительность агрегированных запросов, поскольку каждая обрабатываемая запись должна выполнять эквивалент HMGET для ключа Redis, что при выполнении миллионов ключей требует очень большого времени обработки.

Из примера запроса в исходном вопросе, который у меня был:

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

С правильно определенной схемой мой исходный запрос работает.

person Tombatron    schedule 31.10.2018