在事件存储中存储事件时,存储事件的顺序非常重要,尤其是在稍后投影事件以恢复实体当前状态时。
考虑到它的速度和灵活的模式(并且经常被推荐),MongoDB 似乎是持久化事件存储的一个不错的选择,但是 MongoDB 中没有事务之类的东西,这意味着无法保证正确的事件顺序。
鉴于这一事实,如果您正在寻找一致的事件存储,您应该不使用 MongoDB,而是坚持使用传统的 RDMS,还是有办法解决这个问题?
在事件存储中存储事件时,存储事件的顺序非常重要,尤其是在稍后投影事件以恢复实体当前状态时。
考虑到它的速度和灵活的模式(并且经常被推荐),MongoDB 似乎是持久化事件存储的一个不错的选择,但是 MongoDB 中没有事务之类的东西,这意味着无法保证正确的事件顺序。
鉴于这一事实,如果您正在寻找一致的事件存储,您应该不使用 MongoDB,而是坚持使用传统的 RDMS,还是有办法解决这个问题?
我不熟悉您使用的“事件存储”一词,但我可以解决您问题中的一些问题。我相信将 MongoDB 用于你想要的东西可能是合理的,但要小心一点。
在 MongoDB 中,每个文档都有一个_id
默认ObjectId
格式的字段,该字段由服务器标识符、时间戳和序列计数器组成。因此,您可以对该字段进行排序,并且您将按照创建顺序获取对象,前提是这些ObjectId
s 都是在同一台机器上创建的。
大多数 MongoDB 客户端驱动程序_id
在向数据库发送插入命令之前在本地创建字段。因此,如果您有多个客户端连接到数据库,排序方式_id
不会做您想要的,因为它将首先按服务器哈希排序,这不是您想要的。
但是,如果您可以说服您的 MongoDB 客户端驱动程序不包含_id
在插入命令中,那么服务器将为每个文档生成 ObjectId,并且它们将具有您想要的属性。这样做将取决于您使用的语言,因为每种语言都有自己的客户端驱动程序。仔细阅读驱动程序文档或深入研究它们的源代码——它们都是开源的。大多数驱动程序还包括一种向服务器发送原始命令的方法。所以如果你insert
手动构建一个命令,这肯定会让你做你想做的事。
如果您的系统如此庞大以至于单个数据库服务器无法处理您的所有写入流量,这将崩溃。需要每秒写入数千条记录的 MongoDB 解决方案是设置一个分片数据库。在这种情况下,ObjectId 将再次由不同的机器创建,并且不会具有您想要的良好排序属性。如果您担心超出单个服务器的写入容量,您应该寻找另一种提供分布式序列号的技术。