Эффективный дизайн для обновления другой базы данных всякий раз, когда сущность обновляется в приложении

Question

У меня есть приложение (приложение A), которое использует orientdb (DB # 1) в качестве базы данных.Сейчас мы разрабатываем другое приложение (приложение B), которое использует PostgreSQL (DB # 2) в качестве базы данных.

Теперь у нас есть требование, в котором нам нужно перечислить несколько сущностей приложения 'A' в приложении 'B'и также позволяет пользователям изменять эти объекты в приложении B. Все изменения, которые выполняются для объектов приложения' A 'в приложении' B ', должны быть отражены в БД № 1.После серии внутренних обсуждений с командой мы убеждены, что нужно сразу перенести данные необходимых сущностей из базы данных № 1 в базу данных № 2, а затем динамически обновить базу данных № 2 с записями, которые создаются / обновляются в базе данных № 1 и наоборот.,Может кто-нибудь предложить эффективные способы синхронизации db # 1 и db # 2?

Примечание:

1. Мы не заинтересованы в синхронизации db # 1 и db # 2 в реальном времени.время, возможная последовательность хорошо для нас.
2. Orientdb предоставляет 2 вида хуков
   • Динамические хуки (https://orientdb.com/docs/last/Dynamic-Hooks.html), которые работают на уровне схемы, а не между базами данных.
   • Хуки Java (https://orientdb.com/docs/last/Java-Hooks.html),, который требует, чтобы вы создали jar и поместили его в папку lib orientdb. Мы исключили эту опцию, поскольку у нас есть несколько экземпляров orientdb, работающих в разных регионах, что означает, что каждый раз, когда мы обновляем jar, нам нужно обновлять во всехэкземпляры oriendb и отладки могут быть трудными, так как этот jar работает как подпроцесс внутри oriendb.

Некоторые из рассмотренных нами подходов:

1. Всякий раз, когдапользователь создает / обновляет сущность в приложении 'A', создает / обновляет соответствующую запись в БД # 1 и, как только мы обновили ее в БД # 1, на прикладном уровне (Java), нажмите эквивалентный Postgres SQL-запрос для обновлениязапись в db # 2 в постоянную очередь и асинхронная обработка этих сообщений и наоборот

Answer 1

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

Принцип заключается в том, чтобы подключить что-то к журналам бинов вашей базы данных, которые будут вызывать события при изменении данных, затем вы будете реализовывать прослушиватели, отвечающие за репликацию изменений во 2-й БД. Этот подход позволяет избежать явного объединения разных приложений.

Answer 2

Это классический шаблон, который возникает в микросервисной архитектуре, где каждое микросервисное приложение имеет свою собственную базу данных, и затем возникает необходимость передавать эти данные другим службам. Есть несколько подходов:

1. Приложение A напрямую обновляет базу данных, используемую приложением B.
2. Приложение A вызывает веб-службу, предоставляемую приложением B, а затем эта веб-служба обновляет базу данных, используемую приложением B.

Оба вышеуказанных подхода приводят к жесткой связи между Приложением A и B, что не очень хорошо. Если схема базы данных, используемой приложением B, изменяется, приложение A также необходимо обновить в обоих вышеуказанных подходах.

Вместо этого стандартным и рекомендуемым способом интеграции данных между приложениями в современном мире является использование постоянных очередей, таких как Kafka. В этом случае всякий раз, когда приложение A получает обновления данных, оно помещает событие в очередь Kafka с данными, и ему все равно, получит ли приложение B это или нет. Приложение B подписывается на очередь, и когда оно получает события, переданные приложением A, оно обновляет свою собственную базу данных.

При таком подходе оба приложения очень слабо связаны. Существуют накладные расходы на поддержание этой инфраструктуры Kafka, но в долгосрочной перспективе оно того стоит, если приложения будут расширяться. И если Kakfa совершенно не подходит, то подход 2 (через веб-сервисы) лучше, чем подход 1 или другие интеграционные механизмы.

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