MongoDB 存储引擎：WiredTiger和In-Memory

共计 9548 个字符，预计需要花费 24 分钟才能阅读完成。

存储引擎（Storage Engine）是 MongoDB 的核心组件，负责管理数据如何存储在硬盘（Disk）和内存（Memory）上。从 MongoDB 3.2 版本开始，MongoDB 支持多数据存储引擎（Storage Engine），MongoDB 支持的存储引擎有：WiredTiger，MMAPv1 和 In-Memory。

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

MongoDB 不仅能将数据持久化存储到硬盘文件中，而且还能将数据只保存到内存中；In-Memory 存储引擎用于将数据只存储在内存中，只将少量的元数据和诊断日志（Diagnostic）存储到硬盘文件中，由于不需要 Disk 的 IO 操作，就能获取索取的数据，In-Memory 存储引擎大幅度降低了数据查询的延迟（Latency）。

一，指定 MongoDB 实例的存储引擎

mongod 参数：–storageEngine  wiredTiger | inMemory

指定 Storage Engine 的类型，

• 如果参数值是wiredTiger，MongoDB 使用的存储引擎是 WiredTiger，将数据持久化存储在 Disk Files 中；
• 如果参数值是inMemory，MongoDB 使用的存储引擎是 In-Memory，将数据存储在内存中；
• 从 MongoDB 3.2 版本开始，MongoDB 默认的存储引擎是 WiredTiger；

二，WiredTiger 存储引擎将数据存储到硬盘文件（Disk Files）

WiredTiger 和 MMAPv1 都用于持久化存储数据，相对而言，WiredTiger 比 MMAPv1 更新，功能更强大。

1，文档级别的并发控制（Document-Level Concurrency Control）

MongoDB 在执行写操作时，WiredTiger 在文档级别进行并发控制，就是说，在同一时间，多个写操作能够修改同一个集合中的不同文档；当多个写操作修改同一个文档时，必须以序列化方式执行；这意味着，如果该文档正在被修改，其他写操作必须等待，直到在该文档上的写操作完成之后，其他写操作相互竞争，获胜的写操作在该文档上执行修改操作。

对于大多数读写操作，WiredTiger 使用乐观并发控制（optimistic concurrency control），只在 Global，database 和 Collection 级别上使用意向锁（Intent Lock），如果 WiredTiger 检测到两个操作发生冲突时，导致 MongoDB 将其中一个操作重新执行，这个过程是系统自动完成的。

For most read and write operations, WiredTiger uses optimistic concurrency control. WiredTiger uses only intent locks at the global, database and collection levels. When the storage engine detects conflicts between two operations, one will incur a write conflict causing MongoDB to transparently retry that operation.

2，检查点（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 开始还原数据。

当 MongoDB 以原子方式更新 WiredTiger 的元数据表，使其引用新的 Checkpoint 时，表明新的 Checkpoint 创建成功，MongoDB 将老的 Checkpoint 占用的 Disk 空间释放。使用 WiredTiger 存储引擎，如果没有记录数据更新的日志，MongoDB 只能还原到上一个 Checkpoint；如果要还原在上一个 Checkpoint 之后执行的修改操作，必须使用 Jounal 日志文件。

3，预先记录日志（Write-ahead Transaction Log）

WiredTiger 使用预写日志的机制，在数据更新时，先将数据更新写入到日志文件，然后在创建 Checkpoint 操作开始时，将日志文件中记录的操作，刷新到数据文件，就是说，通过预写日志和 Checkpoint，将数据更新持久化到数据文件中，实现数据的一致性。WiredTiger 日志文件会持久化记录从上一次 Checkpoint 操作之后发生的所有数据更新，在 MongoDB 系统崩溃时，通过日志文件能够还原从上次 Checkpoint 操作之后发生的数据更新。

The WiredTiger journal persists all data modifications between checkpoints. If MongoDB exits between checkpoints, it uses the journal to replay all data modified since the last checkpoint.

3，内存使用

3.1 WiredTiger 利用系统内存资源缓存两部分数据：

• 内部缓存（Internal Cache）
• 文件系统缓存（Filesystem Cache）

从 MongoDB 3.2 版本开始，WiredTiger 内部缓存的使用量，默认值是：1GB 或 60% of RAM – 1GB，取两值中的较大值；文件系统缓存的使用量不固定，MongoDB 自动使用系统空闲的内存，这些内存不被 WiredTiger 缓存和其他进程使用，数据在文件系统缓存中是压缩存储的。

• Starting in MongoDB 3.2, the WiredTiger internal cache, by default, will use the larger of either: 60% of RAM minus 1 GB, or 1 GB.
• For systems with up to 10 GB of RAM, the new default setting is less than or equal to the 3.0 default setting 
• For systems with more than 10 GB of RAM, the new default setting is greater than the 3.0 setting.

4，数据压缩（Data Compression）

WiredTiger 压缩存储集合（Collection）和索引（Index），压缩减少 Disk 空间消耗，但是消耗额外的 CPU 执行数据压缩和解压缩的操作。

默认情况下，WiredTiger 使用块压缩（Block Compression）算法来压缩 Collections，使用前缀压缩（Prefix Compression）算法来压缩 Indexes，Journal 日志文件也是压缩存储的。对于大多数工作负载（Workload），默认的压缩设置能够均衡（Balance）数据存储的效率和处理数据的需求，即压缩和解压的处理速度是非常高的。

5，Disk 空间回收

当从 MongoDB 中删除文档（Documents）或集合（Collections）后，MongoDB 不会将 Disk 空间释放给 OS，MongoDB 在数据文件（Data Files）中维护 Empty Records 的列表。当重新插入数据后，MongoDB 从 Empty Records 列表中分配存储空间给新的 Document，因此，不需要重新开辟空间。为了更新有效的重用 Disk 空间，必须重新整理数据碎片。

WiredTiger 使用 compact 命令，移除集合（Collection）中数据和索引的碎片，并将 unused 的空间释放，调用语法：

db.runCommand ({ compact: '<collection>'} )

在执行 compact 命令时，MongoDB 会对当前的 database 加锁，阻塞其他操作。在 compact 命令执行完成之后，mongod 会重建集合的所有索引。

On WiredTiger, compact will rewrite the collection and indexes to minimize disk space by releasing unused disk space to the operating system. This is useful if you have removed a large amount of data from the collection, and do not plan to replace it.

二，In-Memory 存储引擎将数据存储到内存（Memory）

In-Memory 存储引擎将数据存储在内存中，除了少量的元数据和诊断（Diagnostic）日志，In-Memory 存储引擎不会维护任何存储在硬盘上的数据（On-Disk Data），避免 Disk 的 IO 操作，减少数据查询的延迟。

1，指定 In-Memory 存储引擎

mongod --storageEngine inMemory --dbpath <path>

在选择 In-Memory 存储引擎时，需要指定两个参数：

• 设置 mongod 参数：–storageEngine ，设置参数的值是 inMemory；
• 设置 mongod 参数：–dbpath，设置参数的值是数据存储的目录；
• 使用 Disk 存储元数据，诊断数据和临时数据：虽然 In-Memory 存储引擎不会向文件系统写入数据，但是它需要使用 –dbpath 维护少量的元数据和诊断（Diagnostic）日志，在创建 Large Index 时，使用 Disk 存储临时数据；Although the in-memory storage engine does not write data to the filesystem, it maintains in the –dbpath small metadata files and diagnostic data as well temporary files for building large indexes.

2，文档级别的并发（document-level concurrency）

In-Memory 存储引擎在执行写操作时，使用文件级别的并发控制，就是说，在同一时间，多个写操作能够同时修改同一个集合中的不同文档；当多个写操作修改同一个文档时，必须以序列化方式执行；这意味着，如果该文档正在被修改，其他写操作必须等待。

3，内存使用

In-Mmeory 存储引擎需要将 Data，Index，Oplog 等存储到内存中，通过 mongod 参数：–inMemorySizeGB 设置占用的内存数量，默认值是：50% of RAM-1GB。指定 In-Memory 存储引擎使用的内存数据量，单位是 GB：

mongod --storageEngine inMemory --dbpath <path> --inMemorySizeGB <newSize>

4，持久化（Durable）

由于 In-Memory 存储引擎不会持久化存储数据，只将数据存储在内存中，读写操作直接在内存中完成，不会将数据写入到 Disk 文件中，因此，不需要单独的日志文件，不存在记录日志和等待数据持久化的问题，当 MongoDB 实例关机或系统异常终止时，所有存储在内存中的数据都将会丢失。

5，记录 oplog

In-Memory 存储引擎不会将数据更新写入到 Disk，但是会记录 oplog，该 oplog 是存储在内存中的集合，MongoDB 通过 Replication 将 Primary 成员的 oplog 推送给同一副本集的其他成员。如果一个 MongoDB 实例是 Replica Set 的 Primary 成员，该实例使用 In-Memory 存储引擎，通过 Replication 将 oplog 推送到其他成员，在其他成员中重做 oplog 中记录的操作，这样，就能将在 Primary 成员中执行的数据修改持久化存储。

You can deploy mongod instances that use in-memory storage engine as part of a replica set. For example, as part of a three-member replica set, you could have:

• two mongod instances run with in-memory storage engine.
• one mongod instance run with WiredTiger storage engine. Configure the WiredTiger member as a hidden member (i.e. hidden: true and priority: 0).

With this deployment model, only the mongod instances running with the in-memory storange engine can become the primary. Clients connect only to the in-memory storage engine mongod instances. Even if both mongod instances running in-memory storage engine crash and restart, they can sync from the member running WiredTiger. The hidden mongod instance running with WiredTiger persists the data to disk, including the user data, indexes, and replication configuration information.

三，记录日志

数据是 MongoDB 的核心，MongoDB 必须保证数据的安全，不能丢失，Journal 是顺序写入的日志文件，用于记录上一个 Checkpoint 之后发生的数据更新，能够将数据库从系统异常终止事件中还原到一个有效的状态。MongoDB 使用预写日志机制实现数据的持久化：WiredTiger 存储引擎在执行写操作时，先将数据更新写入到 Journal 文件。Journal Files 是存储在硬盘的日志文件，每个 Journal File 大约是 100MB，存储在 –dbpath 下的 Journal 子目录中，在执行 Checkpoint 操作，将数据的更新同步到数据文件。

每隔一定的时间间隔，WiredTiger 存储引擎都会执行 Checkpoint 操作，将缓存的数据更新日志同步到硬盘上的数据文件中（On-Disk Files），在默认情况下，MongoDB 启用日志记录，也可以显式启用，只需要在启动 mongod 时使用 –journal 参数：

mongod --journal

1，使用 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 中的所有日志记录；

2，缓存日志

MongoDB 配置 WiredTiger 使用内存缓冲区来存储 Journal Records，所有没有达到 128KB 的 Journal Records 都会被缓存在缓冲区中，直到大小超过 128KB。在执行写操作时，WiredTiger 将 Journal Records 存储在缓冲区中，如果 MongoDB 异常关机，存储在内存中的 Journal Records 将丢失，这意味着，WiredTiger 将丢失最大 128KB 的数据更新。

WiredTiger syncs the buffered journal records to disk according to the following intervals or conditions:

• New in version 3.2: Every 50 milliseconds.
• MongoDB sets checkpoints to occur in WiredTiger on user data at an interval of 60 seconds or when 2 GB of journal data has been written, whichever occurs first.
• If the write operation includes a write concern of j: true, WiredTiger forces a sync of the WiredTiger journal files.
• Because MongoDB uses a journal file size limit of 100 MB, WiredTiger creates a new journal file approximately every 100 MB of data. When WiredTiger creates a new journal file, WiredTiger syncs the previous journal file.

3，日志文件（Journal Files）

mongod 
--storageEngine wiredTiger 
--dbpath <path> 
--journal --wiredTigerCacheSizeGB <value>
--wiredTigerJournalCompressor <compressor>
--wiredTigerCollectionBlockCompressor <compressor>
--wiredTigerIndexPrefixCompression <boolean>

mongod 
--storageEngine inMemory
--dbpath <path> 
--inMemorySizeGB <newSize>
--replSet <setname>
--oplogSize <value> 

更多 MongoDB 相关教程见以下内容：

CentOS 编译安装 MongoDB 与 mongoDB 的 php 扩展 http://www.linuxidc.com/Linux/2012-02/53833.htm

CentOS 6 使用 yum 安装 MongoDB 及服务器端配置 http://www.linuxidc.com/Linux/2012-08/68196.htm

Ubuntu 13.04 下安装 MongoDB2.4.3 http://www.linuxidc.com/Linux/2013-05/84227.htm

MongoDB 入门必读(概念与实战并重) http://www.linuxidc.com/Linux/2013-07/87105.htm

Ubunu 14.04 下 MongoDB 的安装指南 http://www.linuxidc.com/Linux/2014-08/105364.htm

《MongoDB 权威指南》(MongoDB: The Definitive Guide)英文文字版[PDF] http://www.linuxidc.com/Linux/2012-07/66735.htm

Nagios 监控 MongoDB 分片集群服务实战 http://www.linuxidc.com/Linux/2014-10/107826.htm

基于 CentOS 6.5 操作系统搭建 MongoDB 服务 http://www.linuxidc.com/Linux/2014-11/108900.htm

MongoDB 的详细介绍：请点这里
MongoDB 的下载地址：请点这里

参考 doc：

Storage Engines 

WiredTiger Storage Engine

Journaling

In-Memory Storage Engine

compact

本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-10/136551.htm