Mongodb WiredTiger 时间戳 来自wiredtiger 内部的声音

偶然看到Wiredtiger团队总监Michael Cahill，关于timestamp的一段视频，写成文字和大家share，如有错误，请及时指正。Michael Cahill在2011年与另一个合伙人共同开发了wiredtiger。

正文，以下为译文，由于是视频，所以难免有可能有错误领会的地方，如果有，请大仙们指正

——————————————————————————————

MongoDB 中的wiredtiger 是支持事务的一个数据库引擎，而解决这个问题是比较困难的，这里我将解释他们是如何工作的，主要是此次的话题是围绕着wiredtiger的时间戳。我们知道mongodb 中比较特殊的是oplog log ,简称为operation log,系统中的操作顺序的记录在oplog中，对于wiredtige 提供了一个一致性版本控制称作多版本控制的东西，对于并行的处理中如何进行顺序记录的，如果不能确定准确的oplog 中的记录顺序，则复制集中的其他机器将不能获得准确的数据复制顺序。所以我们采用timestamp的方式来将信息更有效的在wiredtiger 中的storage laryer 层实现，并进行更有效的控制。

在开始讲主题的之前，我们先回顾一下wiredtiger 的内部的数据存储结构，无论是数据还是索引的存储结构都是以树状结构存储的，数据是以主键的树形结构存储，叶子节点中的key 和 values 是存储在bson,无论你是插入一个新的document, 还是更新一个document 我们都称之为update structure. 并且更新内部会带有一些关于transaction的信息，是否与接下来的操作有关联。当此时有读操作进来，则他们需要考虑和计算给出正确的 lists 进行返回。

上面的工作其实就是多版本控制，这在MONGODB 存在了很长时间了，我们主要讲的是，我们对现有的数据结构进行了改造，在数据结构中添加了时间戳，这个结构将告诉存储引擎事务发生的顺序。其实两句话就可以解释，timestamp 解决了事务的顺序性以及读取数据的是在哪个时间段的。这样即使我们并行处理，掺杂进很多的不同的事务以及不同的顺序，但timestamp 保证了正确的结果。

当我们使用了一个clever technique 将oplog并行通过多线程应用到其他的secondary mongodb上，并且这些数据块被分割，在到目的端进行组合，应用。这些更新很可能不是按照顺序，在primary上我们是按照 100 101 102的顺序，而到了secondary 上很可能就变成 101 100 102 的顺序。

那么时间戳可以解决什么问题

1 对于查询，当101和102被应用后，100并未被应用在secondary上，则查询中不会显示 101 102 有关的数据， 这就保证了数据的一致性。

2 上面提到了oplog 会分割成多个batches 被多个线程来应用，而在从库上读取是使用locks 来进行的，在MONGODB 有一个global lock 在 secondary 上释放这个全局锁，那应用的数据再能在，secondary 上被读取。这样的可以引申到在唯一索引的document上，在有两个线程操作的documents上，我们必须要让所有的结果是正确的。

3 timestamp 同时也要应用到复制中的rollback ，在讲之前大家应该都明白MONGODB 复制中的大多数的概念。通过上图我们可以通过对比时间戳来获得大多数的secondary 上2 号数据点已经被应用。这将对节点失败后的选举等等都有相关的联系。同时对于节点切换后的数据拽取都有相关的作用。

同时在新主产生后，我们也会有相关的历史数据决定旧的主是否还能rejoin进复制集中，上图很明显older prmary将不能被重新加入到复制集中。

总结上面的东西，wiredtiger 通过timestamp的排序工作对例如复制， 数据回滚，以及与index 有关的维护工作进行了有益的支持，下一步我们将针对索引的维护工作进行优化，将两种建立索引的优点合二为一，同时 我们会对long -running reads 方面的工作进行优化，现在的事务基本是基于 short running transactions, 但我们知道现在有一些客户查询大量的数据的事务，我们目前正在做一些底层的工作，使得我们的数据库引擎更加有效的处理类似的工作。