Как смоделировать данные живого веб-приложения с SQL Server на ElasticSearch?

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

У пользователей есть 1..*проекты, 1..*геозоны. Содержимое хранится (в киоске данных) с идентификатором пользователя, идентификатором проекта, текстовыми значениями для географических областей, заголовком и описанием (оба проиндексированы с помощью свободного текстового поиска):

UserID, ProjectID, Geo, Title, Description, Timestamp

Теперь, когда мы хотим перенести это на ElasticSearch, какой подход к моделированию данных будет хорошим?

Просто для витрины данных я думал просто сериализовать объект данных (в настоящее время использую .Net и EntityFramework), чтобы дать мне представление JSON и вставить его в ES. Является ли это хорошим подходом (также требует наименьшей повторной работы)?

Что касается моделирования всего приложения, я видел примеры, когда тип ES был бы организован, скажем, пользователями, поэтому модель может выглядеть примерно так:

User
  User ID, Name, etc...
  ProfileSettings
     Setting1, Setting2, etc...           
  Geographies
     GeoID, GeoName
  Projects
     ProjectID, ProjectName
     ProjectContent
        Key (UserID:ProjectID:ProjectContentID), GeoName, Title, Description, Timestamp

Таким образом, похоже, что все веб-приложение может работать с одним индексом/типом. Немного страшно, нет?

Я хотел бы использовать Kibana и другие инструменты анализа в будущем и читал об ограничениях моделирования данных, таких как отказ от использования родительских/дочерних типов.

Как будет выглядеть хорошая модель данных ElasticSearch для чего-то подобного?

Другой способ спросить: как смоделировать работающее веб-приложение с помощью ElasticSearch и/или лучше хранить пользовательские конфигурации и профили в отдельной СУБД?

Спасибо.


entity-framework data-modeling kibana-4
person ElHaix    schedule 01.08.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

На эти вопросы всегда трудно ответить, не разбираясь в бизнесе и требованиях к отчетности. Но вот пара советов, которые я усвоил из своего, по общему признанию, краткого опыта работы с ES:

1) Вам не нужно помещать все это в один индекс, поэтому отдельные индексы для «пользователя» и «проекта» могут работать лучше всего. Поскольку ES индексирует все поля по умолчанию, поиск индекса проекта по пользователю будет быстрым. Kibana может выполнять поиск по нескольким индексам.

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

3) Может оказаться выгодным создать отображение в дополнение к сериализации и заполнению.

Что касается пользовательских конфигураций и профилей, я не вижу веских причин для использования СУБД. Они будут включаться по идентификатору пользователя без каких-либо требований к присоединению, не будут требовать модели согласованности и параллелизма ACID. Решение NOSQL даст вам гибкость схемы, которая требуется в этих случаях использования.

person NaturalData    schedule 08.08.2015
comment
1) с точки зрения отдельных индексов, как бы вы организовали индексы для нескольких приложений в кластере ES? 2) Почему бы не создать один индекс для каждого приложения, типов профилей пользователей и т. д.? 3) не могли бы вы уточнить, что вы подразумеваете под отображением? - person ElHaix; 08.08.2015
comment
Проверьте это для первых двух вопросов: наборы" title="эластичный поиск нескольких индексов по сравнению с одним индексом и типами для разных наборов данных"> stackoverflow.com/questions/14465668/ И это для сопоставления: elastic.co/guide/en/elasticsearch/reference/current/ - person NaturalData; 10.08.2015