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

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

Моделирование данных

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

Каковы параметры 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 (это было у меня), такой вариант исключает вариант. Если вы хотите извлечь выгоду из скорости эластичного поиска в качестве движка, это, по-видимому, желаемый вариант для вашего варианта использования.

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

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

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