Что представляет собой хорошее применение веб-приложения для реализации пакета данных SQL Server в ElasticSearch?

Question

Исходя из РСУБДА фона и пытается обернуть мою голову вокруг ElasticSearch шаблонов хранения данных ...

В настоящее время в SQL Server, мы витрина данных звезды схемы, RecordData. Строки организованы по идентификатору пользователя, географическому расположению, которое относится к остальной части поиска, названия и описания (которые являются полями свободного текстового поиска).

Я хотел бы переместить это на ElasticSearch и прочитать о создании отдельного индекса для каждого пользователя. Если я это правильно понял, с этим предложением я бы создал тип RecordData в каждом пользовательском указателе, правильно? Что такое рекомендуемое соглашение об именах для пользовательских индексов, которое будет простым для анализа Kibana?

Одна из проблем, с которой я столкнулся, заключается в том, как бы вы организовали несколько веб-приложений на ES-сервере? Вы не хотели бы иметь все эти пользовательские индексы повсюду?

Стоит ли иметь один индекс для каждого приложения и вводить его в таблицу SQL Server?

Поскольку в SQL Server у нас есть другие таблицы для пользовательской настройки на основе идентификаторов пользователей, я полагаю, что тогда я мог бы создавать новые типы ES в пользовательских индексах для конфигурации. Является ли это рекомендуемым образцом? Я бы предпочел не иметь две базы данных для этого веб-приложения.

Предложения приветствуются, благодарю вас.

Answer 1

Я прошел через то же самое, и есть несколько вещей, которые нужно учитывать. Моделирование

данных

Вы говорите, что вы используете звездообразную схему сегодня. Elasticsearch обычно подходит для денормализованных данных, где совокупность информации находится в каждом документе, в отличие от звездной схемы. Если вы можете жить с денормализованным, это нормально, но я предполагаю, что, поскольку у вас уже есть звездная схема, денормализованные данные не являются опцией, потому что вы не хотите идти и обновлять миллионы документов каждый раз, когда изменение имени местоположения, например (если я понимаю вариант использования). По крайней мере, в моем варианте использования это не вариант.

Что такое альтернативные варианты поиска нормализованных данных?

Это заставляет нас думать о том, как помещать звездочную схему как данные в систему, такую ​​как Elasticsearch. В документации есть несколько вариантов, основные из которых были сфокусированы:

• Вложенные объекты - подробная информация на https://www.elastic.co/guide/en/elasticsearch/guide/current/nested-objects.html. Во вложенных объектах вся информация хранится в одном документе, что означает, что одно местоположение и связанные с ним пользователи будут находиться в одном документе. Это может сделать его не оптимальным, потому что документ будет огромным и снова, изменение имени местоположения потребует обновления всего документа. Так что это лучше, но все же не оптимально.
• Родитель - Детский род - более подробная информация на https://www.elastic.co/guide/en/elasticsearch/guide/current/parent-child.html. В этом случае записи местоположения и пользователя будут храниться в отдельных индексах аналогично реляционной базе данных. Кажется, это правильное моделирование для того, что нам нужно. Единственная серьезная проблема с этим вариантом заключается в том, что Kibana 4 не предоставляет способы манипулирования/агрегирования документов на основе отношений между родителями и дочерними элементами на момент написания этой статьи. Поэтому, если основным драйвером для использования Elasticsearch является Kibana (это было мое), такой вариант устраняет эту возможность.Если вы хотите использовать скорость elasticsearch как двигатель, это, по-видимому, является желательным вариантом для вашего варианта использования.

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

Что касается организации самих серверов, то мы организуем это путем создания отдельного кластера из 3 узлов elasticsearch за балансировщиком нагрузки (все это размещено в облаке), а затем все ваши веб-приложения подключаются к этот кластер использует API Elasticsearch.

Надеюсь, что это поможет.