EventStore与MongoDb

Question

EventStore与MongoDb

Jay*_*ete 43 mongodb event-sourcing get-event-store

我想知道使用EventStore有什么好处(http://geteventstore.com)比在MongoDb中自己实现事件采购.

我问的原因是,我们公司有很多人每天与MongoDb合作.但它们不适用于Event Sourcing.虽然他们并没有完全关注这个主题,但他们也不打算在任何地方开始实施.

我即将开始一个非常适合Event Sourcing的项目.大约有16个定义明确的事件,大约有7个定义明确的预测.我说"关于"因为我知道一旦他们看到产品在使用中就会有更多的预测和事件需求.

这种方法将首先是API,我们组织的其他部分将使用REST Api.

虽然我已经按照Greg Young定义的方式阅读了很多关于事件采购的内容,但我从未实际实施过Event Sourcing解决方案.

这是一个绿色的田野项目.没有技术限制,因为我们将把所有内容公开为REST接口.因此,如果有人有使用MongoDb的EvenStore或Event Sourcing的工作经验,请赐教.

关于事件采购的几乎完全不相关的问题:您是否曾直接查询事件存储？或者您是否总是创建新的预测和重播事件以填充这些预测？

Answer 1

Gre*_*ung 51

免责声明我是Greg Young(如果你不能读我的名字:))

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

1)有一条评论说我们只在自定义版本的单声道上运行,这是一个细节但是......事实并非如此(并且已经超过一年了).我们正在等待我们对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会更有意义.

谢谢你的回答格雷格.该项目已被推迟,但与我的开发人员一起,我们对此进行了更多调查.做了一个小小的原型,并决定在EventStore上.不知道你在哪里读到我声称EventStore不是开源的.它是开源的事实是它被考虑的原因.至于比较苹果和橘子,那是因为我根本不知道更好. (4认同)
我知道你是正确工具的主要倡导者,卡夫卡更直接的比较.但是上面的案例指的是事件来源,我可以看到人们推理Mongo,因为他没有定义很多阅读的复杂性.Mongo给了他一些游戏+他不必考虑他的TTL配置将如何发挥(或者在Kafka必须设置ZooKeeper的情况下).由于时间原因,我不得不退出EventStore,开始考虑使用Mongo进行简单的事件读取.同时缺少版本更新.很高兴听到单声道版本向前发展.期待MS开放.Net的vNext (3认同)

Answer 2

bas*_*man 7

看到其他回复并没有谈到EventStore中的工具或好处,只是提到MongoDB的好处,我将会参与其中.但请注意,我的经验是有限的.

我将从缺点开始......

有很多签到可以导致决定您将积极支持自己的版本.虽然团队一直在巩固他们的版本,但他们已经在发布后的18个月内到达版本3应该是一个指示,你必须提升你支持的另一个更新版本的版本(这也可能影响平台你选择部署到).
它不会轻易地在每个平台上运行(特别是如果您尝试迁移到云环境或基于docker的lxc容器).其中一些原因是围绕其他数据库(如Mongo)的社区.但该团队似乎一直在努力摆脱读/写性能,同时保持跨平台的稳定性.随着时间的推移,我发现你不希望偏离裸机操作系统的实施,而今天这个时代并没有吸引力.
使用特殊版本的Mono.寻找对旧版Mono的支持只会使这个过程更像是根管.
要充分利用EventStore的性能,您需要考虑您的架构.EventStore输出到平面文件,事件数据可以快速增长.什么是磁盘的故障率是你持久的数据.如何压缩事物？归档？您有很多控制权,控制权用于将数据存储为事件.然而,虽然我确信Greg Young本人可以引用我的坟墓长期优化和保存磁盘的功能,但我很可能会找到一个成熟的Mongo社区,这个社区遇到类似情况.

和优点......

RESTful - 它是AtomPub.你的流不够具体吗？创建另一个并做http直到你心中的内容.关注路由确实做了一个http转发.关注安全性将http代理放在前面.简单!
当事件开始生成新数据时,您有一套很好的工具和用户界面可用于测试和构建投影(例如,使用chrome浏览器作为调试投影的方法......他们用java脚本编写)
读取性能 - 由于应用程序输出到平面文件,您可以获得内核级缓存,并通过http直接暴露它们.您的流中还有索引用于查询针对较大数据集的投影(但我真的感觉索引性能会随着时间的推移而逐渐增加).

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

归档时间：	12 年，4 月前
查看次数：	10498 次
最近记录：	11 年，6 月前