Как приблизиться к источнику событий с миллионами записей

Question

Мы смотрим на реализацию источников событий / CQRS, и для 95% нашей системы я могу рассуждать о событиях, и это меня не пугает.

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

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

Кажется, я не могу найти никакого совета о том, как обращаться с этими томами.Предполагается ли вам написать событие для каждой отдельной записи и действия и просто принять, что это будет вычислительно / дорого для базы данных?Существуют ли какие-либо тематические исследования, которые имеют схожие требования?

Любые рекомендации приветствуются.

Answer 1

Предполагается ли вам написать событие для каждой отдельной записи и действия и просто принять, что это будет вычислительно / дорого для базы данных?

Потенциально полезная эвристика - как бы высделать это с системой контроля версий?Создаете ли вы пустой документ, а затем вводите миллион коммитов или у вас будет один Data Imported коммит, и вы пойдете оттуда?

Важное замечание, на которое следует обратить внимание, заключается в том, что полномочия для данных где-то еще .«Физические объекты в реальном мире» не подчиняются правилам модели вашего домена;если у вас есть большая куча справочных данных .

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