NoSQL数据库

NoSQL简介

NoSQL是一种不同于关系数据库的数据库管理系统设计方式，是对非关系型数据库的统称，它所采用的数据模型并非传统关系数据库的关系模型，而是类似键值、列族、文档等非关系模型。NoSQL数据库没有固定的表结构，通常也不存在连接操作，也没有严格遵守ACID约束。因此，与关系数据库相比，NoSQL具有灵活的水平可扩展性，可以支持海量数据存储。此外，NoSQL数据库支持MapReduce风格的编程，可以较好地应用于大数据时代的各种数据管理。NoSQL 数据库的出现，一方面弥补了关系数据库在当前商业应用中存在的各种缺陷，另一方面也撼动了关系数据库的传统垄断地位。当应用场合需要简单的数据模型、灵活性的IT系统、较高的数据库性能和较低的数据库一致性时，NoSQL数据库是一个很好的选择。通常NoSQL数据库具有以下3个特点。

1. 灵活的可扩展性（横向扩展）
2. 灵活的数据模型（采用键值、列族等非关系模型，允许在一个数据元素里存储不同类型的数据）
3. 与云计算紧密融合

NoSQL兴起的原因

关系型数据库已经无法满足web2.0的需求

1. 无法满足海量数据的管理需求
   在Web 2.0时代，每个用户都是信息的发布者，用户的购物、社交、搜索等网络行为都在产生大量数据。对于关系数据库来说，在一张10亿条记录的表里进行SQL查询，效率极其低下甚至是不可忍受的。
2. 无法满足数据高并发的需求
   在Web 1.0 时代，通常采用动态页面静态化技术，事先访问数据库生成静态页面供浏览者访问，从而保证在大规模用户访问时，也能够获得较好的实时响应性能。但是，在Web 2.0 时代，各种用户都在不断地发生更新，动态页面静态化技术基本没有用武之地，所有信息都需要动态实时生成，这就会导致高并发的数据库访问，可能产生每秒上万次的读写请求，对于很多关系数据库而言，这都是“难以承受之重”。
3. 无法满足高可扩展性和高可用性的需求
   在Web 2.0时代，不知名的网站可能一夜爆红，用户迅速增加，已经广为人知的网站也可能因为发布了热门吸引眼球的信息，引来大量用户在短时间内围绕该信息大量交流互动，这些都会导致对数据库读写负荷的急剧增加，需要数据库能够在短时间内迅速提升性能应对突发需求。但是，遗憾的是，关系数据库通常是难以水平扩展的，没有办法像网页服务器和应用服务器那样简单地通过添加更多的硬件和服务节点来扩展性能和负载能力。
4. Web 2.0网站系统通常不要求严格的数据库事务
   对于许多Web 2.0 网站而言，数据库事务已经不是那么重要。比如，对于微博网站而言，如果一个用户发布微博过程出现错误，可以直接丢弃该信息，而不必像关系数据库那样执行复杂的回滚操作，这样并不会给用户造成什么损失。而且，数据库事务通常有一套复杂的实现机制来保证数据库一致性，需要大量系统开销，对于包含大量频繁实时读写请求的Web 2.0网站而言，实现事务的代价是难以承受的。
5. Web 2.0并不要求严格的读写实时性
   对于关系数据库而言，一旦有一条数据记录成功插人数据库中，就可以立即被查询。这对于银行等金融机构而言，是非常重要的。银行用户肯定不希望自已刚刚存人一笔钱，却无法在系统中立即查询到这笔存款记录。但是，对于Web 2.0 而言，却没有这种实时读写需求，用户的微博粉丝数量增加了10个，在几分钟后显示更新后的粉丝数量，用户可能也不会察觉。
6. Web 2.0通常不包含大量复杂的SQL查询
   复杂的SQL查询通常包含多表连接操作，在数据库中，多表连接操作代价高昂，因此各类SQL查询处理引擎都设计了十分巧妙的优化机制，通过调整选择、投影、连接等操作的顺序，达到尽早缩小参与连接操作的元组数目的目的，从而降低连接代价、提高连接效率。但是，Web 2.0网站在设计时就已经尽量减少甚至避免这类操作，通常只采用单表的主键查询，因此关系数据库的查询优化机制在Web 2.0中也就难以有所作为。

MySQL集群并不能完全解决问题

主从备份（master sliver）所有写操作针对主服务器，写入后同步到从服务器（同步传播or异步传播）

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

One size fits all

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

NoSQL与关系数据库的比较

比较标准	RDBMS	NoSQL	备注
数据库原理	完全支持	部分支持	RDBMS有关系代数理论作为基础，NoSQL没有统一的理论基础
数据规模	大	超大	RDBMS很难实现横向扩展， 纵向扩展的空间也比较有限， 性能会随着数据规模的增大而降低NoSQL可以很容易通过添加更多设备来支持更大规模的数据
数据库模式	固定	灵活	RDBMS需要定义数据库模式， 严格遵守数据定义和相关约束条件。NoSQL不存在数据库模式， 可以自由灵活定义并存储各种不同类型的数据
数据库模式	固定	灵活	RDBMS需要定义数据库模式， 严格遵守数据定义和相关约束条件。NoSQL不存在数据库模式， 可以自由灵活定义并存储各种不同类型的数据
一致性	强一致性	弱一致性	RDBMS严格遵守事务ACID模型， 可以保证事务强一致性。很多NoSQL数据库放松了对事务ACID四性的要求， 而是遵守BASE模型， 只能保证最终一致性
数据完整性	容易实现	很难实现	任何一个RDBMS都可以很容易实现数据完整性，比如通过主键或者非空约束来实现实体完整性，通过主键、 外键来实现参照完整性， 通过约束或者触发器来实现用户自定义完整性但是， 在NoSQL数据库却无法实现
扩展性	一般	好	RDBMS很难实现横向扩展， 纵向扩展的空间也比较有限。NoSQL在设计之初就充分考虑了横向扩展的需求， 可以很容易通过添加廉价设备实现扩展
可用性	好	很好	RDBMS在任何时候都以保证数据一致性为优先目标， 其次才是优化系统性能， 随着数据规模的增大， RDBMS为了保证严格的一致性， 只能提供相对较弱的可用性大多数NoSQL都能提供较高的可用性
标准化	是	否	RDBMS已经标准化（SQL）NoSQL还没有行业标准， 不同的NoSQL数据库都有自己的查询语言， 很难规范应用程序接口
技术支持	高	低	RDBMS经过几十年的发展， 已经非常成熟，Oracle等大型厂商都可以提供很好的技术支持。NoSQL在技术支持方面仍然处于起步阶段， 还不成熟， 缺乏有力的技术支持
可维护性	复杂	复杂	RDBMS需要专门的数据库管理员(DBA)维护。NoSQL数据库虽然没有DBMS复杂， 也难以维护

总结：
（ 1）关系数据库
优势：以完善的关系代数理论作为基础，有严格的标准，支持事务ACID四性，借助索引机制可以实现高效的查询，技术成熟，有专业公司的技术支持
劣势：可扩展性较差，无法较好支持海量数据存储，数据模型过于死板、无法较好支持Web2.0应用，事务机制影响了系统的整体性能等
（ 2） NoSQL数据库
优势：可以支持超大规模数据存储，灵活的数据模型可以很好地支持Web2.0应用，具有强大的横向扩展能力等
劣势：缺乏数学理论基础，复杂查询性能不高，大都不能实现事务强一致性，很难实现数据完整性，技术尚不成熟，缺乏专业团队的技术支持，维护较困难等

关系数据库和NoSQL数据库各有优缺点，彼此无法取代
关系数据库应用场景：电信、银行等领域的关键业务系统，需要保证强事务一致性
NoSQL数据库应用场景：互联网企业、传统企业的非关键业务（比如数据分析）
采用混合架构

•案例：亚马逊公司就使用不同类型的数据库来支撑它的电子商务应用
对于“购物篮”这种临时性数据，采用键值存储会更加高效
当前的产品和订单信息则适合存放在关系数据库中
大量的历史订单信息则适合保存在类似MongoDB的文档数据库中

NoSQL的四大类型

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

键值数据库

列族数据库

文档数据库

图数据库

NoSQL三大基石

CAP

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

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

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

BASE

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

1. 基本可用：
   基本可用，是指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现
2. 软状态：
   “软状态（soft-state）”是与“硬状态（hard-state）”相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步，具有一定的滞后性
3. 最终一致性
   一致性的类型包括强一致性和弱一致性，二者的主要区别在于高并发的数据访问操作下，后续操作是否能够获取最新的数据。对于强一致性而言，当执行完一次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据；反之，如果不能保证后续访问读到的都是更新后的最新数据，那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例，允许后续的访问操作可以暂时读不到更新后的数据，但是经过一段时间之后，必须最终读到更新后的数据。最常见的实现最终一致性的系统是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的强一致性时，则总会出现一段“各个节点数据不同步导致系统处理不一致的时间”。为了提供最终一致性的支持，这些系统会提供一些工具来使数据更新被最终同步到所有相关节点。

补充：数据库事务的ACID原则

ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。

1. 原子性（Atomicity）

   整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被 回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

2. 一致性（Consistency）
   一个事务可以封装状态改变（除非它是一个只读的）。事务必须始终保持系统处于一致的状态，不管在任何给定的时间 并发事务有多少。
   也就是说：如果事务是 并发多个，系统也必须如同串行事务一样操作。其主要特征是保护性和不变性(Preserving an Invariant)，以转账 案例为例，假设有五个账户，每个账户余额是100元，那么五个账户总额是500元，如果在这个5个账户之间同时发生多个转账，无论 并发多少个，比如在A与B账户之间转账5元，在C与D账户之间转账10元，在B与E之间转账15元，五个账户总额也应该还是500元，这就是保护性和不变性

3. 隔离性（Isolation）
   隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为 串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。

4. 持久性（Durability）
   在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

由于一项操作通常会包含许多子操作，而这些子操作可能会因为硬件的损坏或其他因素产生问题，要正确实现ACID并不容易。ACID建议数据库将所有需要更新以及修改的资料一次操作完毕，但实际上并不可行。
目前主要有两种方式实现ACID：第一种是Write ahead logging，也就是日志式的方式(现代数据库均基于这种方式)。第二种是Shadow paging。
相对于WAL（write ahead logging）技术，shadow paging技术实现起来比较简单，消除了写日志记录的开销恢复的速度也快(不需要redo和undo)。shadow paging的缺点就是事务提交时要输出多个块，这使得提交的开销很大，而且以块为单位，很难应用到允许多个事务并发执行的情况——这是它致命的缺点。
WAL 的中心思想是对数据文件 的修改（它们是表和索引的载体）必须是只能发生在这些修改已经 记录了日志之后 ——也就是说，在日志记录冲刷到永久存储器之后． 如果我们遵循这个过程，那么我们就不需要在每次事务提交的时候 都把数据页冲刷到磁盘，因为我们知道在出现崩溃的情况下， 我们可以用日志来恢复数据库：任何尚未附加到数据页的记录 都将先从日志记录中重做（这叫向前滚动恢复，也叫做 REDO） 然后那些未提交的事务做的修改将被从数据页中删除 （这叫向后滚动恢复 UNDO）。