Поиск по полиморфным данным с помощью Elasticsearch

Question

Я сфокусирован на том, что, по-видимому, является фундаментальной проблемой с Elasticsearch и полиморфными данными. Я хотел бы иметь возможность находить несколько типов результатов (например, пользователей, видео и плейлисты) только с одним запросом Elasticsearch. Это должен быть только один запрос, так как таким образом Elasticsearch может делать все скоринг, и мне не придется делать какие-либо магии для объединения нескольких результатов запроса разных типов.

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

Я искал примеры других решений этой проблемы и не мог найти их. В документации тоже ничего не говорится. Могу ли я игнорировать что-то очевидное или был Elasticsearch просто не предназначен для того, чтобы сделать что-то подобное?

С наилучшими пожеланиями,

Стеффан

Answer 1

То не проблема самого Elasticsearch, его задача (или ограничение) лежащих в основе индексов Lucene. Таким образом, любой db/engine, основанный на lucene, будет иметь те же проблемы (если не хуже :), ES делает чертову работу для вас). Вероятно, ES облегчит боль в дальнейших выпусках, но не резко. И ИМО, вряд ли найдется какая-либо высокотехнологичная поисковая система, которая может иметь истинные полиморфные данные.

Ответ зависит от вашей структуры данных, это точно. В принципе, у вас есть два варианта:

1. Поместите все свои данные в один индекс и разделите их по типам. И вы уже знаете, что накладные расходы - яркие индексы плохо работают с разреженными данными. Похоже, ваши данные меньше проблем. Во всяком случае, ES выполнит всю базовую работу для «отсутствующих» значений, вам нужно будет справляться с накладными расходами памяти/диска для хранения разреженных данных.

   Если ваши данные организованы с отношением parent-child (т. Е. Видео -> список воспроизведения), вам определенно нужен единый индекс для таких данных. Что оставляет вас только с этим подходом.

2. Разделите свои данные на несколько индексов. Таким образом, у вас есть несколько более высокие накладные расходы на диск для индекса lucene +, возможно, более высокий уровень использования ЦП при агрегировании данных из нескольких осколков (так что вы должны настроить настройку соответственно).

   Вы по-прежнему можете запросить ES для всех своих документов в одном запросе, поскольку ES поддерживает multi-index запросов.

Итак, это похоже на вопрос исключительно о вашей структуре данных. Я бы рекомендовал просто запустить небольшой кластер для измерения использования памяти/диска/процессора для ожидаемых данных. Подробнее о «index vs shard» - отлично article от Adrien.

Немного не по теме, если ES не соответствует вашим потребностям, я предлагаю вам по-прежнему рассматривать возможность объединения данных со стороны приложения. ES отлично работает с несколькими запросами света (вместо нескольких более тяжелых), и по мере того, как ваши результаты от ES уже отсортированы, вам необходимо объединить отсортированные потоки с отсортированным вводом. Не так много волшебства, тбх.