Мониторинг изменений в базах данных

 
 
 
Сообщения:2
Уважаемые форумчане, здравствуйте!
Нужен ваш совет.

Алгоритм определения изменений схемы данных.
Введение:
В крупной системе, реализующей минросервисную архитектуру часто возникает необходимость синхронизации горячих данных между различными компонентами (исполняемыми модулями). Как правило единой точкой правды для всех компонентов является СУБД, а именно какая либо схема или набор объектов СУБД. Но частые обращения к этим объектам, в особенности запросы содержащие агрегатные или аналитические функции, негативно влияют на производительность СУБД в целом. Поэтому для разных ситуаций разрабатывают различные тактики определения разности состояний тех или иных объектов СУБД для синхронизации с приложением.
Что нужно сделать:
Спроектировать алгоритм (фунцию) определяющую есть ли изменения в СУБД или нет начиная с какого-либо времени или идентификатора.
Вариации:
  • [Вычисление изменение всей схемы целиком.
  • Вычисление изменений заданных объектов (таблиц, колонок).
  • Вычисление, реализованное только на JAVA без использования системных объектов СУБД.
  • (повышенной сложности) Вычисление, реализованное только на SQL на СУБД Postgres.
  • Вычисление допускает
  • Dведение дополнительных сущностей в схему данных, либо рекомендации к проектированию схемы.

Критерии оценки:
Код должен быть покрыт нагрузочными тестами, приведены оценки планов запроса.

Написано относительно сложно, суть, как я понимаю, необходимо написать на java какую-нибудь простую реализацию: класс, который будет отслеживать изменения данных.

Я гуглил-гуглил и так и этак. Кто-то предлагает на основе анализа журнала транзакций, использовать механизм триггеров. Вроде бы в MS Sql Server и в postgresql есть какие-то встроенные инструменты для этого, кто то предлагал делать это посредством контрольных сумм, в то же время чего-то простого доступного мне найти не удалось. Может быть есть возможность подсказать?
 
 
Сообщения:9916
Какая-то бестолковая архитектура - вроде бы есть сервисы, но при этом вместо того чтоб общаться по API они шарят БД.
GrossmasteR:
Как правило единой точкой правды для всех компонентов является СУБД, а именно какая либо схема или набор объектов СУБД.

У каждого сервиса должна быть своя БД и в нее никто больше не должен лезть. В таком случае:
1. Изменение схемы будет беспокоить только этот сервис. Другие не будут затронуты этими изменениями. А вообще схемы в наше время версионируются с помощью Flyway/Liquibase - они ведут свой журнал изменений.
2. Если другие сервисы заинтересованы в обновлениях (создание/удаление/редактирование объектов) - такие события нужно публиковать сообщениями: либо синхронными (RSS, Atom Syndicate Protocol), либо асинхронными (MQ). Т.к. данные изменяются только одним сервисом - он может трекать че и когда меняется.
Изменен:29 янв 2020 01:05
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет