CAP理论？BASE模型？——NoSQL学习第一弹
来源：厦门大学计算机科学系 林子雨《大数据技术原理与应用（第2版）》第5章 NoSQL数据库 PPT讲义
相关链接：http://dblab.xmu.edu.cn/post/bigdata
整理：CoderGeshu
前言
在现代的计算系统及网络上，每天都会产生庞大的数据量。
这些数据有很大一部分是由关系型数据库管理系统（RDBMS）来处理。关系模型是由 IBM 的研究员 E.F.Codd 博士在 1970 年首先提出，它使得数据建模和应用程序编程更加简单。
而 NoSQL 是一项全新的数据库革命性运动，早期就有人提出，至 2009 年发展趋势越发高涨。
NoSQL 的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入……
正文
什么是 NoSQL？
NoSQL 是「Not Only SQL」的缩写。它所表达的意思是：适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。
为弥补关系型数据库的不足，各种各样的 NoSQL 数据库应运而生，如 MongoDB、Redis、HBase 等。
通常，NoSQL数据库具有以下几个特点：
灵活的可扩展性；
灵活的数据模型；
与云计算紧密融合。
NoSQL 兴起的原因
原因一：关系数据库已经无法满足 Web2.0 的需求
正如上文所说，现代计算机网络中时刻都会产生庞大的数据量，关系数据库已经无法满足 Web2.0 的需求，其主要表现在以下几个方面：
无法满足海量数据的管理需求；
无法满足数据高并发的需求；
无法满足高可扩展性和高可用性的需求。
此时也许有同学会问道：「使用 MySQL 集群是否可以完全解决问题？」，确实，随着数据量的大幅度增加，使用数据库集群可以使读写分离，提高数据库的系统性能。
但数据库集群也会带来相应的问题——
复杂性：集群的部署、管理、配置很复杂。
数据库复制：MySQL 主备之间采用复制方式，只能是异步复制，当主库压力较大时可能产生较大延迟，主备切换可能会丢失最后一部分更新事务，这时往往需要人工介入，备份和恢复不方便。
扩容问题：如果系统压力过大需要增加新的机器，这个过程涉及数据重新划分，整个过程比较复杂，且容易出错。
动态数据迁移问题：如果某个数据库组压力过大，需要将其中部分数据迁移出去，迁移过程需要总控节点整体协调，以及数据库节点的配合。这个过程很难做到自动化。
原因二：「 One size fits all 」模式很难适用于截然不同的业务场景
关系模型作为统一的数据模型既被用于数据分析，也被用于在线业务。但这两者一个强调高吞吐，一个强调低延时，已经演化出完全不同的架构。用同一套模型来抽象显然是不合适的。而在 NoSQL 数据库中，Hadoop 是针对数据分析，MongoDB、Redis 等是针对在线业务，两者都抛弃了关系模型。
原因三：关系型数据库事务机制和高效查询机制变为鸡肋
关系数据库的关键特性包括完善的事务机制和高效的查询机制。但是，关系数据库引以为傲的两个关键特性，到了 Web2.0 时代却成了鸡肋，主要表现在以下几个方面：
Web2.0 网站系统通常不要求严格的数据库事务
Web2.0 并不要求严格的读写实时性
Web2.0 通常不包含大量复杂的 SQL 询（去结构化，存储空间换取更好的查询性能）
NoSQL VS RDBMS
对于 NoSQL 和传统关系型数据库的比较，我们从以下几个角度进行分析。
数据库原理：RDBMS 完全支持，NoSQL 部分支持
RDBMS 有关系代数理论作为基础，因而完全支持数据库原理；NoSQL 没有统一的理论基础，只部分支持。
数据规模：RDBMS 大，NoSQL 超大
RDBMS，很难实现横向扩展，纵向扩展的空间也比较有限，性能会随着数据规模的增大而降低；NoSQL 可以很容易通过添加更多设备来支持更大规模的数据。
数据库模式：RDBMS 固定，NoSQL 灵活
RDBMS 需要定义数据库模式，严格遵守数据定义和相关约束条件；NoSQL 不存在数据库模式，可以自由灵活定义并存储各种不同类型的数据。
查询效率：RDBMS 快，NoSQL 简单查询高效，不具备高度结构化查询，复杂查询性能低
RDBMS 借助于索引机制可以实现快速查询（包括记录查询和范围查询）；很多 NoSQL 数据库没有面向复杂查询的索引，虽然 NoSQL 可以使用 MapReduce 来加速查询，但是，在复杂查询方面的性能仍然不如 RDBMS。
一致性：RDBMS 强一致性，NoSQL 弱一致性
RDBMS 严格遵守事务 ACID 模型，可以保证事务强一致性；很多 NoSQL 数据库放松了对事务 ACID 四性的要求，而是遵守 BASE 模型，只能保证最终一致性。
实现数据完整性：RDBMS 容易，NoSQL 很难
任何一个 RDBMS 都可以很容易实现数据完整性，比如通过主键或者非空约束来实现实体完整性，通过主键、外键来实现参照完整性，通过约束或者触发器来实现用户自定义完整性；但是，这些在 NoSQL 数据库却无法实现。
扩展性：RDBMS 良好，NoSQL 很好
RDBMS 很难实现横向扩展，纵向扩展的空间也比较有限；NoSQL 在设计之初就充分考虑了横向扩展的需求，可以很容易通过添加廉价设备实现扩展。
可用性：RDBMS 好，NoSQL 很好
RDBMS 在任何时候都以保证数据一致性为优先目标，其次才是优化系统性能，随着数据规模的增大，RDBMS 为了保证严格的一致性，只能提供相对较弱的可用性；而大多数 NoSQL 都能提供较高的可用性。
标准化：RDBMS 是，NoSQL 否
RDBMS 已经标准化（SQL）；NoSQL 还没有行业标准，不同的 NoSQL 数据库都有自己的查询语言，很难规范应用程序接口。StoneBraker 认为：NoSQL 缺乏统一查询语言，将会拖慢 NoSQL 发展
技术支持：RDBMS 高，NoSQL 低
RDBMS 已经经过几十年的发展，现已非常成熟，Oracle 等大型厂商都可以提供很好的技术支持；NoSQL 在技术支持方面仍然处于起步阶段，还不成熟，缺乏有力的技术支持。
可维护性：RDBMS 复杂，NoSQL 复杂
RDBMS 需要专门的数据库管理员（DBA）维护；NoSQL 数据库虽然没有 DBMS 复杂，但也难以维护。
总结
关系数据库：
优势：以完善的关系代数理论作为基础，有严格的标准，支持事务 ACID 四性，借助索引机制可以实现高效的查询，技术成熟，有专业公司的技术支持。
劣势：可扩展性较差，无法较好支持海量数据存储，数据模型过于死板、无法较好支持 Web2.0 应用，事务机制影响了系统的整体性能等。
NoSQL 数据库：
优势：可以支持超大规模数据存储，灵活的数据模型可以很好地支持 Web2.0 应用，具有强大的横向扩展能力等。
劣势：缺乏数学理论基础，复杂查询性能不高，大都不能实现事务强一致性，很难实现数据完整性，技术尚不成熟，缺乏专业团队的技术支持，维护较困难等。
关系数据库和 NoSQL 数据库各有优缺点，彼此无法取代。
关系数据库应用场景：电信、银行等领域的关键业务系统，需要保证强事务一致性等；NoSQL 数据库应用场景：互联网企业、传统企业的非关键业务（比如数据分析）等。
NoSQL的四大类型
NoSQL 数据库虽然数量众多，但是归结起来，典型的 NoSQL 数据库通常包括键值数据库、列族数据库、文档数据库和图形数据库。
键值数据库和列族数据库存储结构模型如图所示：
文档数据库和图形数据库存储结构模型如图所示：
下面再来介绍一下每种 NoSQL 数据库类型下的常用产品、应用及优缺点。NoSQL 四大类型下的具体产品如下图所示：
键值数据库
| 相关产品 | Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached |
|---|---|
| 数据模型 | 键/值对：键是一个字符串对象，值可以是任意类型的数据，比如整型、字符型、数组、列表、集合等 |
| 典型应用 | 涉及频繁读写、拥有简单数据模型的应用；内容缓存，比如会话、配置文件、参数、购物车等 ；存储配置和用户数据信息的移动应用 |
| 优点 | 扩展性好、灵活性好，大量写操作时性能高 |
| 缺点 | 无法存储结构化信息，条件查询效率较低 |
| 不适用的情形 | 不是通过键而是通过值来查：键值数据库根本没有通过值查询的途径；需要存储数据之间的关系：在键值数据库中，不能通过两个或两个以上的键来关联数据；需要事务的支持：在一些键值数据库中，产生故障时，不可以回滚 |
| 使用者 | 百度云数据库（Redis）、GitHub（Riak）、BestBuy（Riak）、Twitter（Redis 和 Memcached）、StackOverFlow（Redis）、Instagram（Redis）、Youtube（Memcached）、Wikipedia（Memcached） |
由于键值数据库的特性，使其成为理想的缓冲层解决方案，其执行流程为：
Redis 有时候会被人们称为「 强化版的Memcached」，其支持持久化、数据恢复、且具有更多数据类型等。
文档数据库
| 相关产品 | MongoDB、CouchDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit |
|---|---|
| 数据模型 | 键/值：值（value）是版本化的文档 |
| 典型应用 | 存储、索引并管理面向文档的数据或者类似的半结构化数据：比如，用于后台具有大量读写操作的网站、使用 JSON 数据结构的应用、使用嵌套结构等非规范化数据的应用程序 |
| 优点 | 性能好（高并发）、灵活性高、复杂性低、数据结构灵活；提供嵌入式文档功能，将经常查询的数据存储在同一个文档中 既可以根据键来构建索引，也可以根据内容构建索引 |
| 缺点 | 缺乏统一的查询语法 |
| 不适用情形 | 在不同的文档上添加事务：文档数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案 |
| 使用者 | 百度云数据库（MongoDB）、SAP（MongoDB）、Codecademy（MongoDB）、Foursquare（MongoDB）、NBC News（RavenDB） |
「文档」其实是一个数据记录，这个记录能够对包含的数据类型和内容进行“自我描述”。XML 文档、HTML 文档和 JSON 文档就属于这一类。MongoDB 就是使用 JSON 格式的文档数据库，它的存储的数据是这样的：
{
"_id" : 1001,
"name" : "CoderGeshu",
"password" : "CoderGeshu",
"sex" : "male",
"age" : 18,
"Tel" : {
"Office" : "1234556",
"Mobile" : "456789"
}
}
由上述数据格式及结构可以发现，数据是不规则的，每一条记录包含了所有的有关 CoderGeshu 的信息而没有任何外部的引用，这条记录就是自包含的；这使得记录很容易完全移动到其他服务器，因为这条记录的所有信息都包含在里面了，不需要考虑还有信息在别的表没有一起迁移走；同时，因为在移动过程中，只有被移动的那一条记录（文档）需要操作，而不像关系型中每个有关联的表都需要锁住来保证一致性，这样一来 ACID 的保证就会变得更快速，读写的速度也会有很大的提升。
列族数据库
| 相关产品 | BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS |
|---|---|
| 数据模型 | 列族 |
| 典型应用 | 分布式数据存储与管理；数据在地理上分布于多个数据中心的应用程序；可以容忍副本中存在短期不一致情况的应用程序；拥有动态字段的应用程序；拥有潜在大量数据的应用程序，大到几百TB的数据 |
| 优点 | 查找速度快、可扩展性强、容易进行分布式扩展、复杂性低 |
| 缺点 | 功能较少，大都不支持强事务一致性 |
| 不适的用情形 | 需要 ACID 事务支持的情形，Cassandra 等产品就不适用 |
| 使用者 | Ebay（Cassandra）、Instagram（Cassandra）、NASA（Cassandra）、Twitter（Cassandra and HBase）、Facebook（HBase）、Yahoo!（HBase） |
图形数据库
| 相关产品 | Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB |
|---|---|
| 数据模型 | 图结构 |
| 典型应用 | 专门用于处理具有高度相互关联关系的数据，比较适合于社交网络、模式识别、依赖分析、推荐系统以及路径寻找等问题 |
| 优点 | 灵活性高，支持复杂的图形算法，可用于构建复杂的关系图谱 |
| 缺点 | 复杂性高，只能支持一定的数据规模 |
| 使用者 | Adobe（Neo4J）、Cisco（Neo4J）、T-Mobile（Neo4J） |
不同类型数据库比较分析
MySQL 产生年代较早，而且随着 LAMP 大潮得以成熟。尽管其没有什么大的改进，但是新兴的互联网使用的最多的数据库。
MongoDB 是个新生事物，提供更灵活的数据模型、异步提交、地理位置索引等五花十色的功能。
HBase 是个“仗势欺人”的大象兵。依仗着 Hadoop 的生态环境，可以有很好的扩展性。但是就像象兵一样，使用者需要养一头大象(Hadoop) 才能驱使它。
Redis 是键值存储的代表，功能最简单。提供随机数据存储。就像一根棒子一样，没有多余的构造。但是也正是因此，它的伸缩性特别好。就像悟空手里的金箍棒，大可捅破天，小能成缩成针。
NoSQL 的三大理论基石
CAP 理论
所谓的 CAP 指的是——
C（Consistency）：一致性。指任何一个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是一致的，或者说，所有节点在同一时间具有相同的数据。
A（Availability）：可用性。指快速获取数据，并可以在确定的时间内返回操作结果，保证每个请求不管成功或者失败都有响应。
P（Tolerance of Network Partition）：分区容忍性。指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。
我们理想的目标是：希望设计一个分布式系统能够同时满足CAP。但是理论和实践都证明「鱼和熊掌不可兼得」，在一个分布式系统中，不可能同时满足一致性、可用性和分区容忍性这三个需求，而是最多只能同时满足其中两个，所以当处理 CAP 的问题时，可以有以下几个明显的选择：
CA：强调一致性和可用性，放弃分区容忍性。最简单的做法是把所有与事务相关的内容都放到同一台机器上，很显然，这种做法会严重影响系统的可扩展性。传统的关系数据库（MySQL、SQL Server 和 PostgreSQL）都采用了这种设计原则，因此扩展性都比较差。
CP：强调一致性和分区容忍性，放弃可用性。当出现网络分区的情况时，受影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务（不可用）。
AP：强调可用性和分区容忍性，放弃一致性。它允许系统返回不一致的数据。
下面来看一个牺牲一致性来换取可用性的实例，现假设在一个分布式系统中，有两台机器，各自有进程 P1 和 P2，如下图，两库中的 V1 和 V2 值相互关联，即逻辑上二者保持一致。
正常情况下，如果 P1 更改了 V1 中的值，那么 V2 中的值也会发生相应变化，P2 进程读出来的应该为更改过后的值。如下：
但我们注意，从 V1 传播新值到 V2 这一过程并不能保证都是正确的，它也有可能在传播过程中发生失败现象，那么此时问题就来了，如果新值传播失败，则 V2 中的值就不会被更新，此时 P2 去读取时，可有两个选择：（1）把旧值返回给 P2（即牺牲一致性），（2）不向 P2 提供服务，直到 V2 新值更新成功（即牺牲可用性）。
这里我们以牺牲一致性为例，即在新值传播时，也对外提供服务，只是此时向进程 P2 提供的为旧值（即允许不一致）。
不同产品在 CAP 理论下会因为不同的设计原则，选择其中两者，放弃另外一个。比如，传统的 MySQL、SQL Server 就是放弃了它的分区容忍性。所以传统的 MySQL 都不会去做分区，就只是放在一台机器上。Hbase、Redis 是放弃了可用性，所以 Hbase 中的一些数据可能会有一定的延迟。
BASE 模型
在关系型数据库中，追求的是 ACID 特性，而在 NoSQL 数据库中追求的是 BASE 特性。
BASE 是 Basically Available、Soft state 和 Eventual consistency 的简写，意思是「碱」；ACID 是关系数据库中的事务的四个性质。在 NoSQL 数据库中 BASE（碱）和 ACID（酸）是对应的。
| ACID | BASE |
|---|---|
| 原子性(Atomicity) | 基本可用(Basically Available) |
| 一致性(Consistency) | 软状态/柔性事务(Soft state) |
| 隔离性(Isolation) | 最终一致性 (Eventual consistency) |
| 持久性 (Durable) |
ACID 特性 （即使了然于胸，也要时时温习）
A（Atomicity）：原子性，是指事务必须是原子工作单元，对于其数据修改，要么全都执行，要么全都不执行。C（Consistency）：一致性，是指事务在完成时，必须使所有的数据都保持一致状态。I（Isolation）：隔离性，是指由并发事务所做的修改必须与任何其它并发事务所做的修改隔离。D（Durability）：持久性，是指事务完成之后，它对于系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持。
BASE 特性
BasicallyAvailable：基本可用，是指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现。Soft state：「软状态（soft-state）」是与「硬状态（hard-state）」相对应的一种说法。当数据库保存的数据是硬状态时，可以保证数据一致性，即保证数据一直是正确的；而相对的，软状态是指状态可以有一段时间不同步，具有一定的滞后性。Eventual consistency：最终一致性。一致性的类型包括 强一致性 和 弱一致性，二者的主要区别在于高并发的数据访问操作下，后续操作是否能够获取最新的数据。对于强一致性而言，当执行完一次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据；反之，如果不能保证后续访问读到的都是更新后的最新数据，那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例，它允许后续的访问操作可以暂时读不到更新后的数据，但是经过一段时间之后，必须最终读到更新后的数据。最常见的实现最终一致性的系统是 DNS（域名系统）。一个域名更新操作根据配置的形式被分发出去，并结合有过期机制的缓存，最终所有的客户端可以看到最新的值。
最终一致性
最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，又可以区分为：因果一致性、「读己之所写」一致性、会话一致性、单调读一致性、单调写一致性。
因果一致性
如果进程 A 通知进程 B 它已更新了一个数据项，那么进程 B 的后续访问将获得 A 写入的最新值；而与进程 A 无因果关系的进程 C 的访问，仍然遵守一般的最终一致性规则。
「读己之所写」一致性
可以视为因果一致性的一个特例。当进程 A 自己执行一个更新操作之后，它自己总是可以访问到更新过的值，绝不会看到旧值。
会话一致性
它把访问存储系统的进程放到会话（session）的上下文中，只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话。
单调读一致性
如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
单调写一致性
系统保证来自同一个进程的写操作顺序执行。系统必须保证这种程度的一致性，否则就非常难以编程了。
“一个人可以走的很快，而一群人可以走的很远。”
我是 CoderGeshu，我们下期再见。
「分享、点赞、在看」