2014-03-26 3 views
2

Я использую ElasticSearch для поиска мощности в моем приложении.Дизайн моделирования ассоциации внутри типов в ElasticSearch

Одна из вещей, которую нам нужно сделать, - иметь способ хранения произвольных отношений между различными типами ElasticSearch.

Предположим, что у нас есть три вида в индексе ElasticSearch, такие как

"Клиенты", "Стиль жизни" и "MovieGenres".

Допустим, пользователь хочет связать несколько образ жизни для клиента, что происходит, является то, что пользователи задает отображение в приложении и в ElasticSearch принимает DocId от «клиента» , то DocId из «образа жизни» и помещает его в «Mapper» типа, который хранит пары DocId и хранит тип ассоциации в виде текста («cutomerToLifeStyle»).

Аналогичным образом связь между клиентом и moviegenre будет вставить пару docIds для клиента и moviegenre вместе с текстом типа ассоциации, такие как («customerToMovieGenre»). Идея заключается в консолидации любых типов произвольных отношений между типами в этом «Mapper».

Это может быть несколько упрощенным способом решения проблемы, но кто-нибудь видит что-то не так с этим подходом?

ответ

2

Чисто с точки зрения дизайна я бы также выбрал тип «Mapper», который связывает два документа, сохраняя их идентификаторы, а не, например. перечисляя идентификаторы «MovieGenres» внутри документов «Клиенты». Однако я хотел бы ввести отдельный тип «Mapper» для каждой взаимосвязи. (Это тип «CustomerToLifeStyle» и тип «CustomerToMovieGenre».) Причина в том, что вы можете хранить дополнительные данные в документах картографа, которые являются специфическими для отношения. Скажем, вы хотите сохранить, насколько хорошо клиент оценил фильмы в определенном жанре. Эта информация не будет иметь смысла в отношениях с клиентом. Чем больше данных вы хотите сохранить в документах картографа, тем больше вы увидите данные «CustomerToLifeStyle», а данные «CustomerToMovieGenre» станут разными. Таким образом, наличие отдельных типов для каждой взаимосвязи сохраняет ваш дизайн красивым и чистым.

+0

В итоге я создал тип Mapper. Кажется, мои «соединения» работают. Я думаю, что было бы лучше иметь сервис «присоединиться», поддерживаемый РСУБД (в дополнение к elasticsearch), чтобы заботиться о любых сложных требованиях объединения между различными объектами. Это увеличивает площадь поверхности приложения, но может быть более удобной в обслуживании в долгосрочной перспективе. –

2

Если вы хотите смоделировать этот вид отношений в elasticsearch, вы должны использовать отношения родитель/ребенок, который является одним из основных понятий в elasticsearch:

http://www.elasticsearch.org/blog/managing-relations-inside-elasticsearch/

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

Смежные вопросы