mongodb - 'majority committed data' 和 'the snapshot of majority committed data' 有什么区别

Question

多数提交数据和多数提交数据的快照之间有什么区别，我应该关心它吗？如果这两个概念完全不同，何时以及如何选择一个？
我在阅读有关 mongodb 中事务的引用时发现了这些描述:https://docs.mongodb.com/manual/core/transactions/#transaction-options-read-concern-write-concern-read-preference ，但我无法理解 readConcern: majority 之间的区别和 readConcern: snapshot .

Answer 1

不幸的是，文档确实将这些概念视为理所当然，但区别并不那么容易理解。我什至不确定我是否正确，但 Aly Cabral 在 her talk about distributed transactions 中做了这个例子.
如果我指定 readConcern: snapshot ，那么我将在所有分片中拥有一致的时间点。

相反，如果我指定 readConcern: local或 readConcern: majority ，然后我将为每个分区提供一致的快照。

她最后说 readConcern: snapshot ，协调跨分片集群的快照查找可能很昂贵，因此您应该权衡每个 readConcern 的利弊。 .

她做了一个很好的例子，这些图片真的对我有帮助，但我认为有必要补充一下:

time显示的字段是指 ClusterTime 1:这是一个基于混合逻辑时钟的集群范围的逻辑时钟。每个分片的主分片都有自己的 ClusterTime值(value)并遵守以下规则:

ClusterTime Increment rule:The ClusterTime is incremented (“ticks”) only when there isa write to a primary node’s replication operation log(oplog).ClusterTime Distribution rule:Cluster nodes (mongod, mongos, config server, clients)always track and include the greatest known ClusterTimewhen sending a message.

如果在第二张图片中 ClusterTime交易的选择为 102，分片具有 ClusterTime 110 可能有我不想在事务期间看到的多数提交的更改。从 MongoDB 5.0 开始，这个时间是可配置的:

readConcern: {
    level: "snapshot",
    atClusterTime: Timestamp(1613577600, 1)
}

我正在写一个 report关于 MongoDB 事务，我已经解释了这些概念和许多其他概念。如果您发现错误/需要改进的地方，我将非常感谢任何人的帮助。

1: https://dl.acm.org/doi/pdf/10.1145/3299869.3314049