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崩溃了。那么这段时间内的数据是无法恢复的。