MongoDB空间分配

Mongodb占据的磁盘空间比MySQL大得多，能够理解文档数据如Json这种格式，存在许多冗余数据，但空间占用大得不正常，甚至是传统数据库的三四倍，不太契合工程实践，应该有改善的余地。 查阅了一些资料，具体理下Mongodb的空间分配。

  

      1. MongoDB每一个库逻辑上包含许多集合（collection）,物理上存储为多个数据文件，数据文件的分配是预先分配的，预分配的方式能够减小碎片，程序申请磁盘空间的时候更高效，但MongoDB预分配的策略可能致使空间的浪费。默认的分配空间的策略是：随着数据库数据的增长，MongoDB会不断分配更多的数据文件。每一个新数据文件的大小都是上一个已分配文件的两倍( 64M, 128M, 256M, 512M, 1G, 2G, 2G, 2G )，直到预分配文件大小的上限2G。虽然2G的阀值能够调整，但通常运维等时候每每也不会去调整，就这点来讲，可能致使空间的浪费。（能够这样理解，本来一个collection大小为2M，增长了一个100K的数据后，如今该collection大小变为2M*2=4M,这种分配策略会浪费内存，但会避免产生碎片）

 

对于磁盘的空间的分配效率，我报以怀疑的态度，若是自己有IO瓶颈，预分配一个2G的文件，将可能致使服务出现严重性能问题。预分配文件，能够减小碎片，提升程序申请空间的效率，但有无必要一次分配初始化一个巨大的文件，这点值得商榷。 虽然预分配的机制，文档记载是能够关闭的，但通常使用NOSQL产品都是会使用默认配置，也建议使用默认的配置，因默认配置每每经历了长久的考验，没有那么多bug。

 

 

2. MongoDB的文档在数据文件中是连续存储的，这点不一样于一些关系数据库的作法（它们会把长记录拆分为两部分，溢出的那部分单独存放在另外一处），若是没有预留足够的空间，那么更新可能致使原有空间放不下新的文档。当更新迫使引擎在BSON存储中移动文档时，存储碎片能够致使意外的延迟。对此MongoDB官方的解释是以下，

“若是有足够的空间，在MongoDB中更新文档时，数据会在原地更新。若是更新后的文档大小大于已经分配的空间，那么文档会在一个新位置被重写。MongoDB最终会重用原来的空间，但这可能须要时间，并且空间可能会过分分配。

在MongoDB 2.6中，默认的空间分配策略将是powerOf2Sizes，这个选项从MongoDB 2.2开始就已经提供了。该设置会将MongoDB分配的空间大小向上取整为2的幂（好比，二、四、六、八、1六、3二、64等等）。该设置会下降须要移动文档的概率，并使空间能够更高效地重用，结果是更少的空间过分分配和更可预测的性能。用户仍然可使用精确匹配的分配策略，若是文档大小不增长，该策略更节省空间。”

显然，这种策略又将致使空间的浪费，特别是对于导入只读类型的数据。

3. MongoDB不支持数据文件的压缩，也不能回收空间。它所使用的碎片整理的策略，多是在一个新的地方重写，而不是对旧的碎片进行整理、合并。

4. 不校验数据页。页面校验对于数据库是很是重要的，有助于识别存储设备异常。就这点，MongoDB存储的数据是不安全的，也许哪天就起不来了。