CockroachDB 作为 Eventstore 是个好主意吗？答案

【问题标题】：CockroachDB as Eventstore a good idea?CockroachDB 作为 Eventstore 是个好主意吗？
【发布时间】：2017-12-18 18:52:33
【问题描述】：

我正在为我正在考虑在不久的将来开发的 EvenSourcing 和 CQRS 系统寻找 EventStore。我已经开始熟悉 CockroachDB 并且对可扩展性印象深刻，同时拥有所有这些保证，这对于事件存储和查询来说是很好的。

我在这里考虑，我猜一个（？）表用于事件。看起来与此类似的东西：

表格中的列

所以我有两个问题：

【问题讨论】：

看看我的回答：stackoverflow.com/questions/43408599/…
你问它是否会匹配你的性能和规模扩展，但你没有说它们是什么。
@MichalBorowiecki - 基本上 Cockroach DB 声明了一个非常好的扩展属性，平均节点数增加。所以基本上我问一个大事件表是否破坏了 CockroachDB 的假设。
再次，这是非常抽象的。有多大，你期望的吞吐量是多少？没有具体数字就没有什么意义。
应该是抽象的。考虑一下我会从一个 CockroachDB 实例开始，当事情进展顺利时，我最终会在 2 年内得到 3 个或 10 个实例......提前不知道。而且我希望性能（延迟和吞吐量）随着每个新节点线性扩展（听起来像 Cockroach 的文档，但在这方面并不精确）。

【解决方案1】：

Cockroachdb 作为 Event Store 是一个不错的选择。需要注意的一件事是如何选择主键。例如，如果您使用时间戳作为主键，您将看到所有写入都命中同一个节点，因此最好选择一个键，以便及时完成的写入均匀分布在所有节点上。选择一个随机数作为 eventID 并将其用作键。

CockroachDB 尚不（即将推出）支持有关数据库更改的通知，这在将其用作事件存储时很有用

【讨论】：

【解决方案2】：

CockroachDB 现在支持以更改数据捕获 (CDC) 更改馈送的形式通知数据库更改。这是文档：

还有几篇相关的博文：

YouTube 上还录制了 CRDB 更改提要的演示/演示：

【讨论】：