Архитектура базы данных, разделение базы данных

Question

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

Это упрощенное описание системы. Все 3 базы данных NF (Клиент, Бухгалтерия, Курс, Выдержка)

У нас есть 4 БД нормальной формы:

• Клиентская база данных: ведение информации о клиенте и организации

• Rate DB: получение курсов обмена от сторонней системы

• Exposure DB: обращение в стороннюю систему для получения нашего банковского счета и торговой информации

• Бухгалтерский учет БД: дальнейший расчет по финансовому риску и прогнозирование

У нас есть следующие базы данных для хранения данных

• Службы аналитики SQL Server: схема "звезда"

• куб

Разделение базы данных: наши 4 базы данных (клиент, скорость, экспозиция, учет) - это 4 сервера SQL, но все они работают на одном физическом сервере. Эти базы данных нуждаются в данных друг от друга, например, у нас есть таблица организации, которая используется во всех БД... или в других БД нужны ставки.

Службы аналитики: у нас есть схема "звезда" и службы аналитики. Насколько я понимаю, Data Vault может быть использован в качестве источника для создания схемы запуска... Но мы не используем наше хранилище данных для этой цели. Мы используем SSIS для чтения данных напрямую из БД клиента, тарифа, экспозиции и учета, а также для непосредственного заполнения схемы запуска.

Вопрос:

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

2. Есть хороший источник / блог, чтобы объяснить, когда это хорошая идея для разделения базы данных?

3. Является ли копирование таблиц из исходной базы данных в целевую базу данных хорошим решением? Я чувствую, что кросс-запросы к БД были бы намного проще и эффективнее, чем копирование такого количества таблиц в несколько БД.

Answer 1

Является ли что-то хорошей идеей, это вопрос мнения. Что менее важно, так это вопрос компромиссов, и здесь я могу обсудить их.

Разделение баз данных между отделами дает департаментам большую свободу в выборе моделей их доменов. Одной из достоверных идей школы мысли DDD является то, что команды формируют ограниченный контекст, который может использовать словарный запас немного отличающимся от других. Если предоставление различным группам большей гибкости в определении их собственной терминологии и моделей данных является положительным моментом, то это возможно.

С другой стороны, есть ряд недостатков производительности. Каждая система знает меньше о распределении данных в каждой базе данных и, следовательно, менее способна эффективно планировать. Соединения между узлами всегда дороги. Таким образом, вы получаете некоторые реальные недостатки, а также.

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

Пара других вещей, чтобы рассмотреть:

1. Будут ли связанные серверы лучше, чем хранилище данных?
2. Будет ли какой-то ETL, контролируемый базой данных назначения, лучше?

Answer 2

Существует общая проблема в разработке решений, которые пересекают границы домена. Если у вас есть одна база данных с каждым объектом домена, все становится зависимым друг от друга; если у вас много независимых баз данных, вам придется иметь дело с междоменными запросами.

Самое современное мнение об этом - это концепция микро-услуг и CQRS. Возможно, ваш дизайн является примитивной формой этого проектного решения, а "хранилище данных" выступает в качестве посредника.

Решение, которое обеспечивает архитектура микросервисов, - "независимость важнее эффективности". Каждый микросервис (и основное хранилище данных) может делать то, что имеет смысл, и двигаться со своей скоростью, не беспокоясь о зависимостях. Цена для этого является более сложным решением, особенно когда речь идет о зависимости данных.