Хранилище событий домена в SQL ... используйте сериализацию JSON?

Question

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

Архитектура:

• Веб-приложение
• Java
• Spring 4
• Spring JDBC
• MSSQL

Детали:

• 40 + - различные события, каждый из которых связан либо с общим корнем, либо с одним из его дочерних элементов.
• Подробная информация о событии сохраняются, но не состояние объекта (так что не CQRS событие источников)
• События используются только для отчетов
• отчеты подаются с объектами Java. IE. отчеты НЕ запускаются непосредственно из SQL.

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

event_id long, 
event_type varchar, 
event_time datetime, 
context_1_key varchar, 
context_1_val varchar, 
context_2_key varchar, 
context_2_val varchar, 
context_3_key varchar, 

... повторять как 10й ...

так, например (порядок = совокупный корень, п = ребенок)

event_type=ITEM_OPEN 
context_1_key=ORDER_ID 
context_1_value=1000 
context_2_key=ITEM_ID 
context_2_value=2000 

Нет Мне это не нравится, и я не отвечал за это.

Вопросы:

• context_1_xxx поля являются хрупкими и трудно поддерживать/устранение неисправностей/развернуть
• Все чучела в одну таблицу будет проблемой производительности (даже если отчетность не производительность чувствительна)
• События связаны с объектом домена; они не сохраняют состояние объекта. например. записанное событие бесполезно, если элемент удален

Моя кишка говорит мне, что создание 40 разных таблиц со схемой, уникальной для каждого события, не является ответом. Вместо этого я думал о сериализации (JSON) моментального снимка объекта (ов) домена для сохранения вместе с данными события.
кажется удобным решением:

• мы уже используем/Jackson модуль Spring для сериализации объектов для клиентов на основе браузера.
• команда довольно удобна в процессе сериализации/десериализации, поэтому нет основной кривой обучения.
• данные события должны вернуться через приложение для создания отчетов, которые будут достаточно легко, десериализацией с Джексоном

Только реальные минусы я могу увидеть: - не в состоянии использовать SQL на базе 3-й партии инструменты отчетности - не удалось индексировать таблицы по свойствам сохраненного объекта (JSON)

Я могу несколько смягчить проблему №2 путем дальнейшего разбиения хранилища событий на несколько разных таблиц.

Что еще мне не хватает? Существует ли наилучший подход к достижению этого? Как ты делаешь это?

Answer 1

Building an Event Storage, автор: Greg Young.

Konrad Garus описывает магазин событий, использующий PostgresSQL.

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

Возможно, нет. Первый разрез должен быть отдельной таблицей для событий всех типов. У вас есть blob (json is fine) для данных события и аналогичный blob для события metadata, а затем куча столбцов, которые вы используете для извлечения правильно упорядоченных историй событий.

Вместо этого я думал о сериализации (JSON) моментального снимка объекта (ов) домена, который будет сохранен вместе с данными события.

Это странная фраза. JSON представление данных события? В этом есть смысл.

«Снимок» - это брейк-брейк, но вам не нужен моментальный снимок данных события, потому что это событие неизменно. Вы определенно не хотите смешивать снимки состояния (т. Е. Результат свертывания истории событий) с самими событиями.

Последующий отчет: посмотрите, как клиент GetEventStore .NET writes и reads истории событий могут дать вам дополнительные идеи о том, как разработать схему. Обратите внимание, что данные события/метаданные обрабатываются как капли.