Сопоставления отношений 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" в памяти
  • Обновление дочернего документа не влияет на родителя или других детей, что потенциально может сэкономить много индексирования на больших документах
  • Сортировка/оценка может быть затруднена с помощью родителя/ребенка, так как операции с дочерними/родительскими операциями могут быть непрозрачными в разы

Денормализация

  • Вы сами управляете всеми отношениями.
  • Наиболее гибкие, большинство административных издержек
  • Может быть более или менее результативным в зависимости от вашей настройки.