Mongodb 3.2 Manual阅读笔记：CH9 存储

9. 存储

9. 存储

9.1 存储引擎

9.1.1 WiredTiger存储引擎

9.1.1.1 文档级别并发

9.1.1.2 快照和检查点

9.1.1.3 Journaling

9.1.1.4 压缩

9.1.1.5 内存使用

9.1.2 MMAPv1存储引擎

9.1.3 In-Memory存储引擎

9.2 Journaling

9.2.1 Journaling和WiredTiger引擎

9.2.2 journal和MMAPv1引擎

9.2.3 Journal和in-memory存储引擎

9.1 存储引擎

存储引擎是数据库的一个组件用于管理数据存储。Mongodb支持多存储引擎，不同的存储引擎对于指定负荷可能会有更好的性能。

WiredTiger在Mongodb 3.2之后作为默认的存储引擎，能够很好的适应很多负荷。WiredTiger提供文档级别的并发模型，检查点，压缩，和其他特性。

MMAPv1是Mongodb老的存储引擎在mongodb 3.2之前是默认的存储引擎。

In-Memory Storage Engine在Mongodb 企业版可用。和其他存储引擎不同数据是存放在内存减少数据延迟。

9.1.1 WiredTiger存储引擎

从3.0开始已经在64位系统上可用。

在3.2版本中WiredTiger存储引擎为默认存储引擎。如果没有指定--storageEngine或者storage.engine会自动决定存储引擎的使用并且存放在storage.dbPath下。

9.1.1.1 文档级别并发

WiredTiger使用文档级别并发控制写入操作。这样多个客户端可以同时对不同的文档进行修改。对于很多读写操作WiredTiger使用最优的并发控制。WiredTiger在全局，数据库，collection上使用意向锁。当存储引擎发现2个冲突操作，一个操作会出现写入重提，需要显示的重试这个操作。

一些全局操作，通常执行时间短的涉及到多个数据库的，还是会使用全局锁。对于drop collection还是会有数据库x锁。

9.1.1.2 快照和检查点

WiredTiger使用多版本并发控制(MVCC)，在操作之前，WiredTiger提供一个数据快照。快照表示内存数据库的窗口。

当写入磁盘，WiredTiger写入所有的快照中的数据到磁盘。新的固化数据被当做数据文件的checkpoint。

MongoDB在每60秒或者2GB journal数据创建checkpoint。

当在创建新的检查点，老的检查点还是可用。如果MongDB在写入checkpoint的时候发生错误或者中断，MongoDB可以使用最后一次有效的checkpoint。

当WiredTiger元数据表自动更新引用新的检查点，新的检查点变成可用，并且持久。一旦新的checkpoint可用，老的checkpoint就被释放。

如果没有开启journaling，mongodb会从最后一次checkpoint恢复，checkpoint之后的恢复需要用到journaling。

9.1.1.3 Journaling

WiredTiger使用日志先行配合checkpoint来保证数据持久性。WiredTiger journal记录了checkpoint之间的数据修改。如果MongoDB在2次checkpoint之间退出，mongodb会使用journal来重播最后一次checkpoint之后所有的修改。

WiredTiger使用snappy压缩journal。可以指定其他的压缩方法，或者不压缩，可以使用storage.wiredTiger.engineConfig.journalCompressor来设置。

 

Note:WiredTiger最小的日志记录是128 bytes，如果小于128 bytes，那么就不会压缩记录

也可以直接关闭journal减少对journal的维护，storage.journal.enabled=false。如果是单实例，不使用journal就意味着会丢失修改的数据，特别是mongodb在checkpoint之间不可预见的退出。对于复制集，复制进程可以满足持久性要求。

9.1.1.4 压缩

使用WiredTiger，MongoDB支持对所有collection和index 进行压缩。压缩可以减少存储的使用但是会花费一点cpu。

默认，WiredTiger使用块压缩，使用snappy压缩方式压缩所有collection，对所有索引使用前缀压缩。

对于collection，块压缩也可以使用zlib。

设置storage.wiredTiger.collectionConfig. blockCompressor。

对于index，取消前缀压缩，storage.wiredTiger.indexConfig.prefixCompression

压缩设置可以在每个collection或者索引上在创建时设置。对于很多负荷默认压缩设置平衡了存储效率和处理要求。

9.1.1.5 内存使用

使用WiredTiger,MongoDB利用了WiredTiger的cache和文件系统的cache。在3.2之后，WiredTiger cache默认为一下2个大的一个：

1.60%的内存减去1GB

2.1GB

对于大于10GB的内存，新的默认设置会比3.0占用更多内存。对于文件系统缓存，MongoDB自动使用空闲的内存。数据在文件系统cache是被压缩的。

可以通过配置storage.wiredTiger.engineConfig.cacheSizeGB来调整WiredTiger内存大小。

单机修改存储引擎到WiredTiger

考虑：修改存储引擎使用mongodump和mongorestore工具来导入导出数据。保证这些工具已经安装了。另外保证有足够的空间用于导入导出。为了可以使用WiredTiger必须使用3.0以上版本的MongoDB。

过程

1.启动mongod，如果已经启动跳过

2.使用mongodump导出

3.创建一个数据库目录用于新版本的mongodb运行

4.启动带WiredTiger的MongoDB

5.使用mongorestore来恢复数据。

修改复制集到WiredTiger

考虑：对于复制集有成员使用不同的存储引擎。那么你可以以滚动的方式逐个修改到WiredTiger。在全部修改到WiredTiger之前，最好使用混合的存储引擎方式运行一段时间。

过程

1.关闭该secondary成员，db.shutdownServer()

2.准备一个有WiredTiger的MongoDB创建一个数据库目录

3.启动带WiredTiger的MongoDB，因为没有数据，mongod会执行初始化同步，初始化时间取决于数据库的大小和网络连接。

4.重复以上过程，修改所有secondary

修改shard集群的存储引擎到WiredTiger

考虑：这个过程可能会有下线时间，特别是一个或者多个shard是单机的。如果修改shard的host和端口，就必须去修改shard配置。

过程

1.停用均衡器

2.关闭第三个config server保证元数据是只读的。

3.导出第二个config server的数据

4.对于第二个config服务，创建一个新的数据目录，给wiredtiger使用

5.停止第二个config服务

6.启动带wiredtiger的mongodb启动在第二个config服务上。

7.导入之前导出的数据

8.关闭第二个config服务，保证元数据只读

9.启动第三个config server服务，并按3-7步骤执行

10.对于第一个config server，并按3-7步骤执行

11.启动第二个config server

12.启动均衡器

9.1.2 MMAPv1存储引擎

具体看：https://docs.mongodb.org/manual/core/mmapv1/

9.1.3 In-Memory存储引擎

具体看：https://docs.mongodb.org/manual/core/inmemory/

9.2 Journaling

9.2.1 Journaling和WiredTiger引擎

WiredTiger使用checkpoint来提供内存和磁盘上的一致性数据窗口，允许MongoDB从最近的checkpoint恢复。如果mongodb出现异常退出，那么journaling会被用来恢复数据。

journal恢复数据过程：

1.查看数据文件找到最后一次checkpoint标示

2.在journal文件中查找匹配最后一次checkpoint

3.从最后一次checkpoint开始应用journal文件

journal过程

当启动Journal，WiredTiger为每个客户端的写入记录一条日志。内部修改操作也会记录日志。比如update了一个文档可能会导致索引修改，WiredTiger会创建一个日志记录其中包括文档和相关索引的修改。

MongoDB为WiredTiger创建了journal记录的cache。线程协调的分配和复制自己部分的buffer。所有journal记录最多128KB的buffer。

在以下状况下WiredTiger同步journal buffer：

1.每50毫秒

2.MongoDB发生checkpoint，checkpoint每60秒或者journal数据达到2GB。

3.如果写入操作敏感为j:true，WiredTiger强制同步journal文件

4.因为mongodb使用journal文件最多为100MB，当WiredTiger创建新文件时，同步之前文件的缓存。

Journal文件

对于journal文件，MongoDB创建一个子目录journal在dbpath下面。WiredTiger journal文件被命令为WiredTigerLog.<sequence>，<sequence>会用0填充。

每个写入操作有一个记录，每个记录包含唯一的识别符。

MongoDB使用snappy压缩journal数据。

最小的WiredTiger的日志为128字节，如果小于就不再压缩。

WiredTiger的journal文件最大限制为100MB，一旦超过会创建一个新的journal文件。

WiredTiger会自动删除来的journal文件，只维护最近checkpoint以来的journal文件。

WiredTiger会预分配journal文件。

9.2.2 journal和MMAPv1引擎

使用MMAPv1,当写操作发生，MongoDB更新内存窗口。如果启动了journal，MongoDB会先把内存修改记录到journal文件。如果MongoDB在提交数据修改前发生中断或者出现错误，MongoDB可以使用journal文件，维护数据一致性。

journal过程

MongoDB存储引擎层有2个内部数据的窗口，Private view用来写入到，shared view用来写入到数据文件。

1.MongoDB先把修改数据写入到private view

2.MongoDB然后把这些修改写入到journal文件上，大概100毫秒一次。MongoDB以组提交的方式吧这些修改写入到文件。组提交可以最小化性能影响。写入到文件炒作是原子的，保证journal文件的一致性。也可以通过storage.journal.commitIntervalMs来设置。

3.journal提交完之后，MongoDB把修改写入到shared view

4.最后，MongoDB把在shared view上的修改应用到数据文件上。默认应用间隔是60s。操作系统也可以选择比60s频率更高的，特别是可用内存低的情况下。可以通过设置参数来决定刷新频率，storage.syncPeriodSecs。

如果MongoDB crash没有写数据文件，jrounal会以重放这些修改到shared view最后写入到数据文件。

一旦journal操作应用到了shared view并且刷新到了磁盘，MongoDB要求超重系统重新remap到private view，介绍内存使用。

Journal文件

当启动了journal，MongoDB在dbpath下创建一个子目录journal。

Journal文件包含日志先行的，每个journal项描述了data file中的修改。Journal文件是追加日志的。当journal文件有1GB的数据，MongoDB会创建一个新的journal文件。如果使用了storage.smallFiles选项那么每个文件的大小被限制为128MB。

Lsn文件包含最后一次mongodb刷新到数据文件的时间。

一旦mongodb应用了所有某个journal文件到数据文件，那么这个文件就可以被重用。

除非你每秒写入一些字节，journal目录只要2,3个journal文件。

干净关闭删除所有journal目录的文件。Crash的话journal目录就有文件，当下次启动的时候可以自动恢复。

Journal目录

为了保证书序写入的，最好能够把数据文件和journal目录放在不同的文件系统下。

预分配

mongodb可以预分配journal文件，特别是当mongod进程觉得预分配会比创建新的个更高效的时候。

根据文件系统，可以在第一次启动mongod，启用了journal的时候显示的预分配。预分配可能比较花时间。

9.2.3 Journal和in-memory存储引擎

具体看：

https://docs.mongodb.org/manual/core/journaling/#journaling-and-the-in-memory-storage-engine