EventStore与MongoDb的比较

Question

我想知道使用EventStore (http://geteventstore.com)相比在MongoDb中自己实现事件溯源，有什么优势。

我这样问的原因是，我们公司有很多人每天都在使用MongoDb。尽管他们不完全不了解事件溯源，但也不会在任何地方开始实现它。

我即将开始一个非常适合事件溯源的项目。大约有16个非常明确定义的事件和7个明确定义的投影。我之所以说“大约”是因为我知道一旦他们看到产品的使用情况，就会对更多的投影和事件提出要求。

方法将是API优先，使用REST Api，我们组织的其他部分将要消耗该接口。

虽然我已经读了很多关于Greg Young定义的事件溯源的内容，但我从来没有实现过事件溯源解决方案。

这是一个全新的项目。由于我们将把所有东西公开为REST接口，所以没有技术限制。如果有人有使用EvenStore或带有MongoDb的事件溯源的工作经验，请启发一下我。

还有一个几乎没有关系的问题：您是否直接查询事件存储？还是总是创建新的投影并重放事件以填充这些投影？

- Jay Pete

Answer 1

免责声明：我是Greg Young（如果你看不到我的名字的话 :)）。

---

虽然我认为这个问题很奇怪，但我还是要回答它，尽管它很可能会被删除。答案非常奇怪。我不会花时间逐个回答每个回复，而是将所有评论都放在这个回复中。

1）有人评论说我们只运行在自定义版本的mono上，这是一个细节，但是...事实并非如此（已经超过一年了）。我们正在等待我们对mono所做的关键补丁（例如threadpool.c）被合并到他们的主分支。这已经发生了。

2）EventStore是3条款BSD许可证。不知道你怎么能说我们不是开源的。我们也有一家公司支持，并提供商业支持。

3）有人提到我们将在9月份进入第3版。第1版于2年前发布。第2版增加了集群（显然与单节点相比有一些破坏性变化）。第3版正在添加大量内容，包括具有竞争消费者功能的能力。在这段时间内，实际客户端协议的变化很少（特别是对于那些使用HTTP API的人）。

然而，对我来说真正令人不安的是建议者似乎不理解他们在比较什么。这大约相当于我说“我应该使用neo4j还是leveldb？”你可以在leveldb上构建自己的图形数据库，但那需要很多工作。

在这种情况下，Mongo将成为事件存储中的存储引擎，OP必须自己编写它。如果您想执行最基本的操作，则在存储引擎之上编写生产质量的事件存储是一个非常重要的练习。

我对这个问题的邮件列表做出了回应：（链接）：

如何使用Mongo完成以下操作？：

按顺序/乐观并发等方式将事件写入/从流中读取

然后：

您的投影不希望以与写入流相同的方式读取流，投影通常对事件类型感兴趣，并希望所有类型为T的事件无论写入到哪个流中都能正确排序。

您可能还希望能够随时从推送事件通知切换到处理拉取信息（例如轮询）等。

如果比较的是Kafka、datomic和Event Store，那会更有意义。

- Greg Young

---

我知道你很注重选择正确的工具，而Kafka是一个更直接的比较。但是在上面提到事件溯源时，我能理解人们推荐MongoDB，因为他没有定义太多关于读取复杂性的东西。MongoDB给了他一些自由度，同时他不必考虑TTL配置如何发挥作用（或者在Kafka的情况下设置ZooKeeper）。由于时间关系，我已经放弃使用EventStore并开始考虑MongoDB来进行简单的事件读取。与此同时，我缺少版本更新。很高兴听到MongoDB版本已经更新。期待使用微软开放的.Net vNext。 - baseman

感谢您的回答，Greg。该项目已经被推迟，但是我和其他开发人员一起进一步调查了它。我们做了一个小型原型，并决定使用EventStore。我不确定您在哪里看到我声称EventStore不是开源的。它是开源的事实正是考虑它的原因。至于比较苹果和橘子，那是因为我只是不知道更好的方式。 - Jay Pete

@JayPete 我刚刚收到了一条通知，让我回来看你的评论。我的 OSS 部分回答是针对被踩的评论而不是你最初的问题。 - Greg Young

我们之前在虚拟化基础设施上大量使用GetEventStore，导致出现了问题（不推荐这样做）。除此之外，如果你需要删除特定事件，我建议你考虑一下...我们想到了一种引入空事件的方法来“删除”其他事件的处理（例如在处理中卡住的事件），但这种机制并不理想。 - andrew pate

Answer 2

鉴于其他回复没有讨论EventStore的工具或优点，只提到了MongoDB的好处，我也来说一下。但请注意，我的经验有限。

首先，我会从缺点开始...

- 有很多提交，这可能导致您决定哪个版本是您要积极支持的。虽然团队正在巩固其发布，但他们在发布不到18个月后就到达了3.0版本，这应该表明您必须将您支持的版本升级到另一个更近期的版本（这也可能影响您选择部署的平台）。 - 它不会轻松地在每个平台上工作（特别是如果您试图转移到云环境或基于Docker的LXC容器）。其中一些是由于周围其他数据库的社区，如Mongo。但是，团队似乎一直在努力提高读/写性能，同时保持跨平台稳定性。随着时间的推移，我发现您不希望偏离裸机操作系统实现太远，这在这个时代并不吸引人。 - 使用特殊版本的Mono。寻找旧版Mono的支持只会使过程变得更加痛苦。 - 要充分利用EventStore的性能，您确实需要考虑您的架构。EventStore输出到平面文件，事件数据可以很快增长。您正在持久化数据的磁盘的故障率是多少？如何压缩？存档？等等。您有很多控制权，而这种控制权旨在将您的数据存储为事件。但是，虽然我相信Greg Young本人可以引用优化和保存您的磁盘的功能，但我很可能会找到一个成熟的Mongo社区，他们已经有了运行类似情况的经验。

接下来是优点...

- RESTful - 它是AtomPub。您的流不够特定吗？创建另一个并进行http获取直到满意。担心路由，进行http转发。担心安全性，在前面放置http代理。简单！ - 您有一套不错的工具和UI，可用于测试和构建投影，因为您的事件开始生成新数据（例如，使用Chrome浏览器作为调试投影的方式...是的，它们是用JavaScript编写的）。 - 读取性能 - 由于应用程序输出到平面文件，因此您可以获得内核级缓存，并通过http轻松公开它们。还可以跨流索引以查询针对较大数据集的投影（但我真的感觉索引性能会随着时间的推移而逐渐提高）。

个人而言，我不会将其用于核心/使命关键/或不断增长的应用程序！但是，如果您有一个保持事件环境有趣的边缘案例，那么我会尝试一下！个人而言，现在必须坚持使用Mongo。

- baseman