Elasticsearch и поддержание согласованности реляционных данных

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

В текущей платформе (поддерживаемой базой данных MySQL) большая часть данных хранится с внешними ключами, и, насколько я знаю, Elasticsearch хранит данные совершенно противоположным образом: без каких-либо связей …

Предположим, у нас есть следующие объекты:

• человек
• организация
• адрес

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

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

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

Предлагаемые решения:
При синхронизации объекта в Elasticsearch мы включаем некоторые свойства отношений, которые можно использовать позже, чтобы сохранить согласованность данных, скажем, мы делаем это следующим образом:

: Сохранить человека с идентификатором 1 в Elasticsearch
CURL PUT to URL: Http: // elasticsearch-сервер: some_port / testindex / человек / 1

{
"firstname" : "John",
"lastname" : "Doe",
"address" : {
"street" : "Some street""number" : "1"...
}
"relations" : [
{ "entity" : "address", "id" : "1" }
...
]
}

Сохранить организацию с идентификатором 1 в Elasticsearch
CURL PUT to URL: Http: // elasticsearch-сервер: some_port / testindex / организация / 1

{
"name" : "Some name",
"address" : {
"street" : "Some street""number" : "2"...
}
"relations" : [
{ "entity" : "address", "id" : "2" }
...
]
}

На существующей платформе мы реализовали бы следующую логику, которая синхронизировала бы адрес с Elasticsearch:

1. Сохраните адрес-объект (например, с идентификатором 1)
2. Запустить синхронизацию этого объекта с Elasticsearch
3. Когда синхронизация завершена, выполните поиск в Elasticsearch по всем типам, где есть связь с сущностью, равной «address» и id 1
4. Для каждого возвращаемого типа проверьте, существует ли этот тип с данным идентификатором на платформе, и инициируйте «обновление» и «синхронизацию» этого объекта. (Поскольку во время синхронизации информация об адресе будет построена на основе отношения внешнего ключа, она будет содержать обновленную информацию …)

Есть ли у кого-нибудь отзывы об этом способе работы? Идея работает? У кого-нибудь был негативный / позитивный опыт с этим способом работы?

Обновление 1: Персона, организация и адрес — это лишь небольшой выбор из множества сущностей / объектов, с которыми работает платформа … Я бы хотел избежать создания каких-либо ограничений для любых будущих сущностей / объектов …

Обновление 2: Данные синхронизируются с Elasticsearch, потому что у нас есть API, который может / будет использоваться сторонними компаниями для извлечения данных.

Обновление 3: Мы используем Elasticsearch 2.0, сопоставления должны быть определены на этапе проектирования, что означает, что мы определяем (а) родительский (ые) для определенного документа, у нас больше не будет гибкости, чтобы возможно добавить других родителей в будущем. (Запрещено модифицировать парены для существующего типа …)

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