你们有没有据说过“NoSQL”呢？近年，这个词极受关注。看到“NoSQL”这个词，你们可能会误觉得是“No！SQL”的缩写，并深感愤怒：“SQL怎么会没有必要了呢？”但实际上，它是“Not Only SQL”的缩写。它的意义是：适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，能够考虑使用更加合适的数据存储。 数据库
为弥补关系型数据库的不足，各类各样的NoSQL数据库应运而生。数组
为了更好地了解本书所介绍的NoSQL数据库，对关系型数据库的理解是必不可少的。那么，就让咱们先来看一看关系型数据库的历史、分类和特征吧。 缓存
1969年，埃德加•弗兰克•科德（Edgar Frank Codd）发表了划时代的论文，首次提出了关系数据模型的概念。但惋惜的是，刊登论文的《IBM Research Report》只是IBM公司的内部刊物，所以论文反响平平。1970年，他再次在刊物《Communication of the ACM》上发表了题为“A Relational Model of Data for Large Shared Data banks”（大型共享数据库的关系模型）的论文，终于引发了你们的关注。 服务器
科德所提出的关系数据模型的概念成为了现今关系型数据库的基础。当时的关系型数据库因为硬件性能低劣、处理速度过慢而迟迟没有获得实际应用。但以后随着硬件性能的提高，加之使用简单、性能优越等优势，关系型数据库获得了普遍的应用。网络
虽然本书是讲解NoSQL数据库的，但有一个重要的大前提，请你们必定不要误解。这个大前提就是“关系型数据库的性能绝对不低，它具备很是好的通用性和很是高的性能”。毫无疑问，对于绝大多数的应用来讲它都是最有效的解决方案。 并发
突出的优点
关系型数据库做为应用普遍的通用型数据库，它的突出优点主要有如下几点: memcached
这其中，可以保持数据的一致性是关系型数据库的最大优点。在须要严格保证数据一致性和处理完整性的状况下，用关系型数据库是确定没有错的。可是有些状况不须要JOIN，对上述关系型数据库的优势也没有什么特别须要，这时彷佛也就没有必要拘泥于关系型数据库了。高并发
不擅长的处理
就像以前提到的那样，关系型数据库的性能很是高。可是它毕竟是一个通用型的数据库，并不能彻底适应全部的用途。具体来讲它并不擅长如下处理： 性能
。。。。。。网站
为了弥补关系型数据库的不足（特别是最近几年），NoSQL数据库出现了。关系型数据库应用普遍，能进行事务处理和JOIN等复杂处理。相对地，NoSQL数据库只应用在特定领域，基本上不进行复杂的处理，但它偏偏弥补了以前所列举的关系型数据库的不足之处。
易于数据的分散
如前所述，关系型数据库并不擅长大量数据的写入处理。本来关系型数据库就是以JOIN为前提的，就是说，各个数据之间存在关联是关系型数据库得名的主要缘由。为了进行JOIN处理，关系型数据库不得不把数据存储在同一个服务器内，这不利于数据的分散。相反，NoSQL数据库本来就不支持JOIN处理，各个数据都是独立设计的，很容易把数据分散到多个服务器上。因为数据被分散到了多个服务器上，减小了每一个服务器上的数据量，即便要进行大量数据的写入操做，处理起来也更加容易。同理，数据的读入操做固然也一样容易。
提高性能和增大规模
下面说一点题外话，若是想要使服务器可以轻松地处理更大量的数据，那么只有两个选择：一是提高性能，二是增大规模。下面咱们来整理一下这二者的不一样。
首先，提高性能指的就是经过提高现行服务器自身的性能来提升处理能力。这是很是简单的方法，程序方面也不须要进行变动，但须要一些费用。若要购买性能翻倍的服务器，须要花费的资金每每不仅是原来的2倍，可能须要多达5到10倍。这种方法虽然简单，可是成本较高。
另外一方面，增大规模指的是使用多台廉价的服务器来提升处理能力。它须要对程序进行变动，但因为使用廉价的服务器，能够控制成本。另外，之后只要依葫芦画瓢增长廉价服务器的数量就能够了。
不对大量数据进行处理的话就没有使用的必要吗？
NoSQL数据库基本上来讲为了“使大量数据的写入处理更加容易（让增长服务器数量更容易）”而设计的。但若是不是对大量数据进行操做的话，NoSQL数据库的应用就没有意义吗？
答案是否认的。的确，它在处理大量数据方面颇有优点。但实际上NoSQL数据库还有各类各样的特色，若是可以恰当地利用这些特色将会是很是有帮助。具体的例子将会在第2章和第3章进行介绍，这些用途将会让你感觉到利用NoSQL的好处。
多样的NoSQL数据库
NoSQL数据库存在着“key-value存储”、“文档型数据库”、“列存储数据库”等各类各样的种类，每种数据库又包含各自的特色。下一节让咱们一块儿来了解一下NoSQL数据库的种类和特色。
NoSQL提及来简单，但实际上到底有多少种呢？我在提笔的时候，到NoSQL的官方网站上确认了一下，居然已经有122种了。另外官方网站上也介绍了本书没有涉及到的图形数据库和对象数据库等各个类别。不知不觉间，原来已经出现了这么多的NoSQL数据库啊。
本节将为你们介绍具备表明性的NoSQL数据库。
这是最多见的NoSQL数据库，它的数据是以key-value的形式存储的。虽然它的处理速度很是快，可是基本上只能经过key的彻底一致查询获取数据。根据数据的保存方式能够分为临时性、永久性和二者兼具三种。
临时性
memcached属于这种类型。所谓临时性就是 “数据有可能丢失”的意思。memcached把全部数据都保存在内存中，这样保存和读取的速度很是快，可是当memcached中止的时候，数据就不存在了。因为数据保存在内存中，因此没法操做超出内存容量的数据（旧数据会丢失）。
永久性
Tokyo Tyrant、Flare、ROMA等属于这种类型。和临时性相反，所谓永久性就是“数据不会丢失”的意思。这里的key-value存储不像memcached那样在内存中保存数据，而是把数据保存在硬盘上。与memcached在内存中处理数据比起来，因为必然要发生对硬盘的IO操做，因此性能上仍是有差距的。但数据不会丢失是它最大的优点。
二者兼具
Redis属于这种类型。Redis有些特殊，临时性和永久性兼具，且集合了临时性key-value存储和永久性key-value存储的优势。Redis首先把数据保存到内存中，在知足特定条件（默认是15分钟一次以上，5分钟内10个以上，1分钟内10000个以上的key发生变动）的时候将数据写入到硬盘中。这样既确保了内存中数据的处理速度，又能够经过写入硬盘来保证数据的永久性。这种类型的数据库特别适合于处理数组类型的数据。
MongoDB、CouchDB属于这种类型。它们属于NoSQL数据库，但与key-value存储相异。
不定义表结构
面向文档的数据库具备如下特征：即便不定义表结构，也能够像定义了表结构同样使用。关系型数据库在变动表结构时比较费事，并且为了保持一致性还需修改程序。然而NoSQL数据库则可省去这些麻烦（一般程序都是正确的），确实是方便快捷。
可使用复杂的查询条件
跟key-value存储不一样的是，面向文档的数据库能够经过复杂的查询条件来获取数据。虽然不具有事务处理和JOIN这些关系型数据库所具备的处理能力，但除此之外的其余处理基本上都能实现。这是很是容易使用的NoSQL数据库。
Cassandra、Hbase、HyperTable属于这种类型。因为近年来数据量出现爆发性增加，这种类型的NoSQL数据库尤为引人注目。
面向行的数据库和面向列的数据库
普通的关系型数据库都是以行为单位来存储数据的，擅长进行以行为单位的读入处理，好比特定条件数据的获取。所以，关系型数据库也被称为面向行的数据库。相反，面向列的数据库是以列为单位来存储数据的，擅长以列为单位读入数据。
高扩展性
面向列的数据库具备高扩展性，即便数据增长也不会下降相应的处理速度（特别是写入速度），因此它主要应用于须要处理大量数据的状况。另外，利用面向列的数据库的优点，把它做为批处理程序的存储器来对大量数据进行更新也是很是有用的。但因为面向列的数据库跟现行数据库存储的思惟方式有很大不一样，应用起来十分困难。
最近，像Twitter和Facebook这样须要对大量数据进行更新和查询的网络服务不断增长，面向列的数据库的优点对其中一些服务是很是有用的，可是因为这与本书所要介绍的内容关系不大，就不进行详细介绍了。
总结：
NoSQL并非No-SQL，而是指Not Only SQL。
NoSQL的出现是为了弥补SQL数据库由于事务等机制带来的对海量数据、高并发请求的处理的性能上的欠缺。
NoSQL不是为了替代SQL而出现的，它是一种替补方案，而不是解决方案的首选。
绝大多数的NoSQL产品都是基于大内存和高性能随机读写的（好比具备更高性能的固态硬盘阵列），通常的小型企业在选择NoSQL时必定要慎重！不要为了NoSQL而NoSQL，可能会致使花了冤枉钱又耽搁了项目进程。
NoSQL不是万能的，但在大型项目中，你每每须要它！