本文转载自：http://book.2cto.com/201211/7897.html

市面上的数据库数量成爆炸式增长，要在它们之间进行权衡是很困难的。幸运的是，它们之中的大多数数据库都能归在几个分类里。本节中，我会描述简单及复杂的键值存储、关系型数据库和文档数据库，并将它们与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数组构成。¹

这些复杂键值存储是由亚马逊、谷歌和Facebook这样的大型互联网公司开发的，用来管理系统的多个部分，拥有非常大的数据量。换言之，复杂键值存储管理了一个相对自包含的域，它对海量存储和可用性有一定要求。由于采用了无主节点的架构，这些系统能轻松地通过添加节点进行扩展。它们都选择了最终一致性，也就是说读请求不必返回最后一次写的内容。用户用较弱的一致性所换得的是在某一节点失效时仍能写入的能力。

这与MongoDB正好相反，MongoDB提供了强一致性、（每个分片）一个主节点、更丰富的数据模型，还有二级索引，最后两项特性总是一起出现的。如果一个系统允许跨多个域建模，例如构建完整Web应用程序时就会有此要求，那么查询就需要跨整个数据模型，这时就要用到二级索引了。

因为有丰富的数据模型，可以考虑把MongoDB作为更通用的大型、可伸缩Web应用程序的解决方案。MongoDB的伸缩架构有时也会受到非难，因为它并非源自Dynamo。但MongoDB针对不同域有不同的伸缩解决方案。MongoDB的自动分片受到了雅虎PNUTS数据存储和谷歌 BigTable的启发。读过发布这些数据存储的白皮书的人会发现，MongoDB实现伸缩的方法已经被实现了，而且还很成功。

3. 关系型数据库

本章已经介绍了不少关系型数据库的内容，简单起见，我只讨论RDBMS与MongoDB的相同点和不同点。尽管MySQL²使用固定Schema的数据表，MongoDB使用无Schema的文档，但两者都能表示丰富的数据模型。MySQL和MongoDB都支持B树索引，那些适用于MySQL索引的经验也同样适用于MongoDB。MySQL支持联结和事务，因此如果你必须使用SQL或者要求有事务，那么只能选择MySQL或其他RDBMS。也就是说，MongoDB的文档模型足以在不用联结查询的情况下表示对象。MongoDB中对单独文档的更新也是原子的，这提供了传统事务的一个子集。MongoDB和MySQL都支持复制。就可伸缩性而言，MongoDB设计成能水平扩展，能自动分片并处理故障转移。MySQL上的分片都需要手动管理，有一定的复杂性，更常见的是垂直扩展的MySQL系统。

4. 文档数据库

自称为文档数据库的产品还不多，在本书编写时，除了MongoDB之外，唯一的著名文档型数据库就是Apache CouchDB。尽管CouchDB的数据是使用JSON格式的纯文本存储的，而MongoDB是使用BSON二进制格式，但两者的文档模型是相似的。与MongoDB一样，CouchDB也支持二级索引，不同之处是CouchDB中的索引是通过编写MapReduce函数来定义的，这比MySQL和MongoDB使用的声明式语法更复杂一些。两者伸缩的方式也有所不同，CouchDB不会把数据分散到多台服务器上，每个CouchDB节点都是其他节点的完整副本。
________________________________
1 参见http://mng.bz/5321。
2 这里我用MySQL来做说明，因为我所描述的特性适用于大多数关系型数据库。

[以下补充内容来自：http://book.2cto.com/201211/7896.html 为什么选择MongoDB]

MongoDB项目的总体设计目标。根据其作者的观点，MongoDB的设计是要结合键值存储和关系型数据库的最好特性。键值存储，因为非常简单，所以速度极快而且相对容易伸缩。关系型数据库较难伸缩，至少很难水平伸缩，但拥有富数据模型和强大的查询语言。如果MongoDB能介于两者之间，就能成为一款易伸缩、能存储丰富数据结构、提供复杂查询机制的数据库。

在使用场景方面，MongoDB非常适合用做以下应用程序的主要数据存储：Web应用程序、分析与记录应用程序，以及任何要求有中等级别缓存的应用程序。此外，由于它能方便地存储无Schema数据，MongoDB还很适合保存事先无法知晓其数据结构的数据。