MongoDB征文| Mongodb WiredTiger 时间戳 来自wiredtiger 内部的声音

MongoDB征文| Mongodb WiredTiger 时间戳 来自wiredtiger 内部的声音_第1张图片

​偶然看到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征文| Mongodb WiredTiger 时间戳 来自wiredtiger 内部的声音_第2张图片

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

 

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

 

MongoDB征文| Mongodb WiredTiger 时间戳 来自wiredtiger 内部的声音_第3张图片

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

 

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

 

MongoDB征文| Mongodb WiredTiger 时间戳 来自wiredtiger 内部的声音_第4张图片

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

MongoDB征文| Mongodb WiredTiger 时间戳 来自wiredtiger 内部的声音_第5张图片

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

 

MongoDB征文| Mongodb WiredTiger 时间戳 来自wiredtiger 内部的声音_第6张图片

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

 

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

 

MongoDB征文| Mongodb WiredTiger 时间戳 来自wiredtiger 内部的声音_第7张图片

 

本文参加MongoDB中文社区征文活动,链接:https://mongoing.com/mongodb-blog-contest-2020-may

你可能感兴趣的:(MONGODB)