Comments 3
Скажите, пожалуйста, а зачем вы в elastic запихиваете данные которые хорошо ложатся в реляционную модель? Или это просто настолько плохой пример? Я бы понял вариант запихивания в него/Apache Solr/Apache Lucene иерархической структуры при нормальном использовании FTS, point'ов и т.п. с дальнейшими структурными запросами с использованием ToParentBlockJoinQuery/ToChildBlockJoinQuery, но этот вариант выглядит как странное аморфное нечто..
Вообще современная тенденция пытаться использовать ES как РСУБД несколько удивляет, и не в хорошем смысле. Почему не использовать реляционную базу для данных и ES/Solr для поиска?
Извините, но данный пример и структуры, и запросов очень сильно урезан, для того, чтобы стать максимально простым и понятным, и помочь продемонстрировать использование join field type и только лишь. Но, спасибо за замечание, действительно, во многих случаях в этом нет необходимости и есть масса других интересных и более выгодных решений.
Про современные тенденции некорректных попыток использования, к сожалению, не могу прокомментировать, не владею такой информацией
Аналогичную проблему решали с помощью создания "справочных" индексов. В мастер документах ссылались на id справочной сущности.
Только не делали именно как в статье, справочные индексы были загружены в память, контроль целостности ссылок был не на уровне БД, а в коде. Учитывая то, что Elastic использовался как slave хранилище, проблем не было никаких, все летало. Имхо, сама фича реализована в елке "шоб було" и в рамках идеологии инструмента не нужна.
Родители и дети. Связываем документы в Elasticsearch