mongodb - 如何设计 MongoDB 数据模型来存储 Event Sourcing 事件

Question

如果我为每个聚合类型创建一个表(或文档数据库中的文档)，我可以每当我重构 write 端的 microservices 时合并数据库或对它们进行分片，结果应用程序变得更具可扩展性，它也提高了加载 events< 的速度。

当我像这样设计事件存储时，是否有任何我应该注意的副作用？

编辑:

我目前正在使用 MongoDb。

如果我为每个 aggregate id 创建一个 collection 会怎么样？或者每个聚合类型一个数据库，每个聚合id一个集合 ...？

这在性能、数据管理的便利性、可维护性或进一步的可扩展性方面是否存在问题？

Answer 1

If I create a single table (or document in document databases),I can merge databases or shard them whenever I refactor the write microservices, and as the result the application becomes more scalable.

Are there any side effects I should be aware of while I'm designing the event store like that?

我还没有看到任何关于该设计的权威讨论。

事件溯源社区中曾讨论过为每种类型 聚合创建一个单独的表。你可以找到那个讨论 here .执行摘要:更有经验的从业者似乎对有人故意这样做感到吃惊。

您应该记住的一件事是，虽然事件是真实的(它们描述了业务感兴趣的内容)，但聚合是人为的。如果重新设计聚合边界需要将事件到处移动，您可能会不高兴。

以下内容可能有帮助

• https://github.com/NEventStore/NEventStore.Persistence.MongoDB
• http://www.slideshare.net/dbellettini/cqrs-and-event-sourcing-with-mongodb-and-php
• http://blingcode.blogspot.com/2010/12/cqrs-building-transactional-event-store.html