MongoDB实战经验分享
本文内容纲要：
-对NoSQL的理解
-为什么是MongoDB？
-文档结构设计
-索引及查询优化
-复制分片及副本集
-其他
本文来自去年整理发布的“十天掌握MongoDB”系列PPT。该系列PPT的内容则来自当时的《MongoDB权威指南（英文版）》，个人翻译能力有限，不能保证PPT的内容完全符合该书的内容。而且，我还加入了大量的自己的看法。今天分享给大家的便是其中的第十课，主要是我个人当时的观点，这些观点在现在看来不一定都是正确的，请大家多多批评指正！
对NoSQL的理解
NoSQL并不是No-SQL，而是指NotOnlySQL。
NoSQL的出现是为了弥补SQL数据库因为事务等机制带来的对海量数据、高并发请求的处理的性能上的欠缺。
NoSQL不是为了替代SQL而出现的，它是一种替补方案，而不是解决方案的首选。
绝大多数的NoSQL产品都是基于大内存和高性能随机读写的（比如具有更高性能的固态硬盘阵列），一般的小型企业在选择NoSQL时一定要慎重！不要为了NoSQL而NoSQL，可能会导致花了冤枉钱又耽搁了项目进程。
NoSQL不是万能的，但在大型项目中，你往往需要它！
为什么是MongoDB？
- 基于BSON，兼容JSON
- 有广泛的驱动支持
- 高性能、开源、面向文档
- 全文索引支持
- 自动复制分片
- 内置分布式文件系统
- 内置MapReduce支持
- ……
不要被老陈骗了，我只是想罗列一下MongoDB的优点，如果想了解其他NoSQL产品，不妨看看http://cloud.csdn.net/a/20110610/299526.html
文档结构设计
在SQL时代，我们可以任意设计自己的表结构，仅仅需要注意数据类型的选择，只是无法直接使用树形设计而已。
在MongoDB就没这么幸运了，MongoDB内置的查询机制非常有限，它无法让"你的原来的设计"那么轻松的就能迁移过来。
其实，MongoDB这样的"不给力"，都是"故意"的！通过核心算法的约束，强迫开发者大量的使用冗余数据来提升计算效率。
这个做法，好！也不好！好的是，的确可以解决很多问题，不好的是，因此我们需要改变之前一贯的思路，甚至是之前认为非常一般般的做法，还会给维护带来很多"看起来不必要"的麻烦。
MongoDB宣称自己占用的处理器资源是很低的——其实是因为它的架构就直接绕开了很多运算！！！
在这里我没有太多想说的，总结起来就一句话——不要吝啬存储空间，要将冗余数据的优点发挥到极致！
索引及查询优化
传统的用于优化SQL的技巧，在MongoDB中同样适用；
不要为所有键都创建索引，也不要一个索引也不用；
如果需要，请优先考虑复合索引，但请注意键的顺序；
如果发现即使创建索引也无法很有效的提升，此时应该考虑将数据分片；
设计查询时，应当将能够过滤掉大量记录的条件放在前面，除非这样的改动影响了业务需求。
无论什么业务，请尽量避免在数据库端处理各种排序，如果可以，请尽量减少这样的设计，以提升数据库服务器的吞吐量。老陈的经验是：用户其实并不讨厌多点几次鼠标，讨厌的是点了N多次鼠标之后，找不到合适的内容。试想一下，为什么baidu不提供用户主动排序的功能？
复制分片及副本集
复制是指将数据完完整整的复制到其他MongoDB实例上；
分片是将一块数据很多小块并分发到不同的集合或MongoDB实例；
副本集带有故障转移的特性
而实际上，在生产环境中，我们应当将如上三个概念混合使用，并发挥到极致。
数据安全、运算效率以及负载分流、故障转移等等，每一个特性都需要做的很强壮！
还记得前面说过的吗，NoSQL不是谁都可以玩的，也不是谁都可以玩好的！一个强壮的MongoDB集群可能需要至少十几台服务器，光硬件就是不小的投入！
关于数据安全——不要迷信任何设备，应当经常备份重要的业务数据。
是的，使用复制可以对MongoDB的数据执行热备份。而不需要停掉主数据库引擎。
其他
尽量少用嵌套文档，它会让你的数据库膨胀的非常快，且不利于扩展；
当然，我不是说不要用，如果没有对子文档的深层查询、排序，或者根本就是记录一下而已，这种情况用子文档是最爽不过了！
MongoDB不适合存储高精度的数字，比如你需要精度非常高的财务数据存储，此时建议使用其他持久化方案，或者你干脆就存成字符串或者创建一个字符串格式的副本进行存储。
MongoDB没有内联查询机制，全靠手工外键；
MongoDB没有自增标识，未来的规划中也没有迹象表明要支持，实际上，这是MongoDB故意的！我们建议使用随机标识，而不是递增标识。
标识，读作biaozhi4，而不是biaoshi2，记好了哈！
本文内容总结：对NoSQL的理解，为什么是MongoDB？，文档结构设计，索引及查询优化，复制分片及副本集，其他，
原文链接：https://www.cnblogs.com/ymind/archive/2012/04/25/2470551.html