Мы создаем приложение, используя LMAX Disruptor. При использовании Event Sourcing вы часто хотите сохранять периодические снимки вашей модели домена (некоторые люди называют это шаблоном Memory Image).Как сделать сериализацию снимков модели домена для получения источников событий
Мне нужно лучшее решение, чем то, что мы в настоящее время используем для сериализации нашей модели домена при съемке. Я хочу иметь возможность «красиво распечатать» этот моментальный снимок в читаемом формате для отладки, и я хочу упростить миграцию схемы моментальных снимков.
В настоящее время мы используем Googles' Protocol Buffers, чтобы сериализовать нашу модель домена в файл. Мы выбрали это решение, поскольку буферы протокола более компактны, чем XML/JSON, и использование компактного двоичного формата показалось хорошей идеей сериализации большой модели домена Java.
Проблема заключается в том, что буферы протокола были разработаны для относительно небольших сообщений, а наша модель домена довольно велика. Таким образом, модель предметной области не помещается в один большом иерархическом сообщении Protobuf, и мы в конечном итоге сериализации различных Protobuf сообщения в файл, например:
for each account {
write simple account fields (id, name, description) as one protobuf message
write number of user groups
for each user group {
convert user group to protobuf message, and serialize it
}
for each user {
convert user to protobuf message, and serialize it
}
for each sensor {
convert sensor to protobuf message, and serialize it
}
...
}
Это раздражает, потому что манипулируя поток гетерогенных сообщений Protobuf является сложным , Было бы намного проще, если бы у нас было одно большое сообщение Protobuf, содержащий все наши модели предметной области, например:
public class AggregateRoot {
List<Account> accounts;
}
--> convert to big hierarchical protobuf message using some mapping code:
message AggregateRootMessage {
repeated AccountMessage accounts = 1;
}
--> persist this big message to a file
Если мы это сделаем, это легко prettyprint снимок: просто прочитать большое сообщение Protobuf, затем отпечатайте его с помощью protobuf's TextFormat. В нашем текущем подходе нам нужно читать разные сообщения protobuf по одному и красиво печатать их, что сложнее, так как порядок сообщений protobuf в потоке зависит от текущей схемы моментальных снимков, поэтому наш инструмент довольно печатной должен знать об этом.
Мне также нужен инструмент для переноса моментальных снимков в новую схему моментального снимка, когда наша модель домена развивается. Я все еще работаю над этим инструментом, но это сложно, потому что мне приходится иметь дело с потоком различных сообщений protobuf, вместо того, чтобы иметь дело с одним большим сообщением. Если бы это было просто одно большое сообщение, я мог бы: - взять файл моментального снимка - разобрать файл как большое сообщение protobuf Java, используя схему .proto для предыдущей версии моментального снимка - конвертировать это большое сообщение protobuf в большой protobuf сообщение для новой версии, используя Dozer и некоторый код сопоставления - напишите это новое сообщение protobuf в новом файле, используя схему .proto для новой версии
Но поскольку я имею дело с потоком сообщений протобуфа различных типы, мой инструмент должен обрабатывать этот поток в правильном порядке.
Так что, да ... Я думаю, мои вопросы:
Вы знаете, любой инструмент, который может сериализацию сериализовать большую модель предметной области в файл, без ограничений Protobuf в, возможно с использованием потокового видео, чтобы избежать OutOfMemorryErrors ?
Если вы используете источники событий или изображения памяти, что вы используете для сериализации вашей модели домена? JSON? XML? Protobuf? Что-то другое?
Мы делаем это неправильно? Есть ли у вас какие-либо предложения?
Это может быть полезно или не полезно: http://contourline.wordpress.com/2012/01/18/how-big-is-too-big-for-documents-in-couchdb-some-biased-and -totally-unscientific-test-results/ – Jukka
JSON - действительно подход, который мы могли бы использовать, и мне нравится использовать удобные для чтения форматы файлов. Но они решили использовать двоичный формат для сериализации, чтобы сэкономить место (до того, как я присоединился к проекту), и я не уверен, что хочу спорить о переключении на JSON, если он будет создавать проблемы позже по дороге, когда моментальный снимок станет слишком большой ... Я обдумываю это, но меня тоже интересуют другие подходы. Если кто-то ответит, что он использует JSON в своем проекте Source Source с огромной моделью домена, это может помочь мне аргументировать JSON :) Если мы в конечном итоге выберем JSON, я буду настаивать на GSON, так как мне нравится эта библиотека :) –
Посмотрите также на BSON и MongoDB: http://docs.mongodb.org/manual/core/document/ – Jukka