Чи джерела подій є лише тоді, коли записи рідкісні?

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

Невиключна система з будь-яким значним використанням може виробляти між сотнями і тисячами записів на день, перекладаючи, скажімо, на мільйон або два записи (таким чином, події) на рік роботи. Об'єднання мільйонів об'єктів (подій) просто для отримання поточного стану звучить як глузливе судження, якщо порівнювати з прямолінійним зчитуванням із традиційного сховища. Тим не менш, пошук подій стоїть за однією з найефективніших систем (думаю, LMAX).

Отже, чого я пропускаю? Чи відновлення стану з потоку подій навіть зазвичай робиться? Або ідея рідко доводиться робити це, а замість цього взагалі використовувати інше сховище для звичайних операцій (тобто використовувати сховище запитів із CQRS) та відновлювати з подій лише у виняткових випадках (наприклад, реплікація, аудит тощо)?

Отже, чого я пропускаю?

Здогадуючись.

Перше, що вам може бути відсутнім, це те, що вам потрібно лише перезавантажити події для стану, який ви відбудовуєте. Якщо ви можете чітко моделювати межі транзакцій, кожен об’єкт може виписати події, позначені власним ідентифікатором, а потім прочитати лише ті події. Використовуючи реляційну базу даних для зберігання подій, буде індексований стовпчик ідентифікатора для прискорення запиту. Використовуючи EventStore, кожен об'єкт мав би свій потік.

У вашій моделі потрібно зробити певну обережність, щоб зробити це чисто, оскільки ви хочете бути впевненими, що ви змінюєте лише один об'єкт у кожній транзакції, і тому вам потрібно подбати про те, щоб ви правильно ізолювали кожен інваріант, який ви намагаєтеся примушувати

У тих випадках, коли це не досить швидко, ви все ще маєте можливість створювати знімки свого стану (запам'ятовування) та зберігати це в "традиційному сховищі". Кожен знімок позначається порядковим номером останньої події, яка використовується для створення знімка; під час перезавантаження сховище схоплює цей знімок спочатку, а потім застосовує до нього новіші події. (Це передбачає певний розумний спосіб захоплення останніх знімків - або події також позначаються порядковим номером, або у вас є якийсь ефективний спосіб прочитати потік подій назад, поки ви не дістанетесь до початкової точки.)

Тут все ще є перевага перед звичайним підходом, оскільки ваші знімки можна будувати паралельно вашим записам, а не об'єднувати їх: ви просто помістите слухача подій у якийсь інший потік / процес і дозвольте йому весело разом виписувати до магазину знімків за будь-якого розкладу здається розумним. Зрештою, знімок не повинен бути особливо своєчасним - достатньо часто, щоб робота з повторного застосування нових подій не підірвала ваш угод.

(Знімок робить складну міграцію; будь-які зміни в серіалізації моделі призведе до недійсності кешу знімків. Звичайно, ви можете відновити знімки, використовуючи нову серіалізацію як частину міграції, а потім "наздогнати", коли зміни почнуть діяти.)

Чи відновлення стану з потоку подій навіть зазвичай робиться?

Так. Що, як правило, показано на прикладах CQRS, це те, що рівень додатків, після того, як представлена ​​команда буде добре сформована, прикладний рівень завантажить доменний об'єкт із сховища, де навантаження є конструктором за замовчуванням з подальшим повтором потоку подій (або рівнозначно, дзвінок на завод із переліком подій).

Дві інші, суперечливі думки.

1. За інтерфейсом сховища може бути кеш
2. Інвалідація кешу - одна з двох важких проблем.