为什么MongoDB对于你的项目来说是一个好的选择？我想我已经给出不少理由了。本节中，我会更明确地进行说明，首先说说MongoDB项目的总体设计目标。根据其作者的观点，MongoDB的设计是要结合键值存储和关系型数据库的最好特性。键值存储，因为非常简单，所以速度极快而且相对容易伸缩。关系型数据库较难伸缩，至少很难水平伸缩，但拥有富数据模型和强大的查询语言。如果MongoDB能介于两者之间，就能成为一款易伸缩、能存储丰富数据结构、提供复杂查询机制的数据库。
在使用场景方面，MongoDB非常适合用做以下应用程序的主要数据存储：Web应用程序、分析与记录应用程序，以及任何要求有中等级别缓存的应用程序。此外，由于它能方便地存储无Schema数据，MongoDB还很适合保存事先无法知晓其数据结构的数据。
之前所说的内容还不太足以让人信服，为了证实它们，我们大致了解一下目前市面上的众多数据库，并和MongoDB做个对比。接下来，我将讨论一些特殊的MongoDB使用场景，提供一些生产环境中的例子。最后，我还会讨论一些MongoDB实际使用中的重要注意事项。
1.4.1 MongoDB与其他数据库的对比
市面上的数据库数量成爆炸式增长，要在它们之间进行权衡是很困难的。幸运的是，它们之中的大多数数据库都能归在几个分类里。本节中，我会描述简单及复杂的键值存储、关系型数据库和文档数据库，并将它们与MongoDB做一个比较。下面来看表1-1。
表1-1 数据库家族
1. 简单键值存储
简单键值存储正如其名，基于给定的键对值做索引。常见的场景是缓存。举例来说，假设需要缓存一个由应用程序呈现的HTML页面，此处的键可能是页面的URL，值是HTML本身。请注意，对键值存储而言，值就是一个不透明的字节数组。没有强加关系型数据库中的Schema，也没有任何数据类型的概念。这自然限制了键值存储允许的操作：可以放入一个新值，然后通过键将其找出或删除。拥有如此简单性的系统通常很快，而且具有可伸缩性。
最著名的简单键值存储是memcached（发音是mem-cash-dee）。memcached仅在内存里存储数据，用持久性来换取速度。它也是分布式的，跨多台服务器的memcached节点能像单个数据存储那样来使用，这消除了维护跨服务器缓存状态的复杂性。
与MongoDB相比，memcached这样的简单键值存储通常读写会更快。但与MongoDB不同，这些系统很少能充当主要数据存储。简单键值存储的最佳用途是附加存储，既可以作为传统数据库之上的缓存层，也可以作为任务队列之类的短暂服务的简单持久层。
2. 复杂键值存储
可以改进简单键值模型来处理复杂的读写Schema或提供更丰富的数据模型。如此一来，就有了复杂键值存储。广为流传的论文“Dynamo: Amazon’s Highly Available Key-value Store”中描述的亚马逊 Dynamo就是这样一个例子。Dynamo旨在成为一个健壮的数据库，在网络故障、数据中心停转及类似情况下仍能工作。这要求系统总是能够被读和写，本质上就是要求数据能自动跨多个节点进行复制。如果一个节点发生故障，系统的用户（在这里可能是一个使用亚马逊购物车的顾客）不会察觉到服务中断。当系统允许同一份数据被写到多个节点时，发生冲突的情况是不可避免的，Dynamo提供了一些解决冲突的方法。与此同时，Dynamo也很容易伸缩。因为没有主节点，所有节点都是对等的，所以很容易从整体上理解系统，能方便地添加节点。尽管Dynamo是一个私有系统，但其构建理念启发了很多NoSQL系统，包括Cassandra、Project Voldemort和Riak。
看看是谁开发了这些复杂键值存储，看看实践中它们的使用情况如何，你就能知道它们的优点了。以Cassandra为例，它实现了很多Dynamo的伸缩属性，同时还提供了与谷歌 BigTable类似的面向列的数据模型。Cassandra是一款开源的数据存储，是Facebook为其收件箱搜索功能开发的。该系统可以水平扩展，索引超过50 TB的收件箱数据，允许在收件箱中对关键字和收件人做检索。数据是根据用户ID做索引的，每条记录由一个用于关键字检索的搜索项数组和一个用于收件人检索的收件人ID数组构成。1
1. 参见http://mng.bz/5321。
这些复杂键值存储是由亚马逊、谷歌和Facebook这样的大型互联网公司开发的，用来管理系统的多个部分，拥有非常大的数据量。换言之，复杂键值存储管理了一个相对自包含的域，它对海量存储和可用性有一定要求。由于采用了无主节点的架构，这些系统能轻松地通过添加节点进行扩展。它们都选择了最终一致性，也就是说读请求不必返回最后一次写的内容。用户用较弱的一致性所换得的是在某一节点失效时仍能写入的能力。
这与MongoDB正好相反，MongoDB提供了强一致性、（每个分片）一个主节点、更丰富的数据模型，还有二级索引，最后两项特性总是一起出现的。如果一个系统允许跨多个域建模，例如构建完整Web应用程序时就会有此要求，那么查询就需要跨整个数据模型，这时就要用到二级索引了。
因为有丰富的数据模型，可以考虑把MongoDB作为更通用的大型、可伸缩Web应用程序的解决方案。MongoDB的伸缩架构有时也会受到非难，因为它并非源自Dynamo。但针对不同域有不同的伸缩解决方案。MongoDB的自动分片受到了雅虎PNUTS数据存储和谷歌 BigTable的启发。读过展示这些数据存储技术的白皮书的人会发现，Mongodb实现伸缩的方法已经有成功的案例。
3. 关系型数据库
本章已经介绍了不少关系型数据库的内容，简单起见，我只讨论RDBMS与MongoDB的相同点和不同点。尽管MySQL2使用固定Schema的数据表，MongoDB使用无Schema的文档，但两者都能表示丰富的数据模型。MySQL和MongoDB都支持B树索引，那些适用于MySQL索引的经验也同样适用于MongoDB。MySQL支持联结和事务，因此如果你必须使用SQL或者要求有事务，那么只能选择MySQL或其他RDBMS。也就是说，MongoDB的文档模型足以在不用联结查询的情况下表示对象。MongoDB中对单独文档的更新也是原子的，这提供了传统事务的一个子集。MongoDB和MySQL都支持复制。就可伸缩性而言，MongoDB设计成能水平扩展，能自动分片并处理故障转移。MySQL上的分片都需要手动管理，有一定的复杂性，更常见的是垂直扩展的MySQL系统。
2. 这里我用MySQL来做说明，因为我所描述的特性适用于大多数关系型数据库。
4. 文档数据库
自称为文档数据库的产品还不多，在本书编写时，除了MongoDB之外，唯一的著名文档型数据库就是Apache CouchDB。尽管CouchDB的数据是使用JSON格式的纯文本存储的，而MongoDB是使用BSON二进制格式，但两者的文档模型是相似的。与MongoDB一样，CouchDB也支持二级索引，不同之处是CouchDB中的索引是通过编写MapReduce函数来定义的，这比MySQL和MongoDB使用的声明式语法更复杂一些。两者伸缩的方式也有所不同，CouchDB不会把数据分散到多台服务器上，每个CouchDB节点都是其他节点的完整副本。
1.4.2 使用场景和生产部署
老实说，我们不会仅根据数据库的特性做选择，还需要知道使用它的真实成功案例。这里，我提供一些广义上的MongoDB使用场景，以及一些生产环境中的示例3。
3. 要想获得在生产环境中使用了MongoDB的最新案例列表，请访问http://mng.bz/z2CH。
1.Web应用程序
MongoDB很适合作为Web应用程序的主要数据存储。就算是一个简单的Web应用程序也会有很多数据模型，用来管理用户、会话、应用特定的数据、上传和权限，更不用说非常重要的域了。正如它们能和关系型数据库的表列数据配合良好一样，它们也能获益于MongoDB的集合与文档模型。因为文档能表示丰富的数据结构，建模相同数据所需的集合数量通常会比使用完全正规化关系型模型的数据表数量要少。此外，动态查询和二级索引能让你轻松地实现SQL开发者所熟悉的大多数查询。最后，作为一个成长中的Web应用程序，MongoDB提供了清晰的扩展路线。
在生产环境中，MongoDB已经证明它能管理应用的方方面面，从主要数据领域到附加数据存储，比如日志和实时分析。这里的案例来自The Business Insider（TBI），它从2008年1月起将MongoDB作为主要数据存储使用。虽然TBI是一个新闻网站，但它流量很大，每天有超过一百万独立页面访问。这个案例中有意思的是除了处理站点的主要内容（文章、评论、用户等），MongoDB还处理并存储实时分析数据。这些分析被TBI用于生成动态热点地图，标明不同新闻故事的点击率。该站目前还没有太多的数据，因此尚不需要分片，但它有使用副本集来保证停电时的自动故障转移。
2. 敏捷开发
无论如何看待敏捷开发运动，你都很难否认对于快速构建应用程序的渴望。不少开发团队，包括Shutterfly和纽约时报的团队，都部分选择了MongoDB，因为相比关系型数据库，使用MongoDB能更快地开发应用程序。一个明显的原因是MongoDB没有固定的Schema，所有花在提交、沟通和实施Schema变更的时间都省下来了。
除此之外，不再需要花时间把数据的关系型表述硬塞进面向对象的数据模型里去了，也不用处理ORM生成的SQL的奇怪行为，或者对它做优化了。如此一来，MongoDB为项目带来了更短的开发周期和敏捷的、中等大小的团队。
3.分析和日志
我之前已经暗示过MongoDB适用于分析和日志，将MongoDB用于这些方面的应用程序数量增长得很快。通常，发展成熟的公司都会选择将用于分析的特殊应用作为切入点，进入MongoDB的世界。这些公司包括GitHub、Disqus、Justin.tv和Gilt Groupe，还有其他公司就不再列举了。
MongoDB与分析的关联源自于它的速度和两个关键特性：目标原子更新和固定集合（capped collection）。原子更新让客户端能高效地增加计数器，将值放入数组。固定集合，常用于日志，特点是分配的大小固定，能实现自动过期。相比文件系统，将日志数据保存在数据库里更易组织，而且能提供更强大的查询能力。现在，抛开grep或自定义日志检索工具，用户可以使用他们熟悉并喜欢的MongoDB查询语言来查看日志输出。
4.缓存
这是一种数据模型，它能更完整地表示对象，结合更快的平均查询速度，经常让MongoDB介于传统的MySQL与memcached之间。例如之前提到的TBI，它可以不使用memcached，直接通过MongoDB来响应页面请求。
5. 可变Schema
看看这段代码示例4：
4. 这个想法来自于http://mng.bz/52XI。如果想运行这段代码，需要把-umongodb:secret替换成自己的Twitter用户名和密码。
curl https://stream.twitter.com/1/statuses/sample.json -umongodb:secret| mongoimport -c tweets
这里从Twitter流上拉下一小段示例，并用管道将其直接导入MongoDB集合。因为流生成的是JSON文档，在把它发给数据库前就不需要预先处理数据了。mongoimport工具能直接将数据转换成BSON。这意味着每条推文都能保持其结构，原封不动地存储为集合中的单个文档。无论你是想查询、索引还是执行MapReduce聚合，都能立刻操作数据。而且，不需要事先声明数据的结构。
如果应用程序需要调用JSON API，那么拥有这样一个能轻松转换JSON的系统就太棒了。如果在存储之前无法预先了解数据的结构，MongoDB没有Schema约束的特性能大大简化数据模型。