转载请著明作者与出处。franciscolv http://shuofenglxy.iteye.com/admin/blogs/1330539
第一条：划分shard，使用replSet,保证服务不会全部失效,存储容灾很关键。
第二条：大表要分表，划分ReplSet之后，表还是只存在于一个shard中。小表看需要。
第三条：良好的键值设计，字段名称要短，不要用传统的数据库方式思考。一切能key-value的就不要考虑条件查询神马。索引再好也是比较，能定位到就不要比较，可以通过限制一些功能的方式来满足。
第三条：关于写可靠性问题。尽量不要开启获取写结果，MongoDB是锁库写，同步获取结果会对全库的其他操作有影响。
第四条：索引很好，但还是要减少它的使用，不要为了一些低频度非关键功能设计额外索引。海量数据下，索引占用空间也是非常可观的，更主要的是它占的是内存空间。这本身会造成热点数据的减少。
第五条：MongoDB总连接数的控制，Linux下一个连接大约堆栈开10M空间，这里如果连接数很多的话，建议把堆栈大小设小。
第六条：MongoDB能嵌套的地方尽量不要整引用，完全杜绝跨库引用。简单是数据可靠高效的前提。海量背景下，简单就会意味着高效、可靠。
第七条：MongoDB java client端每个应用服务器一个Mongo实例就足够，其内置了连接池，只需要对其进行配置即可满足并发场景支持，单机一般不超过100，其实多实例场景50-70绰绰有余。池化的思想到哪都不会错，只要不用错。
第八条：读写配置可分开，老版本slaveOk就可以，新版本的话有个ReadPreference.SECONDARY，配置后即可简单的读写分流了。
第九条：数据库统计数据很重要，MongoDB支持的非常好，java client端通过mongo实例获得全库的数据描述，也可以获得某个collection的数据描述，时时关注比le it alone要好很多。
第十条： 不要怕手工方案麻烦，演练好预案，任何未经严格验证+线上复杂场景的自动化方案都是不靠谱的，多做容灾，异常备案比神马都好。