写篇文章时，2.8版本还没有出。

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

1. MongoDB每个库逻辑上包含许多集合（collection）,物理上存储为多个数据文件，数据文件的分配是预先分配的，预分配的方式可以减少碎片，程序申请磁盘空间的时候更高效，但MongoDB预分配的策略可能导致空间的浪费。默认的分配空间的策略是：随着数据库数据的增加，MongoDB会不断分配更多的数据文件。每个新数据文件的大小都是上一个已分配文件的两倍( 64M, 128M, 256M, 512M, 1G, 2G, 2G, 2G )，直到预分配文件大小的上限2G。虽然2G的阀值可以调整，但一般运维等时候往往也不会去调整，就这点来说，可能导致空间的浪费。

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

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

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

在MongoDB 2.6中，默认的空间分配策略将是powerOf2Sizes，这个选项从MongoDB 2.2开始就已经提供了。该设置会将MongoDB分配的空间大小向上取整为2的幂（比如，2、4、6、8、16、32、64等等）。该设置会降低需要移动文档的几率，并使空间可以更高效地重用，结果是更少的空间过度分配和更可预测的性能。用户仍然可以使用精确匹配的分配策略，如果文档大小不增加，该策略更节省空间。”

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

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

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