MongoDB - 架构篇（逻辑结构、数据模型、WiredTiger存储引擎、数据落盘、checkPoint、Journaling日志恢复）

Aaron学习之路
388 阅读5分钟

1. 逻辑结构

image.png

MongoDB 与 MySQL 中的架构相差不多，底层都使用了可插拔的存储引擎以满足用户的不同需要。用户可以根据程序的数据特征选择不同的存储引擎，在最新版本的 MongoDB 中使用了 WiredTiger 作为默认的存储引擎，WiredTiger 提供了不同粒度的并发控制和压缩机制，能够为不同种类的应用提供了最好的性能和存储率。

在存储引擎上层的就是 MongoDB 的数据模型和查询语言了，由于 MongoDB 对数据的存储与 RDBMS 有较大的差异，所以它创建了一套不同的数据模型和查询语言。

2. 数据模型

描述数据模型：

  • 内嵌：内嵌的方式指的是把相关联的数据保存在同一个文档结构之中。MongoDB的文档结构允许一个字段或者一个数组内的值作为一个嵌套的文档。
  • 引用：引用方式通过存储数据引用信息来实现两个不同文档之间的关联，应用程序可以通过解析这些数据引用来访问相关数据。

如何选择数据模型？

选择内嵌:

  • 数据对象之间有包含关系, 一般是数据对象之间有一对多或者一对一的关系。
  • 需要经常一起读取的数据。
  • 有 map-reduce/aggregation 需求的数据放在一起，这些操作都只能操作单个 collection。

选择引用:

  • 当内嵌数据会导致很多数据的重复，并且读性能的优势又不足以覆盖数据重复的弊端 。
  • 需要表达比较复杂的多对多关系的时候 。
  • 大型层次结果数据集，嵌套不要太深。

3. 存储引擎

3.1 概述

存储引擎是MongoDB的核心组件，负责管理数据如何存储在硬盘和内存上。MongoDB支持的存储引擎有MMAPv1 ，WiredTiger和InMemory。

InMemory存储引擎用于将数据只存储在内存中，只将少量的元数据(meta-data)和诊断日志 （Diagnostic）存储到硬盘文件中，由于不需要Disk的IO操作，就能获取所需的数据，InMemory存储引擎大幅度降低了数据查询的延迟（Latency）。

从MongoDB3.2开始默认的存储引擎是WiredTiger，3.2版本之前的默认存储引擎是MMAPv1

MongoDB4.x版本不再支持MMAPv1存储引擎。

storage:
    ## 是否开启日志
    journal:
        enabled: true
    dbPath: /data/mongo/
    ##是否一个库一个文件夹
    directoryPerDB: true
    ##数据引擎
    engine: wiredTiger
    ##WT引擎配置
    WiredTiger:
        engineConfig:
            ##WT最大使用cache（根据服务器实际情况调节）
            cacheSizeGB: 2
            ##是否将索引也按数据库名单独存储
            directoryForIndexes: true
            ##日志是否要开启压缩，采用什么压缩形式
            journalCompressor: none（默认snappy）
        ##集合压缩配置
        collectionConfig:
            blockCompressor: zlib (默认snappy,还可选none、zlib)
        ##索引配置
        indexConfig:
            ## 是否开启索引前缀压缩
            prefixCompression: true

3.2 WiredTiger存储引擎优势

  1. 文档空间分配方式

    • WiredTiger采用的是B+Tree存储
    • MMAPv1 线性存储

  2. 并发级别

    • WiredTiger文档级别锁
    • MMAPv1引擎采用表级锁

  3. 数据压缩

    • WiredTiger采用snappy（默认）和zlib压缩表数据
    • WiredTiger相比MMAPv1无压缩，空间节省数倍

  4. 内存使用

    • WiredTiger可以指定内存的使用大小

  5. Cache使用

    • WriedTiger引擎采用了二阶缓存WiredTiger Cache, File System Cache来保证Disk上数据的一致性
    • MMAPv1只有journal日志

3.3 WiredTiger引擎包含的文件和作用

  • WiredTiger.basecfg：存储基本配置信息，与 ConfigServer有关系
  • WiredTiger.lock：定义锁操作
  • WiredTiger.turtle：存储WiredTiger.wt的元数据
    • WiredTiger.wt：存储table*的元数据
      • table*.wt：存储各张表的数据
  • journal：存储WAL(Write Ahead Log)，只记录数据的变更

image.png

3.4 WiredTiger存储引擎实现原理

3.4.1 数据落盘

WiredTiger的写操作会默认写入 Cache ，并持久化到journal 日志文件 （Write Ahead Log），每60s或Log文件达到2G做一次 checkpoint 产生快照文件。

WiredTiger初始化时，恢复至最新的快照状态，然后再根据WAL恢复数据，保证数据的完整性。

image.png

WiredTiger采用Copy on write的方式管理写操作（insert、update、delete），写操作会先缓存在Cache里，持久化时，写操作不会在原来的leaf page上进行，而是写入新分配的page，每次checkpoint都会产生一个新的root page。

  • Copy on write ： 持久化的时候，会复制一个新的节点，将修改的信息写入到新的节点中，然后将指针指向新的节点

Cache是基于B+Tree的，节点是一个Page，Root Page是根节点，Internal Page是中间索引节点，Leaf Page真正存储数据，数据以Page为单位读写。

3.4.2 checkpoint机制

1. 对所有的table进行一次checkpoint，每个table的checkpoint的元数据更新至WiredTiger.wt

2. 对WiredTiger.wt进行checkpo, 将该table checkpoint的元数据更新至临时文件WriedTiger.turtle.set

3. 将WriedTiger.turtle.set 重命名为 WriedTiger.turtle

4. 上述过程如果中间失败，WiredTiger在下次连接初始化时，首先将数据恢复至最新的快照状态，然后根据WAL恢复数据，以保证存储可靠性。

3.4.3 Journaling日志恢复机制

在数据库宕机时 , 为保证 MongoDB 中数据的持久性，MongoDB 使用了 Write Ahead Logging 向磁盘上的 journal 文件预先进行写入。除了 journal 日志，MongoDB 还使用检查点（checkpoint）来保证数据的一致性，当数据库发生宕机时，就需要checkpoint 和 journal 文件协作完成数据的恢复工作。

  • 在数据文件中查找上一个检查点的标识符
  • 在 journal 文件中查找标识符对应的记录
  • 重做对应记录之后的全部操作

image.png

核心思想：

  • 读不加锁，读写不冲突
  • WAL-写入性能得到保障
    • 加缓存的方式写日志，logBuffer
  • 读取数据的性能，是通过B+树来进行保障的
  • 脏页落盘，通过checkpoint来进行，60s一次或者日志文件大于2G
avatar
文章
阅读
粉丝