Каковы недостатки использования Event sourcing и CQRS?

Event sourcing и CQRS отлично, потому что он получает разработчиков rids застрял с одной предварительно смоделированной базой данных, с которой разработчик должен работать в течение всего срока службы приложения, если нет большого проекта миграции данных. CQRS и ES также имеют другие преимущества, такие как масштабирование eventstore, журнал аудита и т. д. это уже по всему интернету.

но каковы недостатки ?

вот некоторые недостатки, которые я могу думать после исследование и написание небольших демо-приложений

  1. сложный: некоторые люди говорят, что ES является сложным. Но я бы сказал, что наличие сложного приложения лучше, чем сложная модель базы данных, на которой вы можете запускать только очень ограниченные запросы, используя язык запросов (несколько соединений, индексов и т. д.). Я имею в виду, что некоторые языки программирования, такие как Scala, имеют очень богатую библиотеку коллекций, которая очень гибка для создания некоторых серьезно сложных агрегатов, а также Apache Spark, который делает это простой запрос распределенных коллекций. Но базы данных всегда будут ограничены возможностями языка запросов, а распространение баз данных сложнее, чем распределенный код приложения (просто разверните другой экземпляр на другой машине!).
  2. высокое использование дискового пространства: хранилище событий может в конечном итоге использовать много места на диске для хранения событий. Но мы можем запланировать уборку каждые несколько недель и создать снимок, и, возможно, мы можем хранить исторические события локально на внешнем HD просто incase нам нужны старые события в будущем ?
  3. использование памяти: состояние каждого объекта домена хранится в памяти, что может увеличить использование ОЗУ,и мы все, как дорого ОЗУ. БОЛЬШАЯ ПРОБЛЕМА!! потому что я бедный! есть решение ? Можно ли использовать Sqlite вместо сохранения состояния в памяти ? Я делаю вещи более сложными, представляя несколько экземпляров Sqlite в моем приложении ?
  4. больше время загрузки: при сбое или обновлении программного обеспечения загрузка происходит медленно в зависимости от количества событий. Но мы можем использовать снимки, чтобы решить эту проблему ?
  5. согласованность: проблема для некоторых приложений. Представьте себе, если Facebook использовал источник событий с CQRS для хранения сообщений и учитывая, насколько занята система facebook, и если бы я опубликовал сообщение, Я бы увидел свой пост fb на следующий день:)
  6. сериализованные события в хранилище событий: Магазин Магазинов событий события как сериализованные объекты, что означает, что мы не можем запросить содержимое событий в хранилище событий, которое в любом случае не рекомендуется. И мы не сможем добавить еще один атрибут к событию в будущем. Решением было бы хранить события как объекты JSON вместо сериализованных событий ? Но разве это хорошая идея ? Или добавить дополнительные события для поддержки изменения объекта события orignal ?

может кто-нибудь прокомментировать недостатки, которые я привел здесь, и исправить меня, если я ошибаюсь и предложить что - нибудь еще, что я мог пропустить ?

20
cqrs event-sourcing

3 ответов

вот мой взгляд на это.

  1. CQRS + ES может сделать вещи намного проще в сложных программных системах, имея богатые объекты домена, простые модели данных, отслеживание истории, большую видимость проблем параллелизма, масштабируемость и многое другое. Это требует другого способа мышления о системах, поэтому может быть трудно найти квалифицированных разработчиков. Но CQRS упрощает разделение обязанностей между разработчиками. Например, младший разработчик может работать исключительно со стороной чтения без необходимости касаться бизнес-логики.

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

  3. Я не считаю более высокое использование памяти проблема. Гидратация бизнес-объектов должна производиться по требованию. Объекты не должны содержать ссылки на события, которые уже были сохранены. И гидратация событий должна происходить только при сохранении данных. На стороне чтения у вас нет преобразования Entity -> DTO -> ViewModel, которые обычно происходили в многоуровневых системах, и у вас не было бы никакого отслеживания изменений объектов, которое обычно делают полнофункциональные ORMs. Наиболее системы выполняют значительно больше операций чтения, чем записи.

  4. более длительное время загрузки может быть небольшой проблемой, если вы используете несколько гетерогенных баз данных из-за инициализации различных контекстов данных. Однако, если вы используете что-то простое, как ADO .NET для взаимодействия с хранилищем событий и микро-ORM для стороны чтения, система будет "холодный старт" быстрее, чем любой полнофункциональный ORM. Здесь важно не слишком усложнять доступ к данным. Что на самом деле проблема CQRS должна решить. И, как я уже говорил, сторона чтения должна быть смоделирована для представлений и не иметь никаких накладных расходов на повторное отображение данных.

  5. двухфазная фиксация может хорошо работать для систем, которым не нужно масштабировать для тысяч пользователей в моем опыте. Вам нужно будет выбрать базы данных, которые будут хорошо работать с координатором распределенных транзакций. Например, PostgreSQL может хорошо работать для чтения и записи отдельных моделей. Если система необходимо масштабировать для большого числа одновременных пользователей, он должен быть разработан с учетом возможной согласованности. Есть случаи, когда у вас будут агрегированные корни или границы контекста, которые не используют CQRS, чтобы избежать возможной согласованности. Это имеет смысл для несогласованных частей домена.

  6. вы можете запросить события в сериализованном формате, таком как JSON или XML, если вы выбрали правильную базу данных для хранилища событий. И это должно быть сделано только для целей аналитика. Ничто внутри системы не должно запрашивать хранилище событий ничем иным, кроме идентификатора aggregate root и типа события. Эти данные будут индексироваться и жить вне сериализованного события.

25

просто прокомментировать пункт 5. Мне сказали, что Facebook использует ES с возможной последовательностью, поэтому вы иногда можете видеть, как сообщение исчезает и появляется после его публикации.

обычно модель чтения, к которой обращается ваш браузер, находится "близко" к вам, но после того, как вы сделаете сообщение, SPA переключается на модель чтения, близкую к вашей модели записи. Близость между моделью записи (событиями) и моделью чтения означает, что вы можете увидеть свои собственные должность.

однако, через 15 минут ваш СПА переключается обратно на первую, более близкую, читаемую модель. Если событие, содержащее ваш пост, еще не распространилось на эту модель чтения, вы увидите, что ваш собственный пост исчезнет только для того, чтобы появиться позже.

5

Я знаю, что прошло почти 3 года с тех пор, как этот вопрос был задан, но все же в этой статье может быть полезно для кого-то. Ключевыми моментами являются

  • масштабирование со снимками
  • видимость данных
  • изменение схемы
  • работа со сложными доменами
  • нужно объяснить это большинству новых членов команды
0