EventStore 与 MongoDb [关闭]答案

【问题标题】：EventStore vs. MongoDb [closed]EventStore 与 MongoDb [关闭]
【发布时间】：2020-10-27 20:23:15
【问题描述】：

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

我问的原因是，我们公司有很多人每天都在使用 MongoDb。但它们不适用于事件溯源。虽然他们对这个主题并不完全一无所知，但他们也不打算在任何地方开始实施它。

我即将开始一个非常适合事件溯源的项目。大约有 16 个定义明确的事件，以及大约 7 个定义明确的预测。我说“关于”是因为我知道一旦他们看到正在使用的产品，就会有更多的预测和事件的需求。

该方法将首先使用 API，并使用我们组织的其他部分将使用的 REST Api。

虽然我已经阅读了很多关于 Greg Young 定义的事件溯源的信息，但我从未真正实施过事件溯源解决方案。

这是一个绿地项目。没有技术限制，因为我们将把所有东西都公开为 REST 接口。因此，如果有人有使用 MongoDb 的 EvenStore 或 Event Sourcing 的工作经验，请赐教。

还有一个关于事件溯源的几乎完全不相关的问题：你有没有直接查询事件存储？或者您是否总是创建新的投影和重播事件来填充这些投影？

【问题讨论】：

标签： mongodb event-sourcing eventstoredb

【解决方案1】：

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

我将回答这个问题，尽管我相信它可能会被删除。这个问题对我来说有点奇怪，但答案相当奇怪。我不会花时间单独回答每个回复，而是会将我所有的 cmets 都放在这个回复中。

1) 有一条评论说我们只在自定义版本的 mono 上运行，这是一个细节，但是......情况并非如此（并且已经超过一年了）。我们正在等待我们为单声道制作的关键补丁（例如 threadpool.c 以击中他们的主人）。这已经发生了。

2) EventStore 是 3-clause BSD 许可的。不知道你怎么能声称我们不是开源的。我们还有一家公司支持它并提供商业支持。

3) 有人提到我们将在 9 月升级到第 3 版。第 1 版在 2 年前发布。版本 2 添加了集群（显然与单节点相比有一些重大更改）。第 3 版添加了大量内容，包括拥有竞争消费者的能力。在这段时间里，实际客户端协议几乎没有什么变化（尤其是对于那些使用 HTTP API 的客户端）。

然而，这些建议让我真正感到不安的是，他们似乎不明白自己在比较什么。这大致相当于我说“我应该使用 neo4j 还是 leveldb？”。您可以在 leveldb 之上构建自己的图形数据库，但这将是相当多的工作。

在这种情况下，Mongo 将是 OP 必须自己编写的事件存储上的存储引擎。如果您想拥有最基本的操作，那么在存储引擎之上编写生产质量事件存储是一项不平凡的练习。

我写了this in response to the mailing list equivalent of this question：

您将如何使用 Mongo 执行以下操作？：

通过排序/乐观并发/等向/从流中写入和读取事件

然后：

您的投影不希望以与写入相同的方式从流中读取数据，投影通常对事件类型感兴趣，并且希望所有类型为 T 的事件，而不管写入的流和顺序如何。

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

如果将 Kafka、datomic 和 Event Store 进行比较会更有意义。

【讨论】：

我知道您是正确工具的大力倡导者，而 Kafka 更适合直接比较。但是上面的案例是指事件溯源，我可以看到人们在推理 Mongo，因为他没有定义读取的很多复杂性。 Mongo 给了他一些机会 + 他不必考虑他的 TTL 配置将如何发挥作用（或者在 Kafka 必须设置 ZooKeeper 的情况下）。由于时间关系，我不得不退出 EventStore，开始考虑使用 Mongo 进行简单的事件读取。同时缺少版本更新。很高兴听到单声道版本向前发展。期待 vNext 与 MS 开放 .Net
感谢您的回答格雷格。该项目已被推迟，但与我的其他开发人员一起，我们对其进行了更多研究。做了一个小原型，并决定使用 EventStore。不确定您在哪里读到我声称 EventStore 不是开源的。它是开源的事实是它甚至被考虑的原因。至于比较苹果和橙子，那是因为我根本不知道更好。
@JayPete 我收到了关于此的通知，这导致我刚才回来查看您的评论。我的答案的 OSS 部分是投反对票的评论，而不是您原来的问题。
我们很痛苦，因为我们在虚拟化基础架构上大量使用了 GetEventStore（不推荐）。除此之外，我会考虑您是否需要删除特定事件......我们想出了一种方法来引入一个 void 事件来“删除”其他事件的处理（例如那些在处理中卡住的事件），但这种机制是不理想。

【解决方案2】：

看到其他回复没有谈论 EventStore 中的工具或好处，而只提到 MongoDB 的好处，我会插话。但请注意，我的经验有限。

我将从缺点开始...

有很多签入可以决定您要积极支持自己的版本。虽然团队一直在巩固他们的版本，但他们在发布后不到 18 个月就达到了第 3 版，这应该表明您必须将您支持的版本拉到另一个更新的版本（这也会影响平台您选择部署到）。
它不会在每个平台上轻松运行（尤其是当您尝试迁移到云环境或基于 docker 的 lxc 容器时）。其中一些是由于围绕其他数据库（如 Mongo）的社区。但是该团队似乎一直在努力提高读/写性能，同时保持跨平台稳定性。随着时间的推移，我发现您不希望与裸机 OS 实现偏离太远，因为这种实现在当今时代并不吸引人。
使用特殊版本的 Mono。寻找对旧版本 Mono 的支持只会使这个过程更像是根管。
要充分利用 EventStore 的性能，您确实需要考虑您的架构。 EventStore 输出到平面文件和事件数据可以很快增长。您将数据保存到的磁盘的故障率是多少。东西是如何压缩的？存档？等等。您有很多控制权，并且该控制权旨在将您的数据存储为事件。但是，虽然我确信 Greg Young 本人可以在我的坟墓中引用我的坟墓，这些功能可以长期优化和保存您的磁盘，但我很可能会找到一个有遇到类似案例经验的成熟 Mongo 社区。

还有专业人士...

RESTful - 它是 AtomPub。您的流不够具体吗？创建另一个并进行 http 获取，直到您心满意足。关心路由做一个http转发。担心安全性将http代理放在前面。简单！
当您的事件开始生成新数据时，您有一套很好的工具和 UI 用于测试和构建您的预测（例如，使用 chrome 浏览器作为调试预测的一种方式……是的，它们是用 java 编写的脚本）
读取性能 - 由于应用程序输出到平面文件，您可以获得内核级缓存并通过 http 公开它们。此外，您的流中还有索引，用于查询针对更大数据集的预测（但我真的感觉索引性能会随着时间的推移而逐渐提升）。

我个人不会将其用于核心/关键任务/或不断增长的应用程序！但是，如果您有一个侧面案例来保持您的事件环境有趣，那么我会放弃它！我个人现在必须坚持使用 Mongo。

【讨论】：