分布式专题(8)之MongoDB存储原理&多文档事务详解

一、MongoDB存储原理

        存储引擎是数据库的组件，负责管理数据如何存储在内存和磁盘上，MongoDB支持多个存储引擎，因为不同的存储引擎对特定的工作负载表现更好，选择合适的存储引擎可以显著影响应用程序的性能。

1.1 WiredTiger介绍

        MongoDB从3.0开始引入可插拔存储引擎的概念，主要有MMAPV1、WiredTiger存储引擎可供选择。从MongoDB 3.2开始，WiredTiger存储引擎是默认的存储引擎。从4.2版开始，MongoDB删除了废弃的MMAPv1存储引擎。

1.2 WiredTiger读写模型

        读缓存：理想情况下，MongoDB可以提供进似与内存级别的读写性能。WiredTiger引擎实现了数据的二级缓存，第一层是操作系统的页面缓存，第二层则是引擎提供的内部缓存。

        读数据的流程如下：

• 数据库发起Buffer IO读操作，由操作系统将磁盘数据页加载到文件系统 得页缓存区；
• 引擎层读取页缓存区的数据，进行解压后存放到内部缓存区；
• 在内存中完成匹配查询，将结果返回给应用。

        MongoDB为了尽可能保证业务查询的“热数据”能快速被访问，其内部缓存的默认大小达到了内存的一半，该值由wiredTigerCacheSize参数指定，其默认的计算公式如下：

wiredTigerCacheSize=Math.max(0.5*(RAM-1GB),256MB)

        写缓存：当数据发生 写入时，MongoDB并不会立即持久化到磁盘上，而是现在内存中记录这些变更，之后通过CheckPoint机制将变化的数据写入磁盘。这样子处理主要有以下两个原因：

• 如果每一次写入都操作磁盘I/O，那么开销会非常大，而且响应时长会比较大。
• 多个变更的写入可以尽可能进行I/O合并，降低资源负荷；

        那MongoDB如何保证单机的数据可靠性，主要包括以下两个部分：

        CheckPoint（检查点）机制：快照（snapshot）描述了某一时刻（point-in-time）数据在内存中的一致性视图，而这种数据的一致性是WiredTiger通过MVCC（多版本并发控制）实现的。当建立CheckPoint时，WiredTiger会在内存中建立所有数据的一致性快照，并将该快照覆盖的所有数据变化一并进行持久化（fsync）。成功之后，内存中数据的修改才得以真正保存。默认情况下，MongoDB每60s建立一次CheckPoint，在检查点写入过程中，上一个检查点仍然是可用的。这样可以保证一旦出错，MongoDB仍然能恢复到上一个检查点。

          Journal日志：Journal是一种预写式日志（write ahead log）机制，主要用来弥补CheckPoint机制的不足。如果开启了Journal日志，那么WiredTiger会将每个写操作的redo日志写入Journal缓冲区，该缓冲区会频繁地将日志持久化到磁盘上。默认情况下，Journal缓冲区每100ms执行一次持久化。此外，Journal日志达到100MB，或是应用程序指定journal：true，写操作都会触发日志的持久化。一旦MongoDB发生宕机，重启程序时会先恢复到上一个检查点，然后根据Journal日志恢复增量的变化。由于Journal日志持久化的间隔非常短，数据能得到更高的保障，如果按照当前版本的默认配置，则其在断电情况下最多会丢失100ms的写入数据。

        WiredTiger写入数据流程：

         事务（transaction）是传统数据库所具备的一项基本能力，其根本目的是为数据的可靠性与一致性提供保障。而在通常的实现中，事务包含了一个系列的数据库读写操作，这些操作要么全部完成，要么全部撤销。例如，在电子商城场景中，当顾客下单购买某件商品时，除了生成订单，还应该同时扣减商品的库存，这些操作应该被作为一个整体的执行单元进行处理，否则就会产生不一致的情况。

        数据库事务需要包含4个基本特性，即常说的ACID，具体如下：

2.3 MongoDB对事务的支持

2.3.1 writeConcern

        writeConcern 决定一个写操作落到多少个节点上才算成功。MongoDB支持客户端灵活配置写入策略（writeConcern），以满足不同场景的需求。

        语法格式：

{ w: <value>, j: <boolean>, wtimeout: <number> }

         1）w: 数据写入到number个节点才向用客户端确认

{w:0}对客户端的写入不需要发送确认，适用于性能要求高，但不关注正确性的场景

{w:1}默认的writeConcern，数据写入到Primary就向客户端发送确认

{w:"majority"}数据写入到副本集大多数成员后向客户端发送确认，适用于数据安全性要求比较高的场景，该选项会降低写入性能

         2）j: 写入操作的journal持久化后才向客户端确认

默认为{i: false}，如果要求Primary写入持久化了才向客户端确认，则指定该选项为true

         3）wtimeout: 写入超时时间，仅w的值大于1时有效。

当指定{w:}时，数据需要成功写入number个节点才算成功，如果写入过程中有节点故障，可能导致这个条件一直不能满足，从而一直不能向客户端发送确认结果，针对这种情况，客户端可设置wtimeout选项来指定超时时间，当写入过程持续超过该时间仍未结束，则认为写入失败

         注意事项

         在读取数据的过程中我们需要关注以下两个问题：

2.3.2 readPreference

        readPreference决定使用哪一个节点来满足正在发起的读请求。可选值包括：

        readPreference 场景举例

# 为复制集节点添加标签
conf = rs.conf()
conf.members[1].tags = { purpose: "online"}
conf.members[4].tags = { purpose: "analyse"}
rs.reconfig(conf)

#查询
db.collection.find({}).readPref( "secondary", [ {purpose: "online"} ] )

         readConcern: local 和 available，在复制集中 local 和 available 是没有区别的，两者的区别主要体现在分片集上。

        一个 chunk x 正在从 shard1 向 shard2 迁移；整个迁移过程中 chunk x 中的部分数据会在 shard1 和 shard2 中同时存在，但源分片 shard1仍然是chunk x 的负责方：

        所有对 chunkx的读写操作仍然进入 shard1;config 中记录的信息 chunkx仍然属于 shard1;

        此时如果读 shard2，则会体现出 local 和 available 的区别：

• local:只取到应有由shard2负责的数据(不包括x);
• available:shard2上有什么就读什么(包括x)

        注意事项