MongoDB的MMAPv1存储引擎
在MongoDB 3.0之前，默认存储引擎为MMAPv1。从MongoDB 4.0开始，MMAPv1存储引擎开始被遗弃。MMAPv1是基于内存映射文件的原始存储引擎。
一、journal
1、将数据写入journal file可以保证MongoDB数据的持久化，数据写journal file要比写data file频繁。
2、在MMAPv1存储引擎下，MongoDB每100ms写一次journal file，可通过参数storage.journal.commitIntervalMs进行修改；每60s写一次data file，可通过参数storage.syncPeriodSecs进行修改。
3、journaling process
1）在开启journal的情况下，MongoDB存储层会有两个视图：private view、share view
MongoDB首先将写操作应用到private view；
MongoDB应用private view上所有的数据变更到journal file；
该操作的时间间隔大概为100ms，可以通过参数storage.journal.commitIntervalMs进行调整修改。
该过程也成为group commit，group commit可以最小化journal对性能上的影响，因为group commit保证在提交时阻塞其他写操作。
写入日志是原子性的，确保磁盘上日志文件的一致性。
MongoDB应用journal file中记录的变更到share view;
MongoDB应用所有share view中的变更到data file，该操作默认60s一次，可以通参数storage.syncPeriodSecs进行控制
在内存较低的操作系统上该操作会更加频繁
MongoDB将share view重新映射到private view中，以保存物理内存。
2）如果MongoDB意外宕机，期间部分写操作没有从share view应用到data file，MongoDB会将journal file中的变更重新应用到share view，然后重新写入到data file。
3）当数据写入到data file中后，会在journal file中标记该记录已经被flushed，当journal file文件中全部记录被flushed后，会创建一个新的journal file覆盖掉原来旧的。
4）将share view刷入到data file中的过程就相当于不开启journal的流程。
4、journal file
1）当开启journal的情况下，MongoDB会在dbpath目录下创建一个journal的子目录用来存储journal file。
2）journal file实现WAL。当journal file达到1G时，MongoDB会创建一个新的journal file。
3）当MongoDB将journal file中所有记录应用到data file,MongoDB可以将该journal file回收利用为新的journal file。
4）一般情况下，journal目录下会有2-3个journal file。
5）一个比较安全的数据库关闭，MongoDB会移除所有journal目录下的文件。意外宕机的情况下，MongoDB重新启动时，可以利用journal file将数据库恢复到一个一致性状态。
5、建议尽量将journal目录与数据目录放在不同的文件系统下，可以加快对journal file的顺序写。
6、MongoDB会预先分配日志文件
二、记录存储特征
1、所有的记录都是顺序存储在磁盘，当某一个文档的大小超过当前说分配的空间上时，MongoDB需要为该文档的数据以及索引重新分配一个空间，这个操作非常耗时，且容易造成空间碎片化
2、MongoDB默认使用 Power of 2 Sized Allocations，所以每个document对应的record将有实际数据和一些padding组成，这padding可以允许document的尺寸在update时适度的增长，以最小化重新分配record的可能性。此外重新分配空间，也会导致磁盘碎片（旧的record空间）。
三、记录分配策略
1、MongoDB支持多记录分配策略，每个document对应的record将有实际数据和一些padding组成，这padding可以允许document的尺寸在update时适度的增长，以最小化重新分配record的可能性。此外重新分配空间，也会导致磁盘碎片（旧的record空间）。
2、Power of 2 Sized Allocations：
默认情况下，MMAPv1中空间分配使用此策略，每个document的size是2的次幂，比如32、64、128、256...2MB，如果文档尺寸大于2MB，则空间为2MB的倍数（2M,4M,6M等）。
这种策略有2种优势：
1.可以有效的重用空间，减少碎片化。
2.padding可以减少文档重新分配空间
3、No padding Allocation
即按照实际数据尺寸分配空间，如果你确信数据绝大多数情况下都是insert、in-place update，极少的delete，此策略将可以有效的节约磁盘空间，看起来数据更加紧凑，磁盘利用率也更高。
四、内存使用
MongoDB会尽可能使用所有内存作为缓存，但是MongoDB使用内存是动态的，如果其他进程需要使用内存，MongoDB可以为该线程提供缓存内存。
