Эффективность перколятора ElasticSearch по сравнению с запросом

Question

У меня есть кандидаты на работу и списки вакансий. Я пытаюсь определить, какие кандидаты имеют квалификацию для конкретного листинга. У нас уже есть список, индексированный в ES. Два способа, которые я вижу, что я мог бы сделать это, являются:

1. Индекс каждого кандидата в ES, а затем построить запрос, основанный на параметрах листинга для поиска/фильтра вниз на квалифицированных кандидатов, и вернуть их в качестве Результаты.
2. Используйте функцию перколяции для создания запроса перколяции для каждого кандидата, а затем выясните, какие кандидаты совпадают, запустив данные листинга против индекса перколятора кандидата.

Что является более эффективным и совершенным в масштабе (миллионы записей)? Не полностью понимая, как реализуется перколятор (я не нашел статей, которые фактически объясняют реализацию), моя забота заключается в том, что с использованием перколятора я бы на самом деле выполнял один запрос на каждого кандидата в листинге, что было бы очень неэффективным.

Answer 1

С помощью Percolator вы выполняете поисковый запрос по индексу «запросов». Так что в вашем случае относительная 'работа' в исполнении Elasticsearch будут аналогичны в обоих случаях:

C: Number of Candidates CQ: Number of Candidate-Job-Search-Alert-Queries

(На основании вашего описания, C = CQ в вашей системе)

Вариант 1. Индекс всех кандидатов. Каждый раз, когда добавляется новое задание, выполняйте поиск по индексу кандидатов для сопоставления характеристик заданий. (Поиск C записей)

Вариант 2. Зарегистрируйте 1 запрос поиска-запроса-оповещения по каждому кандидату в индексе .percolator. Каждый раз, когда добавляется новое задание, используйте API-интерфейс Percolate для определения соответствия запросов-кандидата-поиска-запроса-кандидата. (поисковые запросы CQ записи запросов)

---

С точки зрения производительности/масштабируемости, большую озабоченность в том, что в Percolator requires the entire .percolator index to be loaded to memory.

С точки зрения функциональности, Percolator limits certain query types, который вам может понадобиться (что было бы голосованием в пользу варианта 1).

---

Если вы оказываетесь в ситуации, когда CQ << C (например, пользователем сохраненного поиска), то это более вероятно, что подход Percolator будет опережать необходимости запрашивать весь индекс кандидата.