MongoDB空间分配
Mongodb占据的磁盘空间比MySQL大得多，可以理解文档数据如Json这种格式，存在许多冗余数据，但空间占用大得不正常，甚至是传统数据库的三四倍，不太契合工程实践，应该有改善的余地。 查阅了一些资料，具体理下Mongodb的空间分配。
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存储的数据是不安全的，也许哪天就起不来了。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
