CQRS Запись базы данных - PullRequest
0 голосов
/ 29 мая 2018

В нашей компании мы разрабатываем систему на основе микросервиса и применяем шаблон CQRS.В CQRS мы разделяем Команды и Запросы, поэтому нам необходимо разработать 2 микросервиса.В настоящее время мне поручено улучшить шаблон CQRS для сохранения событий в отдельной базе данных (источник событий).Я понимаю, что наличие отдельной базы данных событий очень важно, но нужна ли нам отдельная база данных записи?Каково реальное использование базы данных записи?

Ответы [ 3 ]

0 голосов
/ 29 мая 2018

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

Если у вас есть отдельная база данных Read, она может быть встроена в журнал событий либо в строго согласованном, либо в конечном итоге-согласованная манера.

0 голосов
/ 30 мая 2018

Нет, вам не обязательно нужна отдельная база данных записи.Ядро сегрегации CQRS находится на уровне модели (кода).Переход к БД может быть полезным или вредным для вашего проекта, в зависимости от контекста.

Как и во многих ортогональных архитектурных решениях, связанных с использованием CQRS (Event Sourcing, Command Bus и т. Д.),плюсы и минусы должны быть тщательно продуманы до принятия.Ниже некоторого количества одновременного доступа разделение баз данных чтения и записи может не стоить усилий.

0 голосов
/ 29 мая 2018

Я понимаю, что наличие отдельной базы данных событий очень важно, но нужна ли нам отдельная База данных записи?Каково реальное использование базы данных записи?

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

Это "текущая правда", как понимает ваша система.

В некотором смысле, это "реальные" данные, где модели чтения просто старше/ кэшированные представления о том, как выглядели реальные данные.

Это может помочь в терминах СУБД.Когда трафик небольшой, мы можем обслуживать все входящие запросы из одной базы данных.По мере увеличения трафика мы хотим начать разгрузку части этого трафика.Поскольку мы хотим, чтобы постоянные данные находились в согласованном состоянии, мы не можем разгрузить записи - если мы не хотим разрешать конфликты в точке записи.Но мы можем пролить чтения на другие экземпляры, при условии, что мы готовы допустить некоторый конечный интервал времени между тем, когда происходит запись, и когда записанные данные доступны во всех системах.

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

Если вы посмотрите очень внимательно, вы можете заметить, что ваше «событие»database »имеет много общего с« записью в журнал ».

...