NoSQL

NoSQL简介

NoSQL概念:

图；NoSQL概念的演变

NoSQL最初表示的“反SQL”运动，用新型的非关系型数据库取代关系型数据库。

现在NoSQL（Not only SQL）表示关系和非关系型数据库各有优缺点，彼此都无法互相取代。

NoSQL的特点：

通常，NoSQL数据库具有以下几个特点：

灵活的可扩展性。
灵活的数据模型
与云计算紧密融合。

现在有很多公司都使用了NoSQL数据库：如Google，Facebook，百度，阿里等。

NoSQL兴起的原因

原因一：关系型数据库已经无法满足Web2.0的需求

关系型数据库无法满足Web2.0的需求，主要表现在以下几个方面：

无法满足海量数据的管理需求。
无法满足数据高并发的需求。
无法满足高可扩展性和高可用性的需求。

在现在1分钟的时间内：

新浪可以发送2万条微博。
苹果可以下载4.7万次应用。
淘宝可以卖出6万件商品。
人人网可以发送30万次访问。
百度可以产生90万次搜索查询。

MySQL集群是否可以完全解决问题？

复杂性：部署、管理、配置很复杂。
数据库复制：MySQL主备之间采用复制方式，只能是异步复制，当主库压力较大时可能产生较大延迟，主备切换可能会丢失最后一部分更新事务，这时往往需要人工介入，备份和恢复不方便。
扩容问题：如果系统压力过大需要增加新的机器，这个过程涉及数据重新划分，整个过程比较复杂，且容易出错。
动态数据迁移问题：如果某个数据库组压力过大，需要将其中部分数据迁移出去，迁移过程需要总控节点整体协调，以及数据库节点的配合。这个过程很难做到自动化。

原因二：“One size fits all”模式很难适用于截然不同的业务场景：

关系模型作为统一的数据模型既被用于数据分析，也被用于在线业务。但这两者一个强调高吞吐，一个强调低延时，已经演化出完全不同的架构。用同一套模型来抽象显然是不合适的。
Hadoop就是针对数据分析。
MongoDB、Redis等是针对在线业务，两者都抛弃了关系模型。

原因三：关系型数据库的关键特性：

关系数据库的关键特性包括完善的事务机制和高效的查询机制。但是，关系数据库引以为傲的两个关键特性，到了Web2.0时代却成了鸡肋，主要表现在以下几个方面：

Web2.0网站系统通常不要求严格的数据库事务。
Web2.0并不要求严格的读写实时性。
Web2.0通常不包含大量复杂的SQL查询（去结构化，存储空间换取更好的查询性能）。

NoSQL与关系型数据库的比较

NoSQL和关系数据库的简单比较：

RDBMS即关系数据库管理系统(Relational Database Management System)。

对比总结：

关系数据库：

优势：以完善的关系代数理论作为基础，有严格的标准，支持事务ACID四性，借助索引机制可以实现高效的查询，技术成熟，有专业公司的技术支持。
劣势：可扩展性较差，无法较好支持海量数据存储，数据模型过于死板、无法较好支持Web2.0应用，事务机制影响了系统的整体性能等。

NoSQL数据库：

优势：可以支持超大规模数据存储，灵活的数据模型可以很好地支持Web2.0应用，具有强大的横向扩展能力等。
劣势：缺乏数学理论基础，复杂查询性能不高，大都不能实现事务强一致性，很难实现数据完整性，技术尚不成熟，缺乏专业团队的技术支持，维护较困难等。

关系数据库和NoSQL数据库各有优缺点，彼此无法取代。

关系数据库应用场景：电信、银行等领域的关键业务系统，需要保证强事务一致性。
NoSQL数据库应用场景：互联网企业、传统企业的非关键业务（比如数据分析）。
采用混合架构：
案例：亚马逊公司就使用不同类型的数据库来支撑它的电子商务应用。
对于“购物篮”这种临时性数据，采用键值存储会更加高效。
当前的产品和订单信息则适合存放在关系数据库中。
大量的历史订单信息则适合保存在类似MongoDB的文档数据库中。

NoSQL的四大类型

四大类：

NoSQL数据库虽然数量众多，但是，归结起来，典型的NoSQL数据库通常包括键值数据库、列族数据库、文档数据库和图形数据库。

图:键值数据库示例

图：列族数据库

图：文档数据库

图：图形数据库

四大数据库的主要产品：

图：四大数据库的主要产品

键值数据库：

列族数据库：

文档数据库：

“文档”其实是一个数据记录，这个记录能够对包含的数据类型和内容进行“自我描述”。XML文档、HTML文档和JSON 文档就属于这一类。SequoiaDB就是使用JSON格式的文档数据库，它的存储的数据是这样的：

图：文档数据库示例

文档数据库的特点：

数据是不规则的，每一条记录包含了所有的有关“SequoiaDB”的信息而没有任何外部的引用，这条记录就是“自包含”的。
这使得记录很容易完全移动到其他服务器，因为这条记录的所有信息都包含在里面了，不需要考虑还有信息在别的表没有一起迁移走。
同时，因为在移动过程中，只有被移动的那一条记录（文档）需要操作，而不像关系型中每个有关联的表都需要锁住来保证一致性，这样一来ACID的保证就会变得更快速，读写的速度也会有很大的提升。

文档数据库的相关产品：

MongoDB、CouchDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit

数据模型：

键/值
值（value）是版本化的文档

典型应用：

存储、索引并管理面向文档的数据或者类似的半结构化数据。
比如，用于后台具有大量读写操作的网站、使用JSON数据结构的应用、使用嵌套结构等非规范化数据的应用程序。

优点：

性能好（高并发），灵活性高，复杂性低，数据结构灵活。
提供嵌入式文档功能，将经常查询的数据存储在同一个文档中。
既可以根据键来构建索引，也可以根据内容构建索引

缺点：缺乏统一的查询语法。

不适用情形：

在不同的文档上添加事务。文档数据库并不支持文档间的事务，如果对这方面有需求，则不应该选用这个解决方案。

使用者：

百度云数据库（MongoDB）、SAP （MongoDB）、Codecademy （MongoDB）、Foursquare （MongoDB）、NBC News （RavenDB）

图形数据库：

不同类型数据库比较分析；

MySQL产生年代较早，而且随着（Web应用软件组合）LAMP（Linux+Apache+Mysql/MariaDB+Perl/PHP/Python）大潮得以成熟。尽管其没有什么大的改进，但是新兴的互联网使用的最多的数据库。

MongoDB是个新生事物，提供更灵活的数据模型、异步提交、地理位置索引等五花十色的功能。

HBase是个“仗势欺人”的大象兵。依仗着Hadoop的生态环境，可以有很好的扩展性。但是就像象兵一样，使用者需要养一头大象(Hadoop),才能驱使他。

Redis是键值存储的代表，功能最简单。提供随机数据存储。就像一根棒子一样，没有多余的构造。但是也正是因此，它的伸缩性特别好。就像悟空手里的金箍棒，大可捅破天，小能成缩成针。

NoSQL的三大基石

三大基石：CAP，BASE，最终一致性。

CAP：

所谓的CAP指的是：

C（Consistency）：一致性，是指任何一个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是一致的，或者说，所有节点在同一时间具有相同的数据。
A:（Availability）：可用性，是指快速获取数据，可以在确定的时间内返回操作结果，保证每个请求不管成功或者失败都有响应；
P（Tolerance of Network Partition）：分区容忍性，是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。

图：CAP Theorem(理论)

CAP理论告诉我们，一个分布式系统不可能同时满足一致性、可用性和分区容忍性这三个需求，最多只能同时满足其中两个，正所谓“鱼和熊掌不可兼得”。

当处理CAP的问题时，可以有几个明显的选择：

CA：也就是强调一致性（C）和可用性（A），放弃分区容忍性（P），最简单的做法是把所有与事务相关的内容都放到同一台机器上。很显然，这种做法会严重影响系统的可扩展性。传统的关系数据库（MySQL、SQL Server和PostgreSQL），都采用了这种设计原则，因此，扩展性都比较差
CP：也就是强调一致性（C）和分区容忍性（P），放弃可用性（A），当出现网络分区的情况时，受影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务
AP：也就是强调可用性（A）和分区容忍性（P），放弃一致性（C），允许系统返回不一致的数据

图：不同产品在CAP理论下的不同设计原则

BASE:

说起BASE（Basically Availble, Soft-state, Eventual consistency），不得不谈到ACID。

一个数据库事务具有ACID四性：

A（Atomicity）：原子性，是指事务必须是原子工作单元，对于其数据修改，要么全都执行，要么全都不执行。
C（Consistency）：一致性，是指事务在完成时，必须使所有的数据都保持一致状态。
I（Isolation）：隔离性，是指由并发事务所做的修改必须与任何其它并发事务所做的修改隔离。
D（Durability）：持久性，是指事务完成之后，它对于系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持。

BASE的基本含义是基本可用（Basically Availble）、软状态（Soft-state）和最终一致性（Eventual consistency）：

基本可用：

基本可用，是指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现。

软状态：

“软状态（soft-state）”是与“硬状态（hard-state）”相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步，具有一定的滞后性。

最终一致性：

一致性的类型包括强一致性和弱一致性，二者的主要区别在于高并发的数据访问操作下，后续操作是否能够获取最新的数据。对于强一致性而言，当执行完一次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据；反之，如果不能保证后续访问读到的都是更新后的最新数据，那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例，允许后续的访问操作可以暂时读不到更新后的数据，但是经过一段时间之后，必须最终读到更新后的数据。

最常见的实现最终一致性的系统是DNS（域名系统）。一个域名更新操作根据配置的形式被分发出去，并结合有过期机制的缓存；最终所有的客户端可以看到最新的值。

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，又可以区分为：

因果一致性：如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将获得A写入的最新值。而与进程A无因果关系的进程C的访问，仍然遵守一般的最终一致性规则。
“读己之所写”一致性：可以视为因果一致性的一个特例。当进程A自己执行一个更新操作之后，它自己总是可以访问到更新过的值，绝不会看到旧值。
单调读一致性：如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
会话一致性：它把访问存储系统的进程放到会话（session）的上下文中，只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话。
单调写一致性：系统保证来自同一个进程的写操作顺序执行。系统必须保证这种程度的一致性，否则就非常难以编程了。

如何实现各种类型的一致性？

对于分布式数据系统：

N — 数据复制的份数
W — 更新数据是需要保证写完成的节点数
R — 读取数据的时候需要读取的节点数
如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。一般设定是R＋W = N+1，这是保证强一致性的最小设定。
如果W+R<=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。

对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。

如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。实例：HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前，写操作是不会返回成功的。也就是说它的W＝N，而读操作只需要读到一个值即可，也就是说它R＝1。

像Voldemort，Cassandra和Riak这些类Dynamo的系统，通常都允许用户按需要设置N，R，W三个值，即使是设置成W＋R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性，或者是W<N的强一致性时，则总会出现一段“各个节点数据不同步导致系统处理不一致的时间”。为了提供最终一致性的支持，这些系统会提供一些工具来使数据更新被最终同步到所有相关节点。