第一部分
基 础 篇
第1章 认识MongoDB
第2章 快速入门
第1章 认识MongoDB
MongoDB是一个高性能、开源、无模式的文档型数据库，使用C++开发，是当前NoSQL数据库产品中最热门的一种。在许多场景下，它可以替代传统的关系型数据库或键-值存储方式，官方网站地址是：http://www.mongodb.org/，读者可以在此获得更详细的信息。有一定NoSQL基础概念的读者可以跳过本章，直接开始后面内容的学习。没有接触过NoSQL的读者可以详细阅读本章，以便消化、吸收最基本的概念。
1.1 NoSQL简介
NoSQL（Not Only Sql，非关系型数据库）的主要特点包括非关系型的、分布式的、开源的、水平可扩展的。
NoSQL的原始目的是为了大规模Web应用，这场全新的数据库革命运动很早就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，通常的应用如模式***、支持简易复制、简单的API、最终的一致性（非ACID）、大容量数据等。NoSQL用得最多的是Key-Value（键值对）存储，当然还有文档型的、列存储、图型数据库、xml数据库等。相对于目前铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维。
1.1.1 产生背景
随着互联网Web 2.0网站的兴起，非关系型数据库已经成为一个极其热门的新领域，非关系型数据库产品的发展迅速，而传统的关系型数据库在应付Web 2.0网站，特别是超大规模和高并发的SNS类型的Web 2.0纯动态网站时已经显得力不从心，暴露了很多难以克服的问题，例如：

1. 对数据库高并发读写的需求
   Web 2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系型数据库应付上万次SQL查询还勉强可以，但是应付上万次SQL写数据请求，硬盘I/O就无法承受了。对于普通的BBS网站，往往也存在对高并发写请求的需求。
2. 对海量数据的高效率存储和访问的需求
   对于大型的SNS网站，每天用户产生海量的用户动态信息，甚至一个月就能达到2.5亿条用户动态，对于关系数据库来说，在一张存储2.5亿条记录的表里进行SQL查询，效率是极其低下甚至是不可忍受的。此外，大型Web网站的用户登录系统，例如腾讯、盛大，动辄数以亿计的账号，关系数据库也很难应付。
3. 对数据库的高可扩展性和高可用性的需求
   在基于Web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像Web Server和APP Server那样简单地通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，可是停机维护随之带来的就是公司收入的减少。

在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于Web 2.0网站来说，关系数据库的很多主要特性却无用武之地，例如：
数据库事务一致性需求。很多Web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。
数据库的写实时性和读实时性需求。对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出这条数据的，但是对于很多Web应用来说，并不要求这么高的实时性。
对复杂的SQL查询，特别是多表关联查询的需求。任何大数据量的Web系统都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就需要避免产生这种情况。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大地弱化了。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的NoSQL数据库应运而生。
1.1.2 NoSQL的种类及其特性
NoSQL是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论长期垄断数据库市场的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大量数据存取上具备关系型数据库无法比拟的性能优势，该概念在2009年年初得到了广泛认同。
NoSQL数据库根据数据的存储模型和特点分为很多种类，如表1-1所示。
表1-1 NoSQL数据库的种类

以上对NoSQL数据库类型的划分并不是绝对的，只是从存储模型上来进行的大体划分。它们之间也有交叉的情况，比如Tokyo Cabinet / Tyrant的Table类型存储就可以理解为文档型存储，Berkeley DB XML数据库是基于Berkeley DB之上开发的。
这些NoSQL数据库，有的是用C/C++编写的，有的是用Java编写的，还有的是用Erlang编写的，每种都有自己的独到之处，从中挑选一些比较有特色且应用广泛的产品学习和了解。

1. 满足海量存储需求和访问的面向文档的数据库
   面向文档的非关系型数据库主要解决的问题不是高性能的并发读写，而是在保证海量数据存储的同时，具有良好的查询性能。

（1）MongoDB
MongoDB是用C++开发的，主要解决的是海量数据的访问效率问题。根据官方文档记载，当数据量达到50GB以上的时候，MongoDB的数据库访问速度是MySQL的10倍以上。MongoDB的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万~1.5万次读写请求。
MongoDB还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储。
MongoDB也有一个Ruby的项目MongoMapper，是模仿Merb的DataMapper编写的MongoDB接口，使用起来非常简单，几乎和DataMapper一模一样，功能非常强大。
（2）CouchDB
CouchDB是用Erlang开发的面向文档的数据库系统，其数据存储方式类似Lucene的Index文件格式。CouchDB最大的意义在于它是一个面向Web应用的新一代存储系统，事实上，CouchDB的口号就是：下一代的Web应用存储系统。
它可以把存储系统分布到n台物理节点上，并且可以很好地协调和同步节点之间的数据读写一致性。这当然也得益于Erlang无与伦比的并发特性。
CouchDB支持REST API，可以让用户使用JavaScript来操作CouchDB数据库，也可以用JavaScript编写查询语句。可以想象，用AJAX技术结合CouchDB开发出来的CMS系统会是多么的简单和方便。

1. 满足极高读写性能需求的Key-Value数据库
   高性能Key-Value数据库的主要特点是具有极高的并发读写性能，如Redis、Tokyo Cabinet、Flare，这3种Key-Value DB都是用C语言编写的，除了出色的性能，它们还有自己独特的功能。

（1）Redis
Redis本质上是一个Key-Value类型的内存数据库，类似Memcached，整个数据库加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作，是我知道的性能最快的Key-Value DB。
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还支持对List进行各种操作。例如，从List两端push和pop数据、取List区间、排序，以及对Set支持各种集合的并集交集操作。此外，单个Value的最大限制是1GB，因此Redis可以用来实现很多有用的功能。例如，用它的List来做FIFO双向链表，实现一个轻量级的高性能消息队列服务，用它的Set可以做高性能的tag系统等。由于Redis也可以对存入的Key-Value设置expire时间，因此也可以当做一个功能加强版的Memcached。
Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生的可扩展机制，不具有可扩展能力，要依赖客户端来实现分布式读写。
（2）Tokyo Cabinet和Tokyo Tyrant
Tokyo Cabinet（TC）和Tokyo Tyrant（TT）的开发者是日本人Mikio Hirabayashi，主要用于日本最大的SNS网站mixi.jp。TC出现的时间最早，现在已经是一个非常成熟的项目，也是Key-Value数据库领域最大的热点，现在广泛应用于网站。TC是一个高性能的存储引擎，而TT提供了多线程高并发服务器，性能也非常出色，每秒可以处理4万~5万次读写操作。
TC除了支持Key-Value存储之外，还支持Hashtable数据类型，因此很像一个简单的数据库表，并且还支持基于Column的条件查询、分页查询和排序功能，基本上相当于支持单表的基础查询功能，所以可以简单地替代关系数据库的很多操作，这也是TC受到大家欢迎的主要原因之一。有一个Ruby项目miyazakiresistance将TT的Hashtable的操作封装成和ActiveRecord一样的操作，用起来非常高效。
TC/TT在Mixi的实际应用当中，存储了2000万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。TC在保证了极高的并发读写性能的同时，还具有可靠的数据持久化机制，同时还支持类似关系数据库表结构的Hashtable以及简单的条件、分页和排序操作，是一个很优越的NoSQL数据库。
TC的主要缺点是，在数据量达到上亿级别以后，并发写数据性能会大幅度下降，开发人员发现在TC里面插入1.6亿条2KB~20KB数据的时候，写入性能开始急剧下降。即当数据量达到上亿条的时候，TC性能便开始大幅度下降，从TC作者自己提供的Mixi数据来看，至少上千万条数据量的时候还没有遇到这么明显的写入性能瓶颈。
（3）Flare
TC是日本第一大SNS网站mixi.jp开发的，而Flare是日本第二大SNS网站green.jp开发的。简单地说，Flare就是给TC添加了scale（可扩展）功能。它替换了TT部分，自己另外给TC写了网络服务器。Flare的主要特点就是支持scale能力，它在网络服务端之前添加了一个Node Server，用来管理后端的多个服务器节点，因此可以动态添加数据库服务节点、删除服务器节点，也支持Failover。如果你的使用场景必须让TC可以scale，那么可以考虑Flare。
Flare唯一的缺点就是它只支持Memcached协议，因此，当使用Flare的时候，就不能使用TC的Table数据结构，只能使用TC的Key-Value数据结构存储。

1. 满足高可扩展性和可用性的面向分布式计算的数据库
   Cassandra和Voldemort都是用Java开发的面向scale能力的数据库，主要解决的问题领域和上述两类数据库不一样，它首先必须是一个分布式的数据库系统，由分布在不同节点上的数据库共同构成一个数据库服务系统，并且根据这种分布式架构来提供Online的，具有弹性的可扩展能力。例如，可以不停机地添加更多数据节点、删除数据节点等。因此，Cassandra常常被看成是一个开源版本的Google BigTable。

（1）Cassandra
Cassandra项目是Facebook在2008年开发出来的，随后，Facebook自己使用Cassandra的另外一个不开源的分支，而开源的Cassandra主要由Amazon的Dynamite团队维护，Cassandra被认为是Dynamite 2.0版本。目前，除了Facebook之外，Twitter和digg.com都在使用Cassandra。
Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务。对Cassandra的一个写操作会被复制到其他节点上，对Cassandra的读操作也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只需在群集里面添加节点就可以了。
若以单个节点来衡量Cassandra，其节点的并发读写性能不是特别好，但是评价Cassandra单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是许多个节点构成的系统，其并发性能取决于整个系统的节点数量和路由效率，而不仅仅是单节点的并发负载能力。
（2）Voldemort
Voldemort与Cassandra类似，也是面向解决scale问题的分布式数据库系统。Cassandra来自于Facebook这个SNS网站，而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了许多的NoSQL数据库，例如Cassandra、Voldemort、Tokyo Cabinet、Flare等。Voldemort的资料不是很多，Voldemort官方给出Voldemort的并发读写性能也很不错，每秒读写超过了1.5万次。
Facebook开发Cassandra，Linkedin开发Voldemort，从中可以大致看出国外大型SNS网站对于分布式数据库，特别是对数据库的scale能力方面的需求是多么殷切。前面提到，在Web应用的架构当中，Web层和APP层相对来说都很容易横向扩展，唯有数据库是单点的，极难scale，现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一个很好的方向，这也是现在Cassandra如此热门的主要原因。
1.1.3 NoSQL特点
当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求，而NoSQL存储就是实现了这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系，如Facebook 的Cassandra、Apache 的HBase，也得到了广泛认同。从这些NoSQL项目的名字上看不出什么相同之处：Hadoop、Voldemort、Dynomite，还有很多，但它们都有一个共同的特点，就是要改变大家对数据库在传统意义上的理解。
NoSQL特点如下：
运行在便宜的PC服务器集群上。PC集群扩充起来非常方便并且成本很低，避免了传统商业数据库Sharding操作的复杂性和成本。
击碎了性能瓶颈。NoSQL的支持者称，通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL格式的时间，执行速度变得更快。“SQL并非适用于所有的程序代码”，对于那些繁重的重复操作的数据，SQL值得花钱。但是当数据库结构非常简单时，SQL可能没有太大用处。
没有过多的操作。虽然NoSQL的支持者也承认关系型数据库提供了无可比拟的功能集合，而且在数据完整性上也发挥绝对稳定，他们同时也表示，企业的具体需求可能没有那么复杂。
支持者源于社区。因为NoSQL项目都是开源的，因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样，不得不从社区中寻求支持。
1.1.4 发展现状
当今的计算机体系结构在数据存储方面要求应用架构具备庞大的水平扩展性，而NoSQL正致力于改变这一现状。目前，新浪微博的Redis和Google的BigTable，以及Amazon的SimpleDB使用的就是NoSQL型数据库。　
从NoSQL项目的名字上看不出什么相同之处，但是，它们通常在某些方面相同：可以处理超大量的数据。　
这场革命目前仍然需要等待。NoSQL对大型企业来说还不是主流，但是，一两年之后很可能就会变个样子。在NoSQL运动的最新一次聚会中，来自世界各地的150人挤满了CBS Interactive的一间会议室。他们分享了如何推翻缓慢而昂贵的关系数据库的暴政，怎样使用更有效和更便宜的方法来管理数据。
关系型数据库给开发者强加了太多东西。它们要你强行修改对象数据，以满足数据库系统的需要。在NoSQL拥护者们来看，基于NoSQL的数据库替代方案“只是给你所需要的”。
现在NoSQL有很多成熟的产品得到广泛应用，图1-1是NoSQL族谱的一部分，现在知名的一些NoSQL数据库，比如Cassandra、HBase、MongoDB、CouchDB等都在其中，可以从图中看到这些数据库的起源派系。

如图所示，比较强大的两类是BigTable系（Google）和Dynamo系（Amazon）。两家公司都有这两个NoSQL数据库系统的论文发表。
注意　NoSQL产品非常多，图中只列举其中的一些代表。
NoSQL发展至今，出现了好几种非关系性数据库，本书以NoSQL中目前表现***的MongoDB为例进行说明。