Рефакторинг БД
Паттерны распила монолита на MSA
Зачем
Часть рефакторинга монолита.
Паттерны
Вопросы:
- Выделен DAL, есть адаптер до БД, исп-ся паттерн Репозиторий?
- Анализ в коде зависимости View, SP, trigger от таблиц
- проблема: использование шаблона shared database. Данные брались из таблиц через view, через интеграцию загружались в другие ИС. В результате мы не могли выносить таблицы в отдельную схему, потому что они активно использовались.
Паттерны БД
.svg)
Паттерны рефакторинга схемы базы данных:
- Разделить данные по признаку Сущности, например: Новый клиенты в НС, повторные в монолите
- плюысы: не требуется реализации миграции данных
- минусы: синхронизация в монолит потребуется, для возможности отката НС при итеративном распиле
- отделение существующих таблиц
- переносятся как есть в НС (антипаттерн?)
- отделение таблиц с рефакторингом
- Паттерн «разделение таблицы» (split table), который разбивает одну таблицу на две или больше
- 1м этапом в той же БД, тесты
- 2м - в новой БД сервиса
- Паттерн «разделение таблицы» (split table), который разбивает одну таблицу на две или больше
- Разделить операции чтения\изменения данных (CQRS)
- Операции изменения в 1ю очередь в новый сервис
- Адаптер в монолите к АПИ нового сервиса
- Синхронизация данных полей на чтение в монолите
- Операции чтения во 2ю очередь
- Снижает изменения интеграций со смежными ИС потребителями данных на чтение
- Необходима миграция текущих данных в новый сервис
- TODO Синонимы в БД?
- Операции изменения в 1ю очередь в новый сервис
- Паттерн “Совместное использование БД” несколькими сервисами
- минусы: нет сокрытия и изоляция данных, размыто понимание какой сервис какими данными владеет
- подходит для:
- статических справочных данных для чтения
- БД для интеграция нескольких внешних ИС потребителей
- Паттерн “Представления (проекции view) БД” для внешних ИС потребителей
- минусы: единое ядро СУБД между ИС как правило необходимо, иначе проблемы совместимости, скорости (MSSQL2PgSQL и тп)
- Паттерн “Сервис обертки над БД” (database wrapping service)
- подходит где сложно разобрать быстро модель БД, поэтому замораживается развитие БД, все изменения через Сервис
- контроль, что скрыто в модели от потребителей
- минусы: “повязка” временная для постепенного рефакторинга модели БД
- подходит где сложно разобрать быстро модель БД, поэтому замораживается развитие БД, все изменения через Сервис
- Паттерн “Интерфейс БД как служба”
- Основная БД отображается на отдельную БД на чтение для внешних ИС потребителей
- механизм отображения:
- онлайн CDC (Devezium и тп)
- пакетный ETL
- CDC vs ETL
- механизм отображения:
- Изменения в основной БД происходят через API
- подходит для: отчетности
- минусы: доп расходы на отдельную БД и механизм отображения
- альтернатива: реплика полная БД, но сокрытия нет и ИС потребители сами следят за изменениями модели БД
- Отличие от Паттерна “Представления БД” - отдельная БД может быть на другом тех стеке
- Основная БД отображается на отдельную БД на чтение для внешних ИС потребителей
- Писать в обе БД (2 источника истины), чтение только из новой БД
- Механизмы сверки данных необходимы
- Устранение двойной записи - шаблон Outbox вместе с Debezium, можно сделать так, что сервисы будут выполнять обе задачи – обновлять данные и уведомлять другие сервисы – безопасно и согласованно.