目录
5.1 NoSQL数据库
Not only SQL特点
灵活的可拓展性(相比关系型数据库可以进行水平扩展)
灵活的数据模型(关系型数据库行列遵循严格的关系代数关系,NoSQL则没有严格的模型规范)
和云计算紧密结合
传统的关系型数据库特点
具有非常完备的关系理论基础;具有事务性机制的支持;具有高效的查询优化机制。
无法满足海量数据的管理需求;无法满足高并发的需求;无法满足高可扩展性和高可用性的需求。
MySQL集群方式的缺陷
复杂性,整个集群部署管理配置都非常复杂。
延迟性,主机数据的复制一般采用异步方式,当主库压力较大时,就会带来较大的延迟。
扩容问题,整个集群压力过大时,需要增加新机器对整个数据集进行重新分区,非常复杂。
5.2 NoSQL与关系型数据库的比较
数据库原理
关系型数据库:具有完备的关系代数理论作为基础。
NoSQL数据库:没有统一的理论基础,各有规范。
数据规模
关系型数据库:很难实现横向扩展,纵向扩展非常有限。
NoSQL数据库:具有非常好的水平可扩展性。
数据库模式
关系型数据库:要定义严格的数据库模式,且严格遵守事先定义的数据库模式。
NoSQL数据库:数据模型非常灵活,可以存储不同类型的数据。
查询效率
关系型数据库:适当数据量级查询效率高,数据量级增大查询效率下降。
NoSQL数据库:未构建起面向复杂查询的索引,查询性能差。
事务一致性
关系型数据库:遵循ACID事务模型,可以保证事务强一致性。
NoSQL数据库:只能保证最终一致性,不能保证事务强一致性。
数据完整性
关系型数据库:具有保证完整性的完备机制。
NoSQL数据库:不能实现完整性约束。
可用性
关系型数据库:规模增大后,为了保证严格的一致性可用性方面会被削弱。
NoSQL数据库:牺牲一部分一致性,能够在短时间内迅速返回所需的结果,具有很好的可用性。
标准化
关系型数据库:遵循SQL标准,标准化比较完善。
NoSQL数据库:未形成通用的行业标准。
技术支持
关系型数据库:很多都是商业数据库,可以获得非常强大的技术和后续服务支持。
NoSQL数据库:很多属于开源产品,处于整个发展的初期阶段。
可维护性
关系型数据库:需要管理员维护。
NoSQL数据库:没有成熟的基础和实践操作规范,维护较为复杂。
5.3 四大类型NoSQL数据库
键值数据库
数据模型
键是一个字符串对象,值可以是任意类型的数据,比如整型,数组,列表,集合等等。
典型应用
涉及频繁读写、拥有简单数据模型的应用,内容缓存,如会话、配置文件、参数、购物车等,存储配置和用户数据信息等移动应用。
优缺点
扩展性好,灵活性好,写操作性能非常高;无法存储结构化信息,条件查询效率较低(必须通过key才能找到对应的值,无法直接对值进行查询)。
不适用情形
键值数据库没有通过值查询的途径;不能通过两个或两个以上的键来关联数据;在一些键值数据库中,产生故障时,不能回滚。
键值数据库是理想的缓冲层解决方案。
列族数据库
数据模型——列族
典型应用
分布式数据存储与管理;数据在地理上分布于多个数据中心的应用程序;可以容忍副本中存在短期不一致情况的应用程序;拥有动态字段的应用程序。
优缺点
查找速度快、可扩展性强、容易进行分布式扩展、复杂性低;功能较少,大都不支持强事务一致性
不适用情形
需要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它已更新了一个数据项,那么进程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。
5.5 从NoSQL到NewSQL
数据库的发展
应用场景
分析型应用:NewSQL
事务型应用:OldSQL
互联网应用:NoSQL
NewSQL数据库
NewSQL数据库同时具备OldSQL和NoSQL数据库各自的优点,基于关系数据模型保证了强一致性,事务一致性,支持SQL查询,同时具有很好的水平可扩展性,支持海量的数据存储。
关系数据库、NoSQL、NewSQL数据库产品分类图
5.6 文档数据库MongoDB
MangoDB是由C++语言编写的,一个基于分布式文件存储的开源数据库系统。MangoDB将数据存储为一个文档,数据结构由键值(key=>value)对组成,BSON: binary类型JSON对象。字段值可以包含其他文档,数组以及文档数组。在高负载的情况下,可以添加更多的节点以保证服务器的性能,旨在为WEB应用提供可扩展的高性能数据存储解决方案。
MangoDB特点
提供了一个面向文档的存储模式,相对关系型数据库操作简单;
可以设置任何属性的索引,实现更快的排序与查询(相对键值数据库);
具有较好的水平可扩展性;
支持丰富的查询表达式,可以查询文档中内嵌的对象及数组;
可以直接替换已完成文档中某个指定的数据字段;
可以利用MapReduce对数据进行批量处理和聚合操作;
MangoDB的概念术语与关系型数据库比较
集合就是Mongo文档组,类似于RDBMS中的表格;集合存在于数据库中,没有固定的结果,可插入不同格式和类型的数据,从而避免关系型数据库中的跨表连接。
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 | 正则表达式类型。用于存储正则表达式。 |