大数据技术原理与应用（第五章 NoSQL数据库）
目录
5.1 NoSQL数据库
Not only SQL特点
传统的关系型数据库特点
MySQL集群方式的缺陷
5.2 NoSQL与关系型数据库的比较
数据库原理
数据规模
数据库模式
查询效率
事务一致性
数据完整性
可用性
标准化
技术支持
可维护性
5.3 四大类型NoSQL数据库
键值数据库
数据模型
典型应用
优缺点
不适用情形
列族数据库
数据模型——列族
典型应用
优缺点
不适用情形
文档数据库
数据模型
典型应用
优缺点
不适用情形
图数据库
数据模型——图结构
典型应用
优缺点
不适用情形
5.4 NoSQL数据库的理论基石
CAP
Consistency一致性
Availability可用性
Partition tolerance分区容忍性
CA：强调一致性（C）和可用性（A），放弃分区容忍性（P）
CP：强调一致性（C）和分区容忍性（P），放弃可用性（A）
AP：强调可用性（A）和分区容忍性（P），放弃一致性（C）
BASE
BA（Basically Availble）：基本可用
S（Soft-state）：软状态
E（Eventual consistency）：最终一致性
关系型数据库事务的ACID性质
A（Atomicity）：原子性
C（Consistency）：一致性
I（Isolation）：隔离性
D（Durability）：持久性
最终一致性
因果一致性
“读己之所写”一致性
单调读一致性
会话一致性
单调写一致性
当W+R>N时，保证强一致性
当W+R≤N时，弱一致性
5.5 从NoSQL到NewSQL
数据库的发展
应用场景
NewSQL数据库
关系数据库、NoSQL、NewSQL数据库产品分类图
5.6 文档数据库MongoDB
MangoDB特点
MangoDB的概念术语与关系型数据库比较
MangoDB数据类型
5.1 NoSQL数据库
Not only SQL特点
灵活的可拓展性（相比关系型数据库可以进行水平扩展）
灵活的数据设计方案（其中基于关系型数据库遵循严格的基于关系的组织方式，而NoSQL数据库则不依赖于严格的规范约束）
和云计算紧密结合
传统的关系型数据库特点
具有完整的系统化的关系理论基础；该事务处理能力为其功能提供保障；该先进查询优化机制显著提升了数据检索与分析效率
具有完整的系统化的关系理论基础；该事务处理能力为其功能提供保障；该先进查询优化机制显著提升了数据检索与分析效率
对于海量数据的管理而言
MySQL集群方式的缺陷
复杂性，整个集群部署管理配置都非常复杂。
delay characteristic, the copying of host data typically employs asynchronous replication. Under conditions where the main database experiences significant pressure, this leads to notable delays.
扩容问题在集群面临过载压力时出现，则必须投入额外的机器资源对数据集进行全面的重新划分。
5.2 NoSQL与关系型数据库的比较
数据库原理
关系型数据库：具有完备的关系代数理论作为基础。
NoSQL数据库：没有统一的理论基础，各有规范。
数据规模
关系型数据库：很难实现横向扩展，纵向扩展非常有限。
NoSQL数据库：具有非常好的水平可扩展性。
数据库模式
关系型数据库：需建立严格的数据规范结构，并在设计阶段就充分遵循既定的数据架构设计原则
NoSQL数据库：数据模型非常灵活，可以存储不同类型的数据。
查询效率
关系型数据库：适当数据量级查询效率高，数据量级增大查询效率下降。
NoSQL数据库：未构建起面向复杂查询的索引，查询性能差。
事务一致性
关系型数据库：遵循ACID事务模型，可以保证事务强一致性。
NoSQL数据库：只能保证最终一致性，不能保证事务强一致性。
数据完整性
关系型数据库：具有保证完整性的完备机制。
NoSQL数据库：不能实现完整性约束。
可用性
关系型数据库：规模增大后，为了保证严格的一致性可用性方面会被削弱。
非一致性的数据库系统（NoSQL数据库）：放弃了一定的一致性，在短时间内快速检索所需数据，并表现出较高的可用性水平。
标准化
关系型数据库：遵循SQL标准，标准化比较完善。
NoSQL数据库：未形成通用的行业标准。
技术支持
关系型数据库：大量应用于商业环境中的数据库系统通常能够提供可靠的技术保障和专业的后续支持服务。
NoSQL数据库：很多属于开源产品，处于整个发展的初期阶段。
可维护性
关系型数据库：需要管理员维护。
NoSQL数据库：没有成熟的基础和实践操作规范，维护较为复杂。
5.3 四大类型NoSQL数据库
键值数据库
数据模型
标识符代表一个字符串对象；其值可为多种不同数据类型的实例。例如基本数据类型如integer；而像array、list以及set等复杂结构也可作为其值的存储空间
典型应用
包含频繁读写操作且采用简单数据模型的应用程序中存在大量缓存内容包括会话信息配置文件参数列表以及用于存储配置信息和用户数据的移动应用
优缺点
具备良好的扩展性，并且具有高度的灵活性；该系统不具备存储非结构化数据的能力，并且条件查询的效率相对较低（仅能基于键来定位对应的数据项，并不支持直接对数据值进行检索）
不适用情形
键值数据库不支持基于值查询的方式；无法使用两个或多个键来关联数据；某些键值数据库在发生故障时无法回滚。
键值数据库是理想的缓冲层解决方案。
列族数据库
数据模型——列族
典型应用
分布式的数据存储和管理；分布在多个数据中心的应用程序；能够容忍短暂的一致性差异的应用程序；拥有可变字段的应用程序
优缺点
该系统在性能方面表现出色：其查找效率高、具备良好的扩展性，并且适合分布式架构设计。然而，在功能性方面存在一定的局限性：多数功能模块均不支持严格的事务一致性。
不适用情形
需要ACID事务支持的情形时某些产品不适用。
文档数据库
数据模型
JSON数据格式，本质上就是一个键值数据库，不够值Value是版本化文档。
典型应用
存储、索引并管理面向文档的数据；或者类似的半结构化数据。
优缺点
该系统具备以下特点：能够内部展示其数据内容和类型信息；一个文档内部即可完整整合所有相关信息；并行更新时仅需锁定一个文档即可实现相关数据修改；该系统支持嵌入式功能，并集成了频繁访问的数据资源到同一份文件中；同时该系统还存在缺少统一的查询语法表达方式的问题。
不适用情形
文档数据库不支持文档间的事务。
图数据库
数据模型——图结构
典型应用
专门用于处理具有高度相互关联关系的数据；这类方法主要针对社交平台上的互动行为分析以及模式识别技术的应用场景，并且特别适用于依赖关系分析、推荐系统应用和路径规划问题等复杂数据关联性分析的场景。
优缺点
该系统具备高度的适应性，并能够处理复杂的图形算法；通过该系统可以构建出较为复杂的关联关系图谱。由于其对数据类型的适用范围极为有限
不适用情形
关联性差的数据。
5.4 NoSQL数据库的理论基石
CAP
Consistency一致性
指任何一个读操作总能读到之前完成的写操作结果。
Availability可用性
表示该系统能够迅速获取数据，并在指定时间内完成操作并返回结果；确保不论请求成功还是失败都会做出回应。
Partition tolerance分区容忍性
当出现网络分隔的情况时（即部分节点无法与其他节点通信），被隔离的部分仍能保持稳定运行状态。
一个分布式系统无法同时具备一致性、可用性和容错性
CA ：强调一致性（C）和可用性（A），放弃分区容忍性（P）
基本的方法是将所有与事务相关的内容放置于一台机器中。这一做法严重制约了系统的可扩展现状。主流的关系型数据库（MySQL、SQL Server和PostgreSQL）均遵循了这一设计理念，并由此导致了系统扩展性的不足。
CP ：强调一致性（C）和分区容忍性（P），放弃可用性（A）
当网络分区发生时，在受到影响的服务中存在必须保持数据一致性的情况；因此，在等待期间内该服务将无法对外提供任何服务**。
AP ：强调可用性（A）和分区容忍性（P），放弃一致性（C）
允许系统返回不一致的数据。
BASE
BASE由Basically Avaible Soft state和Eventual consistency两个概念的缩写组成,俗称'碱'。在NoSQL数据库领域中,BASE（即'碱'）与传统的关系型数据库中的事务特性（ACID）存在一一对应的关系。
BA（Basically Availble）：基本可用
当某个分布式系统的部分出现故障无法访问时（即），其余部分仍可正常运行（这相当于允许系统分区失败的情况得以容忍）。
S（Soft-state）：软状态
在数据库领域中，“软态（soft-state）”这一概念与之相对应的是“硬态（hard-state）”。当数据库中的数据处于"硬态"状态下时，则能够确保数据的一致性和完整性；即无论何时都能获得准确无误的数据信息。“软态"则表征了一种延后效应的状态特征，在一定程度上存在暂时性的不一致现象。
E（Eventual consistency）：最终一致性
一致性的类型主要分为强一致性与弱一致性两种。其核心区别在于，在面对高强度的数据访问操作时，后续的操作能否及时获取到最新更新的数据信息。在强一致性模式下，在完成一次更新操作后，默认情况下后续的所有读取操作都能保证获得最新的数据版本；而若这些后续读取操作无法持续获得最新的数据，则体现为弱一致性的情况。
其中最终一致性作为一种特殊的弱一致性模式，在这种情况下允许后续的操作暂时无法获取最新的数据值。
DNS系统通常被认为是实现最终一致性的最常用方案之一。当一个域名发生更新时，
该更新信息会被按照预设的形式传播至相关服务器，
并借助过期机制进行缓存管理；
这样做的结果是使得所有客户端都能够及时获取最新的域名值。
关系型数据库事务的ACID性质
A（Atomicity）：原子性
遵循事务操作必须遵循原子性原则，在对其数据进行修改时，则要求要么全部成功完成，要么全部失败而不成功
C（Consistency）：一致性
指事务在完成时，必须使所有的数据都保持一致状态。
I（Isolation）：隔离性
指由并发事务所做的修改必须与任何其它并发事务所做的修改隔离。
D（Durability）：持久性
在事务完成后，在系统中实施此修改将导致其具有永久性的影响；即使发生严重故障此类修改也会持续存在。
最终一致性
基于更新后的数据中各进程访问到数据的时间及方式的不同，则可将其划分为以下三种情况：
因果一致性
如果一个进程A向进程B发送了一个通知，并且该通知中包含了一个数据项已经被更新的信息，则任何随后针对该数据项进行的操作都会基于最新的修改值进行处理。而对于那些与进程中没有因果关系的其他进程C而言，则会依照通常的一致性原则执行操作。
“读己之所写”一致性
在因果一致性框架下作为一个特殊情况出现，在进程A自身执行一次更新操作时，在本地缓存中不会有旧数据残留于其本地缓存中。
单调读一致性
如果一个进程已经观察到了数据对象中的某个特定值，则在后续操作中不会返回比该值更早的结果。
会话一致性
该方法将访问存储系统的进程放置于 session 的上下文中；只要 session 连续进行中，则系统确保‘读己所书’一致性。若因某些故障导致 session 结束，则需创建新的 session，并且系统将阻止其延伸至后续的 session.
单调写一致性
该系统必须确保同一进程内的所有写操作按照指定顺序执行。如果无法维持这种程度的一致性，则将导致编程变得极为复杂。
对于分布式数据系统，如何实现各种类型的一致性？
N — 数据复制的份数
W — 更新数据是需要保证写完成的节点数
R — 读取数据的时候需要读取的节点数
当W+R>N时，保证强一致性
在分布式系统中，在写相关的节点与读相关的节点存在重叠时，则表示该系统满足强一致性特性。例如，在典型的基于主从复制模式的关系型数据库系统中，默认配置参数设置为N=2、W=2、R=1，则无论从主库还是从备库中进行数据读取操作时所获取的数据都是高度一致的。其中规定R加W等于N加一（即R＋W = N+1），这也是确保强一致性达到最低要求的标准配置。
当W+R≤N时，弱一致性
举例而言，在关系型数据库中采用一主一备异步复制策略时，若参数设置为N=2, W=1, R=1，则当读取备用库时（即在备用库发生更新后），将导致无法获取主库已更新的数据，并因此成为弱一致性。
对于分布式系统来说，在确保系统的高可用性方面通常建议将N设为3及以上。不同配置的参数组合（如N,W,R）需要在可扩展性和一致性的平衡中选择合适的配置方案，以便满足各种应用场景的需求。
当 N=W 且 R=1 时，在分布式系统中，默认的数据分布假设通常是同步 write 的机制。任何单个 writes 节点故障都会导致 write 失败的发生，并最终影响系统的 availability 会受到影响。然而，在分布式系统中，默认的数据分布假设通常是同步 write 的机制。在这种情况下虽然可能会导致 write 失败但通过同步的方式来实现数据的一致性从而确保 strong consistency 可靠性的前提下尽可能减少对系统性能的影响。
基于其底层架构,HBase通过HDFS实现了对数据冗余备份的支持。在遵循强一致性机制下,HDFS确保了对分布式文件存储的安全性。当系统中各节点尚未完成全节点同步时,写入操作将不会返回成功结果。具体而言,该系统的强一致性和弱一致性特性表现在:当系统处于全节点同步状态时,读操作可获取任意一个副本的数据（即R=1）;而当系统未完成全节点同步时,写入操作无法获得成功反馈（即W=N）。
5.5 从NoSQL到NewSQL
数据库的发展
应用场景
分析型应用：NewSQL
事务型应用：OldSQL
互联网应用：NoSQL
NewSQL数据库
NewSQL数据库集成了OldSQL和NoSQL数据库各自的优势，在遵循关系数据模型的基础上实现了强的一致性和事务完整性，并能够高效地执行各种类型的查询操作；该系统还展现出良好的水平扩展能力，并具备处理海量数据的能力。
关系数据库、NoSQL、NewSQL数据库产品分类图
5.6 文档数据库MongoDB
MangoDB采用C++语言开发, 是一个基于分布式文件存储的开源数据库系统. 该系统将数据以文档形式存储, 其中每个文档由键值对（key-value）构成. 每个字段值不仅支持嵌套文档和其他类型的数据, 还可包含数组以及这些数组类型的文档集合. 在处理高负载场景时, 可通过增加节点数量来提升服务器性能. 这种设计旨在为Web应用提供高性能且可扩展的数据存储解决方案.
MangoDB特点
提供了一个面向文档的存储模式，相对关系型数据库操作简单；
可以设置任何属性的索引，实现更快的排序与查询（相对键值数据库）；
具有较好的水平可扩展性；
支持丰富的查询表达式，可以查询文档中内嵌的对象及数组；
可以直接替换已完成文档中某个指定的数据字段；
可以利用MapReduce对数据进行批量处理和聚合操作；
支持各种编程语言：RUBY，PYTHON，JAVA，C++，PHP，C#等语言。
MangoDB的概念术语与关系型数据库比较
集合本质上是MongoDB中组织在一起的文档集合，在结构上与关系型数据库中的表相仿；作为非关系型数据库的一种核心结构体，集合无需预先定义固定的查询结果格式或返回值数量。它能够灵活存储包括文本、数字、嵌入式对象等多种数据类型，并通过内置的聚合操作规避了传统关系型数据库的复杂联结问题。
MangoDB数据类型
| String | 字符串。存储数据常用的数据类型。在 MongoDB 中，UTF-8 编码的字符串才是合法的。 |
|---|---|
| Integer | 整型数值。用于存储数值。根据你所采用的服务器，可分为 32 位或 64 位。 |
| Boolean | 布尔值。用于存储布尔值（真/假）。 |
| Double | 双精度浮点值。用于存储浮点值。 |
| Min/Max keys | 将一个值与 BSON（二进制的 JSON）元素的最低值和最高值相对比。 |
| Arrays | 用于将数组或列表或多个值存储为一个键。 |
| Timestamp | 时间戳。记录文档修改或添加的具体时间。 |
| Object | 用于内嵌文档。 |
| Null | 用于创建空值。 |
| Symbol | 符号。该数据类型基本上等同于字符串类型，但不同的是，它一般用于采用特殊符号类型的语言。 |
| Date | 日期时间。用 UNIX 时间格式来存储当前日期或时间。你可以指定自己的日期时间：创建 Date 对象，传入年月日信息。 |
| Object ID | 对象 ID。用于创建文档的 ID。 |
| Binary Data | 二进制数据。用于存储二进制数据。 |
| Code | 代码类型。用于在文档中存储 JavaScript 代码。 |
| Regular expression | 正则表达式类型。用于存储正则表达式。 |