多年运维Mongodb，以下经验，非常认可，分享给大家。
1.mongodb 表名和字段名统一用小写字母
mongodb 是默认区分大小写的，为了避免以前在 mysql 下遇到的大小写敏感导致程序访问频频出错，
建立规范，mongodb 的表名和字段名都用小写字母命名。
2.尽可能的缩短字段名的长度
mongodb 的 schema free 导致了每笔数据都要存储它的 key 以及属性，这导致了这些数据的大量冗余。
开发人员也许考虑到，从易读性出发设计的 key 名，基本都是按照字面意思去设计的，这导致 key 很长，对应的数据存储占用了很大的空间。
所以，在你的程序里维护一套字典即可，尽可能降低 key 的长度。
譬如：
static final String CONTENT = "content";
static final String CONTENT_TYPE = "ctype";
static final String CONTENT_LENGTH = "clen";
这个很重要,如果你单表有1000W条记录，如果字段名称，减少几个字母，你想想可以节约多少空间，查询速度提高多少。
3.记住，mongodb 的查询每次只能用到一个索引
对于较复杂的表结构，可能会导致你频频使用联合索引。
但记住：
1）mongodb 单表最大索引数为 64 。
2）索引越多，插入或修改记录就会导致 mongodb 越慢。写锁会阻塞读请求，写得越慢，阻塞读请求越多、阻塞时间越长。
所以，索引越加越多的时候，你可能需要审视一下表结构设计的合理性。
这个很容易理解，索引是在这个表里，内存保留的另外一份数据，当索引多的时候，插入数据需要生成多份，所以就慢了。
4.客户端连接数大小的设置
mongodb-java-driver 的连接池，目前从观察到的情况是应用一开启便根据 connectionsPerHost 变量的设置，建立全部连接，然后提供给程序使用，并且一旦其中某个连接到数据库的访问失败，则会清空整个连接池到这台数据库的连接，并重新建立连接。
而 mongodb 对中断连接的垃圾清理工作则是懒惰的被动清理方式，如果驱动程序端配置的连接数过大，一旦发生重连，则会导致 mongo 服务器端堆积大量的垃圾连接以及对应数据，导致主机资源耗尽。
建议： mongodb 驱动的连接池大小的设置一般应该控制 100 左右。
（ 参考阅读：PHP-FPM模式下可怕的 MongoDB-PHP-Driver 连接池无节制连接问题）
5.实例分离
mongodb 对数据库的访问全部加锁。
如是查询请求则设置共享锁。
数据修改请求则设置全局排他锁，且是实例级别的排他锁。
写锁会阻塞读请求，如果长时间持有写锁，会阻塞整个实例的读请求。
建议：
1）不同应用不应该共用同一个实例，防止互相阻塞！
2）如服务器资源不足，共用同一个实例，要保证读写特性相同，如都是读多写少，防止一台写多应用阻塞读请求。
（评语：旧版本的MongoDB （pre 2.0）拥有一个全局的写入锁，这个问题在2.0版本中的得到了显著的改善，并且在当前2.2版本中得到了进一步的加强。MongoDB 2.2使用数据库级别的锁在这个问题上迈进了一大步。所以用 MongoDB 2.2的人可以忽略此条目。）
如果有条件，这个很重要，一个应用如果表设计的特别糟糕，会影响整个实例的效率，这个不只是2.2版本，最新的mongodb3.4也一样。
6.需要重点关注的 mongodb 性能指标
关注主要性能指标：
1）Faults：显示 mongodb 每秒页面故障的数量，这个是 mongodb 映射到虚拟地址空间，而不是物理内存。这个值如果飙高的话，可能意味着机器没有足够的内存来存储数据和索引。
2）Flushes：每秒做了多少次 fsync，显示多少次数据被刷新进了磁盘。
3）locked：写锁。
4）idx miss：索引未命中比例。
5）qr | qw：读写锁的请求队列长度。
6）conn： 当前已经建立的连接数。
这几个性能指标都很重要，当然，你从外表去观察，也就连接数了。
7.严重的空间碎片问题
mongodb 如果数据修改很频繁，会出现比较严重的空间碎片问题，表现在磁盘文件扩张与实际数据量不相符，内存不够用，索引命中率低，查询效率降低。
碎片整理，目前我们采用的版本没有太有效的方法。
可以用 db.repaireDatabase() 来整理数据库，这个过程非常的慢。
如果是 master/slave 模式，则相当于执行一次主从切换，然后从新建立从库。
如果是 replSet 架构，可以停掉数据库，然后删除数据目录，从新从复制组中全同步数据，这个时候要考虑 oplog 的尺寸。
一个大体的步骤：
1）先调用rs.freeze(1200)，将每个不想让它成为 primary 的机器让它在 1200 秒内无法成为 primary(这步也可以不做)；
2）将 primary stepDown，不出意外新的 primary 会起来；
3）将原 primary kill 掉；
4）删掉所有 data 数据(调用 repair 很慢，真不如干掉重新来)；
5）再重启动原 primary 的进程；
6）以此循环完成整个复制组的全部重建。
这个多年的库会存在大量碎片，但速度实在太慢，如果大数据，这个操作可要费点功夫了
8.连接池 WriterConcern 模式选择
有些应用配置了 WriterConcern.FSYNC_SAFE 模式；这种配置意味着客户端在插入数据或更新数据的时候，要求 mongodb 必须将所更新的数据写入磁盘并返回更新成功的信息给程序。
如果碰上应用程序访问压力大，mongodb 就会反应迟钝，并可能会假死。
针对此情况，需要评估数据的一致性需求，做出合适调整。
我们一般建议关闭此选项。
（评语：刘奎波的业务中心优化时就关闭了这个 WriterConcern.FSYNC_SAFE 模式）
9.开发时注意的细节
1）更新某条数据的时候，先查出来再更新会减小锁的时间；
2）只有真正需要的字段才select出来；
3）只有返回很少结果的查询才用索引，否则会加载太多数据，比没有用索引还慢！
4）属性比较多的时候，建立分层的关系能够提高查询效率，否则每个记录都要过一遍才能找到要的属性。（评语：貌似说的是以 Array 形式存储的 subdocument）
5）skip+limit 翻页，越往后面越慢。比较靠谱的做法是，先找出上次的id，翻页的时候不用 skip：
last_row_id = ObjectId('....');
db.activity_stream->find({_id:{$lt: last_row_id },user_id:20 } ).sort( {_id:-1} ).limit(10);
这个第一条Bmob后端云等平台，只提供基于objectid更新数据，也就是这个道理，让大家先查询出来，再更新。 第二条，需要大家自己优化，平台没法给你操作。 第五条其实是最常用的优化手段，在性能一般的情况，50w数据，就需要这样操作了
10.关于硬件资源的选择
虚拟机可以很好的隔离资源，并可动态的扩展。
我们建议 mongodb 的部署采用虚拟机的方式，每个虚拟机部署一个实例，使各节点分散在不同的物理机上，根据应用的前期预测，平衡虚拟机的之间的i/o。
