Сопоставления отношений Elasticsearch (один к одному и один к многим)

В моем эластичном поисковом сервере у меня есть один индекс http://localhost:9200/blog.
Индекс (блог) содержит несколько типов.

например: http://localhost:9200/blog/posts, http://localhost:9200/blog/tags.

В типе тегов я создал более 1000 тегов и 10 сообщений, созданных в типе сообщений.

Например: сообщения

{   
    "_index":"blog",
    "_type":"posts",
    "_id":"1",
    "_version":3,
    "found":true,
    "_source" : {
        "catalogId" : "1",
       "name" : "cricket",
       "url" : "http://www.wikipedia/cricket"
    }
}

Например: теги

{   
    "_index":"blog",
    "_type":"tags",
    "_id":"1",
    "_version":3,
    "found":true,
    "_source" : {
        "tagId" : "1",
        "name" : "game"
    }
}

Я хочу назначить существующий тег сообщениям в блоге (т.е. отношение = > сопоставление).

Как назначить метки для сопоставления сообщений?

Ответ 1

Существует 4 подхода, которые вы можете использовать в Elasticsearch для управления отношениями. Они очень хорошо описаны в сообщении блога Elasticsearch - Управление отношениями внутри Elasticsearch. Я бы рекомендовал прочитать всю статью, чтобы получить более подробную информацию о каждом подходе, а затем выбрать тот подход, который наилучшим образом соответствует вашим потребностям бизнеса, оставаясь при этом технически подходящим.

Вот основные моменты для 4-х подходов.

Внутренний объект

Легкая, быстрая, эффективная

Только применимо, когда поддерживаются отношения "один-к-одному"

Нет необходимости в специальных запросах
Уплотненный

Вложенные документы хранятся в одном блоке Lucene как друг для друга, что помогает повысить производительность чтения/запроса. Чтение вложенного документа происходит быстрее, чем эквивалент parent/child.

Обновление одного поля во вложенном документе (родительские или вложенные дочерние элементы) заставляет ES переиндексировать весь вложенный документ. Это может быть очень дорого для больших вложенных документов

"Перекрестные ссылки" вложенные документы невозможны.

Лучше всего подходит для данных, которые часто не меняются.
Parent/Child

Дети хранятся отдельно от родителя, но направляются в один и тот же осколок. Таким образом, родительские/дочерние элементы имеют немного меньшую производительность при чтении/запросе, чем вложенные

Сопоставления родителя/дочернего элемента имеют немного дополнительные издержки памяти, так как ES поддерживает список "join" в памяти

Обновление дочернего документа не влияет на родителя или других детей, что потенциально может сэкономить много индексирования на больших документах

Сортировка/оценка может быть затруднена с помощью родителя/ребенка, так как операции с дочерними/родительскими операциями могут быть непрозрачными в разы
Денормализация

Вы сами управляете всеми отношениями.

Наиболее гибкие, большинство административных издержек

Может быть более или менее результативным в зависимости от вашей настройки.