mongodb官网文档阅读笔记：与写性能相关的几个因素

Indexes

和所有db一样，索引肯定都会引起写性能的下降，mongodb也没啥特别的，相对索引对读性能的提示，这些消耗一般是可以接受的，所以该添加的索引还是要添加，当然需要谨慎一些。扯点远的，曾经我碰到过一个case，因为一个表的索引数量太多，导致后续磁盘的util越来越高，达到70%，而刚添加的副本集成员磁盘uitl才20%不到。后来发现是因为索引太多，越到后面造成的索引碎片也就越来越多，后来的处理方法是定期都挨个重做副本集的成员。

Document Growth and the MMAPv1 Storage Engine

一些更新操作会增加一个文档的大小，比如给一个文档再添加一列。对于MMAPv1的存储引擎，如果一个更新操作引起这个文档大小超过了之前申请的record size，mongodb将会在硬盘上重新迁移使得保证有足够的空间存储这整个文档(这点类似于oracle的行迁移)，这个迁移操作将比不迁移的情况消耗更长的时间和代价，尤其是这个文档上有索引的话，因为如果这个文档有索引的话，mongodb必须更新它的所有的索引，因此如果一个文档有很多索引的话，这个迁移将会影响到写入的吞吐量。

在mongodb3.0中，默认的情况下mongodb用2的指数形式来自动增加文档空间，2的指数大小能保证mongodb高效地重复利用剩下空间，同时也能在很多情况下减少迁移的次数。当然这种2的指数形式虽然能减少重新申请空间的次数，但却还是无法完全根除该操作。

Journaling

mongodb使用预先写journal log到磁盘的方式保证写操作的持久性，从而能够中崩溃中恢复(类似于关系数据库的redo log)。在将数据写到数据页之前，它会先将其写入到journal log。
尽管journal log提供的持久性特性通常比它所需要的写性能消耗更重要，我们还是需要在持久化和写性能之间做一个权衡。
1 如果journal log和数据文件在同一块磁盘，数据页和journal将不可避免地存在写竞争，建议将journal log移到另外一块单独的磁盘或许可以提升写性能
2 如果上文提到的write concern设置了journal级别，mongod一般来说都会降低两次journal log之间的提交间隔（因为提交间隔太长，write concern设置后一次写操作将会花很长时间），这样就会增加写负载。关于write concern，请参考我的另外一篇blog，http://blog.csdn.net/cug_jiang126com/article/details/47399133
3 可通过调整commitIntervalMs 参数动态修改journal
log的提交间隔，减少该值会增加写操作的次数，增加该值可减少写操作的次数，但是会增加数据丢失的风险，因为在这个提交间隔内，如果db崩溃了，那么这段时间内的数据是无法恢复的。