Collapse + rescore функциональность

Elastic In Your Native Tongue Вопросы на русском языке
1

Я знаю что раньше в версии 5.3 была функциональность rescore+collapse https://github.com/elastic/elasticsearch/pull/28521 и что ее выпилили, но в моей ситуации мне такая функциональность необходима. Основная идея - создать плагин который бы позволил эмулировать такое поведение
Я изучал исходные коды elastic'a и вот что получается:

  • QueryPhase имеет строгий порядок выполнения и rescore выполняется после всех collectors (в static boolean execute) и до выполнения второй фазы агрегации aggregationPhase.execute(searchContext);
  • все что мне нужно это в реализовоном мной классе унаследованом от InternalAggregations реализовать reduce метод в котором я и буду делать collapsing по id элемента с сортировкой по score

Мой вопрос - есть ли другие способы реализовать эту функциональность с помощью плагина (менять код эластика я не хочу, во всяком случае пока). Если нет то как можно вытащить score во время агригации (я так понял что можно через вложеную агрегацию с скриптингом, что выглядит не слишком хорошо)

эластик 6.6

2

Вы видели последний комментарий от Джима? Вы как с этим будите бороться?

3

насколько я понял, то проблема в том что из за скора на разных шардах могут не правльно разбиваться/определяться топ документы, в моем случае score должен выдавать LTR и проблем стандартных алгоритмов расчета вроде TF/IDF и bm25 не должно быть

4

Я не очень понимаю, что вы хотите сделать, но в контексте map_script агрегации scripted_metrics есть доступ к score. Так что может начать со script engine плагина и использовать эту агрегацию?

5

Я хочу после рескора, сделать коллапс. При этом рескор будет из плагина который получает веса из LTR'a.

Возможно, для решения задачи в плагине не нужны переопределять агрегаты, может быть есть более правильный/элегантный/производительный подход? Насколько решение с пропатченым elastic'ом и его queryPhase будет быстрее плагина с агрегатами? Естественно что это все нужно мерить, после разработки на близком к проду окружении, но, кажется, есть очевидные вещи для тех кто работает с эластиком каждый день.

Мои наблюдения, возможно не совсем верны, именно поэтому я прошу совета у тех кто может дать направление в котором можно (если можно) правильно решить задачу, так чтобы в продакшене это не ложилось при 1000 rps с response tim'ом в 200ms на кластере в 8 машин при кол-ве документов ~10млн.

P.S. Насколько я знаю любой доступ к скриптам сильно влияет на производительность, возможно это не так

6

Я хочу после рескора, сделать коллапс.

Теперь понял. Я не думаю, что это можно сделать без значительной переработки elasticsearch, которую вы хотели-бы избежать. Надо смотреть глубже, но в данный момент у меня, к сожалению, нет для этого времени.

7

Спасибо за ответ! Сэкономили кучу времени которые мы хотели потратить на плагин.

8

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.