Эластичные поиска: Моделирование данных, содержащих переменные поля

Question

Мне нужно хранить данные, которые могут быть представлены в формате JSON следующим образом:

Article{ 
    Id: 1, 
    Category: History, 
    Title: War stories, 

    //Comments could be pretty long and also be changed frequently 
    Comments: "Nice narration, Reminds me of the difficult Times, Tough Decisions" 

    Tags: "truth, reality, history", //Might change frequently 

    UserSpecifiedNotes:[ 
    //The array may contain different users for different articles 
    { 
     userid: 20, 
     note: "Good for work" 
    }, 
    { 
     userid: 22, 
     note: "Homework is due for work" 
    } 
    ] 
} 

После того, как прошли через различные статьи, денормализация данных является одним из способов справиться с этим данные. Но поскольку общие поля могут быть довольно длинными и даже часто меняться, я бы не хотел их повторять. Какими могут быть другие способы улучшения представления и поиска этих данных? Родитель-ребенок? Внутренний объект?

---

В настоящее время я бы имел дело со множеством вставок, обновлений и нескольких поисков. Но всякий раз, когда поиск должен быть выполнен, он должен быть очень быстрым. Я использую NEST (.net client) для использования эластичного поиска. Поисковый запрос будет использоваться, как ожидается, работать следующим образом:

1. Вход: searchString и userID
2. Поведение: Статьи, содержащие searchString в или Название, комментарии, теги или записки для данного userID рода в порядок соответствия

Answer 1

В нормальном сценарии основное содержание статьи будет изменено очень редко, тогда как «UserSpecifiedNotes»/комментарии к статье будут генерироваться/добавляться чаще. Это идеальный вариант для реализации отношения родитель-потомок.

С внутренним объектом вам все равно придется переиндексировать все «man article» и «UserSpecifiedNotes»/комментарии каждый раз, когда приходит новое примечание. С использованием отношения parent-child вы просто добавляете новое примечание.

С подробностями вы указали вы можете принять подход 4 индексов

• Основной статья (номер, категория, название, описание и т.д.)
• Комментариев (прокомментировано, текст комментария и т.д.)
• Тэги (метки, любой другой мета тег)
• UserSpecifiedNotes (USERID, ноты)

Сказав, что нужно Помните, что это ваше фактическое требование. При наличии отношения родитель-ребенок потребуется больше памяти, а ma замедляет производительность поиска крошечным битом. Но индексирование будет быстрее.

С другой стороны, вложенный объект значительно увеличит ваше время индексирования, поскольку вам необходимо собрать все данные, относящиеся к статье, перед индексированием. Вы можете, конечно, хранить все и просто добавлять в качестве обновления. В качестве более простого обслуживания и простоты реализации я бы предложил использовать parent-child.