关于mongodb:mongodb存储引擎wired-tiger学习笔记

7次阅读

共计 2401 个字符,预计需要花费 7 分钟才能阅读完成。

从 MongoDB 3.2 版本开始,WiredTiger 成为 MongDB 默认的 Storage Engine,用于将数据长久化存储到硬盘文件中,WiredTiger 提供文档级别(Document-Level)的并发管制,检查点(CheckPoint),数据压缩和本地数据加密(Native Encryption)等性能。

个性

1. checkpoint

Checkpoint 操作开始时,WiredTiger 提供指定工夫点(point-in-time)的数据库快照(Snapshot),该 Snapshot 出现的是内存中数据的一致性视图。当向 Disk 写入数据时,WiredTiger 将 Snapshot 中的所有数据以一致性形式写入到数据文件(Disk Files)中。一旦 Checkpoint 创立胜利,WiredTiger 保障数据文件和内存数据是一致性的,因而,Checkpoint 担当的是还原点(Recovery Point),Checkpoint 操作可能缩短 MongoDB 从 Journal 日志文件还原数据的工夫。

当 WiredTiger 创立 Checkpoint 时,MongoDB 将数据刷新到数据文件(Disk Files)中,在默认状况下,WiredTiger 创立 Checkpoint 的工夫距离是 60s,或产生 2GB 的 Journal 文件。在 WiredTiger 创立新的 Checkpoint 期间,上一个 Checkpoint 依然是无效的,这意味着,即便 MongoDB 在创立新的 Checkpoint 期间遭逢到谬误而异样终止运行,只有重启,MongoDB 就能从上一个无效的 Checkpoint 开始还原数据。

如果要还原在上一个 Checkpoint 之后执行的批改操作,必须应用 Journal 日志文件

2. 预写日志 journal

Journal 是程序写入的日志文件,用于记录 上一个 Checkpoint 之后产生的数据更新,可能将数据库从零碎异样终止事件中还原到一个无效的状态。在数据更新时,先将数据更新写入到 journal 文件。journal 文件会首先写入内存中。所有不超过 128kb 的日志记录都被缓存。当满足以下条件时,journal 会被刷入到磁盘中:

- 每 100ms
- 写操作时加了选项 `{j:true}`
- 达到创立新的 journal 文件的阈值(100mb)

应用 Journal 日志文件还原的过程

WiredTiger 创立 Checkpoint,可能将 MongoDB 数据库还原到上一个 CheckPoint 创立时的一致性状态,如果 MongoDB 在上一个 Checkpoint 之后异样终止,必须应用 Journal 日志文件,重做从上一个 Checkpoint 之后产生的数据更新操作,将数据还原到 Journal 记录的一致性状态,应用 Journal 日志还原的过程是:
1 获取上一个 Checkpoint 创立的标识值:从数据文件(Data Files)中查找上一个 Checkpoint 产生的标识值(Identifier);
2 依据标识值匹配日志记录:从 Journal Files 中搜寻日志记录(Record),查找匹配上一个 Checkpoint 的标识值的日志记录;
3 重做日志记录:重做从上一个 Checkpoint 之后,记录在 Journal Files 中的所有日志记录;

3. 存储构造

数据存储

内存 page 以 B + 树的构造组织,每个节点为一个 page,root page 是 btree 的根节点,internal page 是 btree 的两头索引节点,leaf page 是真正存储数据的叶子节点;btree 的数据以 page 为单位按需从磁盘加载或写入磁盘。

Wiredtiger 采纳 Copy on write(快照)的形式治理批改操作(insert、update、delete),批改操作会先缓存在 cache 里,checkpoint 时,会产生一个新的 root page,此时对页面的批改会新调配索引 page 和数据 page。原来的 B + 树结构理论成为一个快照,由后盾线程执行 checkpoint

索引存储

Mongo 在索引上也辨别为主键索引和非主键索引,这方面与 Mysql 的聚簇索引和二级索引相似,主键索引贮存主键以及数据内容,非主键索引贮存索引列数据以及主键。

  • 搜寻从根节点开始,因为 B 树所有节点都会负责数据存储的工作。所以搜寻的工夫复杂度和数据在构造中的地位强相干,最好的状态是数据在根节点中就搜寻到了,能够间接返回,工夫复杂度是 O(1)。即从均匀搜寻速度来看 MongoDB 查问速度会比 Mysql 更快
  • 单纯从存储构造上看,数据的存储散布在各个节点,因而如果须要对数据进行遍历,则须要对整个树进行数据的读取。然而从整体的角度层面来看,MongoDB 的数据是结构化存储,所有的数据都能够以聚合的形式进行存储,对于数据的遍历需要并没有关系型数据库那么高。在数据的存储底层,Mongo 应用的也是 BSON(Binary Json)进行存储,在类型反对和网络传输效率上相较于 Json 也有了很大的晋升。

MongoDB 是一种面向文档的数据库管理系统,与传统关系型数据库譬如 Mysql 不同的是 Mysql 的数据是扁平化的,构建结构化的数据往往须要通过连表查问在业务中进行组合。而 MongoDB 是面向文档的数据库,数据在存储阶段就是结构化的,聚合的。即一个文档外部就蕴含了其相关联的子结构

空间局部性原理:如果一个存储器的某个地位被拜访,那么将它左近的地位也会被拜访。
B+ 树叶节点两两相连可大大增加区间拜访性,可应用在范畴查问等,而 B - 树每个节点 key 和 data 在一起,则无奈区间查找。

B+ 树能够很好的利用局部性原理,若咱们拜访节点 key 为 50,则 key 为 55、60、62 的节点未来也可能被拜访,咱们能够利用磁盘预读原理提前将这些数据读入内存,缩小了磁盘 IO 的次数。
当然 B + 树也可能很好的实现范畴查问。比方查问 key 值在 50-70 之间的节点。

正文完
 0