mongo的碎片整理

由于业务原因，需要将过期数据删除，但有一个问题出现了，频繁删除数据之后，会产生很多磁盘碎片，这些碎片如果没有被重复利用，

进而会影响查询性能（表查询时仍然会扫描这部分删除数据的磁盘空间块），随需要处理。

当从MongoDB中删除文档（Documents）或集合（Collections）后，MongoDB不会将Disk空间释放给OS，MongoDB在数据文件（Data Files）中维护Empty Records的列表。

当重新插入数据后，MongoDB从Empty Records列表中分配存储空间给新的Document，因此，不需要重新开辟空间。为了更新有效的重用Disk空间，必须重新整理数据碎片。

有好几种方法处理：

①使用compact命令

②重建collection

③节点降级，主变成从，从变成主，删数据，再数据同步（数据量非常大的情况下，建议晚上操作同步数据）

 

comoact命令可以压缩单个集合和它的索引。以前压缩数据库的唯一办法就是执行这个数据库的repair

具体用法：
>use testdb
> db.myCollection.runCommand('compact');
> db.runCommand({ compact : 'myCollection' });
压缩比率截图：

压缩比率=348160/1044480*100%=33%

compact优点：
1.compact只压缩需要的Collection，压缩期间产生的临时文件会就相对较少，对磁盘剩余空间需求较小；

2.compact去除Collection所在文件的碎片,其重建索引的cost也变小了，对内存的需求也减少；

compact注意点：
1.compact操作是不会释放磁盘空间的，而是把释放的空间继续给MongoDB使用；
2.compact操作进行时会产生对应的锁，使用mongostat可以查看，所以该操作最好在业务量最少下进行；
3.限制集合{Capped Collection}是不需要compact的

官方解释是：compact命令能够重写和重组集合的data和index

     格式：      

    db.runCommand({ compact: <collection name>,force:<boolen> } )   ---红色部分是可选项

     compact命令之后写你想要整理的collection名字

     force参数用于replica set中primary整理时之用，否则会报错

说明：

          在compact期间会阻塞其他针对此collection的操作，所以最好在业务不繁忙的时候进行compact动作；

          针对compact完成之后，不同引擎会有不同的磁盘影响

     WireTiger引擎：

          在此引擎的数据库下，compact会整理碎片，并且释放未使用的磁盘空间给系统

     MMAPv1引擎：

          在此引擎的数据库下，compact会整理碎片，重建索引，但不会将未使用的空间释放给系统，后续新插入的数据依然可以使用这些空间

     在复制集架构下的一些注意：

          compact命令不会自动复制到secondary节点执行，compact在每个节点成员中都是独立的，在Primary，secondary中执行时都要使用force参数，

          当在secondary的collection上执行compact命令时，此secondary节点会变成RECOVERING状态，且无法提供读操作

     在capped collection中不必使用compact命令，因为它本身就是固定空间