【IT168 评论】本文来自去年整理发布的“十天掌握MongoDB”系列PPT。该系列PPT的内容则来自当时的《MongoDB权威指南(英文版)》，个人翻译能力有限，不能保证PPT的内容完全符合该书的内容。而且，我还加入了大量的自己的看法。今天分享给大家的便是其中的第十课，主要是我个人当时的观点，这些观点在现在看来不一定都是正确的，请大家多多批评指正!

　　对NoSQL的理解

　　NoSQL并不是No-SQL，而是指Not Only SQL。

　　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，记好了哈!