Как оптимизировать индекс перколятора elasticsearch Производительность памяти

Question

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

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

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

Answer 1

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

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

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

• Местоположение - 300+
• промышленности - 50+
• и т.д ...

Давать решение пространства :

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

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

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

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

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

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

Этот подход значительно уменьшит площадь памяти индекса перколяра при использовании той же цели.

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

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