mongodb版本为3.4
mongodb存储引起的一些概述
存储引擎是MongoDB的核心组件，负责管理数据如何存储在硬盘和内存上。从MongoDB 3.2 版本开始，MongoDB 支持多数据存储引擎，MongoDB支持的存储引擎有：WiredTiger，MMAPv1和In-Memory。
从mongodb3.2开始默认的存储引擎是WiredTiger，3.3版本之前的默认存储引擎是MMAPv1，mongodb4.x版本不再支持MMAPv1存储引擎。
MongoDB不仅能将数据持久化存储到硬盘文件中，而且还能将数据只保存到内存中；In-Memory存储引擎用于将数据只存储在内存中，只将少量的元数据和诊断日志（Diagnostic）存储到硬盘文件中，由于不需要Disk的IO操作，就能获取索取的数据，In-Memory存储引擎大幅度降低了数据查询的延迟（Latency）
WiredTiger存储引擎
从mongodb3.2开始mongodb默认支持WiredTiger存储引擎，对于3.2之前的版本可以使用参数指定存储引擎。
storage:
engine: wiredTiger
wireTiger:
[存储引擎的参数设置]
WiredTiger是各种操作应用的理想选择，因此是MongoDB的默认存储引擎。它应该是所有新应用程序的起点，除了您需要内存或加密存储引擎的特定功能的情况。
WiredTiger存储引擎的主要优势：
最大化可用缓存： WiredTiger最大限度地利用可用内存作为缓存来减少I / O瓶颈。使用了两个缓存：WiredTiger缓存和文件系统缓存。WiredTiger缓存存储未压缩的数据并提供类似内存的性能。操作系统的文件系统缓存存储压缩数据。当在WiredTiger缓存中找不到数据时，WiredTiger将在文件系统缓存中查找数据。
在移动到WiredTiger缓存之前，在文件系统缓存中找到的数据首先经过解压缩过程。
WiredTiger缓存在保存尽可能多的工作集时表现最佳。但是，为需要它的其他进程（如操作系统，包括文件系统缓存）保留内存也很重要。这也包括MongoDB本身，整体上消耗的内存比WiredTiger主动使用的内存多。
MongoDB默认为WiredTiger缓存大小约为RAM的60％。离开文件系统缓存的最小量是可用内存的20％。任何较低的操作系统都可能受限于资源。
高吞吐量： WiredTiger使用“写入时复制” - 当文档更新时，WiredTiger将制作文档的新副本并确定最新版本以返回给读者。此方法允许多个客户端同时修改集合中的不同文档，从而实现更高的并发性和吞吐量。当应用程序使用具有多个内核的主机（越多越好）并且多个线程正在写入不同的文档时，实现最佳写入性能。
减少存储空间并改善磁盘IOP： WiredTiger使用压缩算法来减少磁盘上存储的数据量。不仅存储减少了，而且随着从磁盘读取或写入更少的位，IOP性能也会提高。某些类型的文件比其他文件压缩得更好。文本文件是高度可压缩的，而二进制数据可能不是可压缩的，因为它可能已经被编码和压缩。使用压缩时，WiredTiger会产生额外的CPU周期，但用户可以配置压缩方案以优化CPU开销与压缩比。Snappy是默认的压缩引擎，在高压缩率和低CPU开销之间提供了良好的平衡。Zlib将实现更高的压缩比，但会产生额外的CPU周期。
压缩（索引和journals日志）：索引可以在内存和磁盘上压缩。WiredTiger利用前缀压缩来压缩索引，节省RAM使用以及释放存储IOP。默认情况下，使用Snappy压缩压缩journals日志。
多核可扩展性：随着CPU制造商缩小到更小的平版印刷，功耗变得越来越成问题，处理器趋势已转向多核架构，以维持摩尔定律的节奏。WiredTiger在设计时考虑了现代的多核架构，并提供跨多核系统的可扩展性。危险指针，无锁算法和快速锁存等编程技术可最大限度地减少线程之间的争用。线程可以执行操作而不会相互阻塞 - 从而减少线程争用，更好的并发性和更高的吞吐量。
WiredTiger允许用户为其读取指定隔离级别。读取操作可以返回大部分副本集已接受或提交到磁盘的数据视图。这样可以保证应用程序只读取在发生故障时仍然存在的数据，并且在将新的副本集成员提升为主要成员时不会回滚。
【以上关于wiredTiger存储引擎的介绍来自官方文档的一片博客：存储引擎】
文档级并发
WiredTiger使用文档级并发控制进行写操作。因此，多个客户端可以同时修改集合的不同文档。
对于大多数读写操作，WiredTiger使用乐观并发控制。WiredTiger仅在全局，数据库和集合级别使用意图锁。当存储引擎检测到两个操作之间的冲突时，会发生写入冲突，导致MongoDB透明地重试该操作。
一些全局操作（通常是涉及多个数据库的短期操作）仍然需要全局“实例范围”锁定。其他一些操作（例如删除集合）仍需要独占数据库锁。
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日志文件。
journal日志
WiredTiger使用预写日志的机制，在数据更新时，先将数据更新写入到日志文件，然后在创建Checkpoint操作开始时，将日志文件中记录的操作，刷新到数据文件，就是说，通过预写日志和Checkpoint，将数据更新持久化到数据文件中，实现数据的一致性。WiredTiger 日志文件会持久化记录从上一次Checkpoint操作之后发生的所有数据更新，在MongoDB系统崩溃时，通过日志文件能够还原从上次Checkpoint操作之后发生的数据更新。
压缩
使用WiredTiger，MongoDB支持对所有集合和索引进行压缩。压缩可以以额外的CPU为代价最大限度地减少磁盘的使用。
默认情况下WiredTiger存储引擎使用snappy方式压缩所有集合，前缀压缩方式压缩索引。
对于集合的压缩还可以使用zlib方式压缩。
storage:
joural:
enabled: true #启用journal日志，false为关闭
engine: wiredTiger #指定存储引擎
wiredTiger:
cacheSizeGB: 8 #来指定mongodb使用内存的多少-8G
engineConfig: #存储引擎的配置
journalCompressor: snappy #指定journal日志的压缩方式
indexConfig: #索引配置
prefixCompression: true #前缀压缩开启
collectionConfig:
blockCompressor: snappy #指定集合的压缩方式
内存使用
在上面提到过：【最大化可用缓存： WiredTiger最大限度地利用可用内存作为缓存来减少I / O瓶颈。使用了两个缓存：WiredTiger缓存和文件系统缓存。WiredTiger缓存存储未压缩的数据并提供类似内存的性能。操作系统的文件系统缓存存储压缩数据。当在WiredTiger缓存中找不到数据时，WiredTiger将在文件系统缓存中查找数据。】
mongodb从3.4版本开始默认使用内存为下面两个中的最大一个：
- 50% of (RAM - 1 GB)
- 256MB
默认情况下，WiredTiger对所有集合使用Snappy块压缩，对所有索引使用前缀压缩。压缩默认值可在全局级别配置，也可以在集合和索引创建时单独指定压缩级别。
wiredTiger内部缓存中的数据与磁盘格式使用不同的表示形式：
【官方文档总结--站位】
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会重建集合的所有索引
把已经含有数据的mongdb的存储引擎更改为WiredTiger
当前mongdb实例存储引擎为mmapv1，如下：
mmapv1的配置#数据大小如下
> show dbs;
admin 0.078GB
local 0.078GB
mydb 0.453GB
开始更改mongdb实例的存储引擎：
1.备份原来的数据库文件：
[root@test2 data]# mkdir db_back #创建备份目录
[root@test2 bin]# ./mongodump -o /data/db_back/ #备份数据
2018-11-09T17:46:54.684+0800 writing admin.system.indexes to
2018-11-09T17:46:54.685+0800 done dumping admin.system.indexes (2 documents)
2018-11-09T17:46:54.685+0800 writing admin.system.version to
2018-11-09T17:46:54.686+0800 done dumping admin.system.version (1 document)
2018-11-09T17:46:54.686+0800 writing mydb.test to
2018-11-09T17:46:57.676+0800 [###############.........] mydb.test 636416/999999 (63.6%)
2018-11-09T17:46:58.632+0800 [########################] mydb.test 999999/999999 (100.0%)
2018-11-09T17:46:58.632+0800 done dumping mydb.test (999999 documents)
[root@test2 bin]#
2.停止mongodb实例
kill `netstat -lntp |grep mongod | awk '{print $NF}' | cut -d "/" -f1`
3.修改配置文件
storage:
engine: wiredTiger
wiredTiger:
engineConfig:
cacheSizeGB: 4
journalCompressor: none
collectionConfig:
blockCompressor: none
indexConfig
prefixCompression: false
4：把现在dbpath中的数据，改名备份起来！
[root@test2 data]# mv db db_mmapv1
[root@test2 data]# mkdir db #然后再重新创建一个db目录
5：启动mongodb实例
[root@test2 bin]# ./mongod -f ../conf/mongod.conf
about to fork child process, waiting until server is ready for connections.
forked process: 14436
child process started successfully, parent exiting
[root@test2 bin]#
6：导入之前导出的数据
[root@test2 bin]# ./mongorestore --dir=/data/db_back/ #导入数据
2018-11-09T17:59:10.586+0800 preparing collections to restore from
2018-11-09T17:59:10.599+0800 reading metadata for mydb.test from /data/db_back/mydb/test.metadata.json
2018-11-09T17:59:10.646+0800 restoring mydb.test from /data/db_back/mydb/test.bson
2018-11-09T17:59:13.546+0800 [########................] mydb.test 20.1MB/54.4MB (37.0%)
2018-11-09T17:59:16.546+0800 [##################......] mydb.test 42.7MB/54.4MB (78.5%)
2018-11-09T17:59:18.354+0800 [########################] mydb.test 54.4MB/54.4MB (100.0%)
2018-11-09T17:59:18.354+0800 no indexes to restore
2018-11-09T17:59:18.354+0800 finished restoring mydb.test (999999 documents)
2018-11-09T17:59:18.354+0800 done
[root@test2 bin]# ./mongo #查看数据
MongoDB shell version v3.4.2
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.2
Server has startup warnings:
2018-11-09T17:57:26.586+0800 I STORAGE [initandlisten]
2018-11-09T17:57:26.586+0800 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2018-11-09T17:57:26.586+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2018-11-09T17:57:26.688+0800 I CONTROL [initandlisten]
2018-11-09T17:57:26.688+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2018-11-09T17:57:26.688+0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2018-11-09T17:57:26.688+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2018-11-09T17:57:26.688+0800 I CONTROL [initandlisten]
> show dbs
admin 0.000GB
local 0.000GB
mydb 0.077GB #数据占有空间明显变小了
比较两个存储引擎，数据目录文件的不同
[root@test2 db]# pwd
/data/db
[root@test2 db]# ls #当前正在使用的wiredTiger存储引擎
collection-0-1470999101568290858.wt diagnostic.data index-4-1470999101568290858.wt _mdb_catalog.wt storage.bson WiredTiger.lock
collection-2-1470999101568290858.wt index-1-1470999101568290858.wt index-6-1470999101568290858.wt mongod.lock WiredTiger WiredTiger.turtle
collection-5-1470999101568290858.wt index-3-1470999101568290858.wt journal sizeStorer.wt WiredTigerLAS.wt WiredTiger.wt
[root@test2 db]# ls ../db_mmapv1/ #之前备份的mmapv1存储引擎的目录
admin.0 admin.ns diagnostic.data journal local.0 local.ns mongod.lock mydb.0 mydb.1 mydb.2 mydb.ns storage.bson _tmp
[root@test2 db]#