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

Question

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

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

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

Мой план состоит в том, чтобы использовать CXF для открытия его в качестве веб-службы, Java-уровень среднего уровня для бизнес-логики и эластичный поиск сзади для хранения и запроса данных.

Тогда у меня вопрос: правильно ли я думаю оasticsearch или подход (разные таблицы и объединение) совершенно неправильный? Если это правильно, что было бы лучшим способом для представления различных «таблиц» в терминологии ElasticSearch.

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

Cheers, Rob

Answer 1

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

Я думаю, вы могли бы пойти по этому поводу двумя способами.

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

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

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

• Поддерживаются многие сопоставления типов.
• Общие поля можно анализировать по-разному.
• Теоретически каждый документ имеет все поля отображений.

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

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

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