MongoDB存储引擎-MMAPv1学习总结

一.读写锁
不支持MVCC
Version < 2.2 : 
只支持进程级锁，一个Mongod实例一个锁。
2.2 ≤ Version < 2.8 : 
支持库级锁，一个db一把锁。
3.0.0 ≤ Version
支持 collection 级别的锁。
内存
内存映射文件
交由操作系统管理，不能
    手动配置管理
无强制内存量要求
缓存索引、热数据等


二.Journal日志
Journal日志，是MongoDB的预写日志WAL(类似Mysql的Redo log)。
journal就是一个预写事务日志，来确保数据的持久性，wiredTiger每隔60秒（默认）或者待写入的数据达到2G时，mongodb将对journal文件提交一个checkpoint（检测点，将内存中的数据变更flush到磁盘中的数据文件中，并做一个标记点，表示此前的数据表示已经持久存储在了数据文件中，此后的数据变更存在于内存和journal日志）。对于write操作，首先被持久写入journal，然后在内存中保存变更数据，条件满足后提交一个新的检测点，即检测点之前的数据只是在journal中持久存储，但并没有在mongodb的数据文件中持久化，延迟持久化可以提升磁盘效率，如果在提交checkpoint之前，mongodb异常退出，此后再次启动可以根据journal日志恢复数据。journal默认使用了snappy压缩，检测点创建后，此前的journal日志即可清除。mongod可以禁用journal，这在一定程度上可以降低它带来的开支；对于单点mongod，关闭journal可能会在异常关闭时丢失checkpoint之间的数据（那些尚未提交到磁盘数据文件的数据）；对于replica set架构，持久性的保证稍高，但仍然不能保证绝对的安全。
因为Journal日志文件是磁盘上连续分配的空间，MongoDB在运行时通过顺序追加的方式记录，通过顺序IO来改善写性能。同时，后台会定时刷写Journal日志文件以将写操作持久化到数据文件。
通过这种两次写的方式，当Mongodb因为一次非正常退出（比如崩溃），重启mongod进程后会根据journal下的文件来恢复数据以达到数据一致，防止数据丢失。同时，一次正常的退出时MongoDB会
刷写并删除journal目录下所有文件。
journal除了故障恢复的作用之外，还可以提高写入的性能，通过批量提交（batch-commit）的方式减少IO次数，一般默认100ms刷新一次到journal，可通过下面参数修改：
storage.journal.commitIntervalMs
值越低，刷新输出频率越高，journal的持久性也就越高(故障意外情况下丢失的数据越少)，但同时意味着更多的磁盘IO。
2.0以上版本默认开启的，可以通过nojournal = true 或--nojournal关闭，但建议开启。
Journal文件是以“j._”开头命名的，且是append only的，如果1个journal文件满了1G大小，mongodb就会新创建一个journal文件来使用，一旦某个journal文件所记载的写操作都被使用过了，
mongodb就会把这个journal文件删除。通常在journal文件所在的文件夹下，只会存在2~3个journal文件，除非你使用mongodb每秒都写入大量的数据。
使用 smallfiles 这个运行时选项可以将journal文件大小减至128M大小。

三.数据文件
每个db有1个.ns（namespace）和若干个数据文件(.n)构成
数据文件随着数据的增多而增多，默认从64M开始，数据文件每新增一次，大小为上一个数据文件的2倍，上限为2GB。这样的设计有利于防止数据量较小的数据库浪费过多的空间，同时又能保证数据量较
大的数据库有相应的空间使用。
MongoDB会使用预分配方式来保证写入性能的稳定（可通过–noprealloc关闭，但不建议）。预分配在后台进行。预分配使得MongoDB始终保持额外的空间和空余的数据文件，从而避免了数据增长过快而
带来的分配磁盘空间引起的阻塞。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15498/viewspace-1992470/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15498/viewspace-1992470/