Как оптимизировать индекс эластичного поискового фильтра

Question

Есть ли способ улучшить производительность памяти при использовании перколяционного индекса эластичного поиска?

Я создал отдельный индекс для моего перколятора. У меня примерно 1 000 000 созданных пользователем сохраненных поисков (для оповещений по электронной почте). После создания этого индекса перколятора мое использование кучи увеличилось до 100%, и сервер перестал отвечать на любые запросы. У меня несколько ограниченные ресурсы, и я не могу просто использовать больше оперативной памяти для решения проблемы. Единственным решением было удалить индекс, содержащий мои сохраненные поиски.

Из того, что я прочитал, индекс перколятора постоянно находится в памяти. Это совершенно необходимо? Есть ли способ подавить это поведение, но при этом сохранить функциональность? Есть ли способ оптимизировать структуру данных / запросов / индексов, чтобы обойти это поведение и при этом достичь желаемого результата?

Answer 1

Нет решения этой проблемы с точки зрения ElasticSearch, и вряд ли это возможно. Я пообщался с ребятами из ElasticSearch напрямую, и они ответили: "брось больше оборудования".

Однако я нашел способ решить эту проблему с точки зрения смягчения моего использования этой функции. Когда я проанализировал свои сохраненные поисковые данные, я обнаружил, что мои поиски состоят из около 100 000 уникальных ключевых слов, а также различных перестановок фильтров, создающих более 1 000 000 сохраненных поисков.

Если я смотрю на фильтры, они такие вещи, как:

• Расположение - 300+
• Промышленность - 50+
• так далее...

Предоставление пространства для решения:

100 000 *> 300 *> 50 *... ~ => 1 500 000 000

Однако, если бы мне пришлось разложить поиски и проиндексировать поиски по ключевым словам и фильтры отдельно в индексе перколятора, я бы получил гораздо меньше запросов:

100 000 +> 300 +> 50 +... ~ => 100 350

И сами эти поиски меньше и менее сложны, чем первоначальные поиски.

Теперь я создаю второй (не перколяционный) индекс, в котором перечислены все 1 000 000 сохраненных поисков и в том числе идентификаторы компонентов поиска из индекса перколятора.

Затем я фильтрую документ, а затем выполняю второй запрос, фильтруя поиск по ключевому слову и фильтруя результаты перколятора. Я даже могу сохранить показатель релевантности, так как он возвращается исключительно из поиска по ключевым словам.

Такой подход значительно сократит объем используемой памяти перколяционного индекса при выполнении той же цели.

Я хотел бы пригласить отзыв об этом подходе (я еще не пробовал, но буду держать вас в курсе).

Точно так же, если мой подход будет успешным, вы считаете, что он заслуживает особого запроса?