ElasticSearch проектирование для расширения Java WebService

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



У меня есть базовый объект Activity и расширения для него. В мире базе данных у меня есть таблица деятельности таблицы для каждого расширения и активности-расширение присоединяемой таблицы.



Затем я бы объединил соответствующие таблицы для поиска информации.



Я планирую использовать CXF, чтобы открыть его как веб-сервис, java middle tier for business логика и elasticsearch на задней панели для хранения и запроса данных.



Тогда мой вопрос заключается в том, правильно ли я думаю об elasticsearch или подход (разные таблицы и соединение) полностью ошибочен. Если это правильно, то как лучше всего представить различные "таблицы" в терминологии ElasticSearch.



Также для elasticsearch, как лучше всего работать с идентификационной информацией в объектах. Лучше всего сопоставить _id с полем id в каждом объекте или сохранить свой собственный id поле?



Ура!,
Роб

599   1  

1 ответ:

Я видел сравнения, которые говорят, что в ElasticSearch индекс сопоставим с базой данных, а таблица сопоставима с типом.

Я думаю, что вы могли бы сделать это в основном двумя различными способами.

Вариант 1: один индекс и один тип. Каждый подтип деятельности индексируется в один тип в ES, и некоторые документы имеют отсутствующие поля.
это даст вам,

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


Вариант 2: один индекс и несколько типов. Каждое расширение активности является типом в ElasticSearch.

  • множество отображений типов для поддержки.
    • Общие поля можно анализировать по-разному. Каждый документ, в теории, имеет все поля отображений.

При любом подходе вы можете поиск по всем подтипам. Я думаю, что сложность поисковых запросов будет зависеть от приложения.

Для большинства приложений я бы предпочел вариант 2. Каждый подтип должен быть своим собственным "типом" в ElasticSearch. Вы можете использовать фасеты для разных типов, если хотите. Если ваши подтипы относительно просты, я думаю, что вы могли бы сделать Вариант 1.

Когда вы его реализуете, я хотел бы услышать, как это сработало.

1  
2011-11-18 01:02:57

Comments

    Ничего не найдено.
Click here to cancel reply.