大数据技术原理与应用——NoSQL数据库
5.1 NoSQL 简介
特点
1.灵活的可扩展性
传统的关系型数据库由于自身设计机理的原因,通常很难实现“横向扩展”,在面对数据库负载大规模增加时,往往需要通过升级硬件来实现“纵向扩展”。但是,当前的计算机硬件制造工艺已经达到一个限度,性能提升的速度开始趋缓,已经远远赶不上数据库系统负载的增加速度,而且配置高端的高性能服务器价格不菲,因此寄希望于通过“纵向扩展”满足实际业务需求,已经变得越来越不现实。相反,“横向扩展”仅需要非常普通廉价的标准化刀片服务器,不仅具有较高的性价比,也提供了理论上近乎无限的扩展空间。NoSQL 数据库在设计之初就是为了满足“横向扩展”的需求,因此天生具备良好的水平扩展能力。
2.灵活的数据模型
关系模型是关系数据库的基石,它以完备的关系代数理论为基础,具有规范的定义,遵守各种严格的约束条件。这种做法虽然保证了业务系统对数据一致性的需求,但是过于死板的数据模型,也意味着无法满足各种新兴的业务需求。相反,NoSQL 数据库天生就旨在摆脱关系数据库的各种束缚条件,摈弃了流行多年的关系数据模型,转而采用键/值、列族等非关系模型,允许在一个数据元素里存储不同类型的数据。
3.与云计算紧密融合
云计算具有很好的水平扩展能力,可以根据资源使用情况进行自由伸缩,各种资源可以动态加入或退出,NoSQL 数据库可以凭借自身良好的横向扩展能力,充分自由利用云计算基础设施,很好地融入到云计算环境中,构建基于 NoSQL 的云数据库服务。
5.2 NoSQL 兴起的原因
5.2.1 关系数据库无法满足 Web 2.0 的需求
传统的关系数据库性能上缺陷
无法满足海量数据的管理需求
到了 Web 2.0 时代以后,数据的产生速度非常快
无法满足高并发的需求
在 Web 1.0 时代,通常采用动态页面静态化的技术,事先访问数据库生成静态页面供浏览者访问,从而保证在大规模用户访问时,也能够获得较好的实时响应性能。但是,在 Web 2.0 时代,各种用户都在不断地发生更新,购物记录、搜索记录、微博粉丝数等信息都需要实时更新,动态页面静态化技术基本没有用武之地,所有信息都需要动态实时生成,这就会导致高并发的数据库访问,可能产生每秒上万次的读写请求,对于很多关系数据库而言,这都是“难以承受之重”。
无法满足高扩展性和高可用性的需求
在 Web 2.0 时代,不知名的网站可能一夜爆红,用户迅速增加,已经广为人知的网站也可能因为发布了热门吸引眼球的信息,引来大量用户在短时间内围绕该信息大量交流互动,这些都会导致对数据库读写负荷的急剧增加,需要数据库能够在短时间内迅速提升性能应对突发需求。但是,遗憾的是,关系数据库通常是难以水平扩展的,没有办法像网页服务器和应用服务器那样简单地通过添加更多的硬件和服务节点来扩展性能和负载能力。
5.2.2 关系数据库的关键特性在 Web 2.0 时代成为“鸡肋”
5.3 NoSQL 与关系数据库的比较
一、在数据库原理方面
二、在数据规模方面
三、在数据库模式方面
四、在查询效率方面
五、在事务一致性方面
六、在数据完整性方面
七、在可扩展性方面
八、在可用性方面
九、在标准化方面
十、在技术支持方面
十一、在可维护方面
关系数据库的优势
1.具有非常完备的关系代数理论作为基础
2.有严格的标准
3.支持事务一致性
4.可以借助索引机制实现非常高效的查询
关系数据库的劣势
1.可扩展性非常差
2.不具备水平可扩展性,无法较好支持海量数据存储
3.数据模型定义严格,无法较好满足新型 Web 2.0 应用需求
NoSQL 数据库的优势
1.支持超大规模的数据存储
2.数据模型非常灵活
NoSQL 数据库的劣势
1.缺乏底层基础理论做支撑
2.很多 NoSQL 数据库都不支持事务的强一致性
两种数据库的应用场景
实际上,在企业应用当中,有些企业都市采用混合应用架构,一个企业中可以同时用两种不同类型的数据库产品,如亚马逊公司,其内部就使用不同的数据库去支持电子商务的应用,比如,对购物篮,临时性的数据一般采用键值存储,键值存储对简单的数据模型效率是非常高的;而对于产品订单信息,一般会把它放在关系数据库当中,因为这属于企业的关键业务应用,是绝对不能丢失的;而当企业需要做分析时,它会把很多历史的订单信息放到现在比较流行的叫文档数据库 MongoDB 中。
对于一个企业来讲,实际上都是成混合型架构,在这么多的产品当中选择一些能够满足他们不同需求的产品,形成组合型应用。
5.4 NoSQL 的四大类型
5.4.1 键值数据库
键值数据库成为理想的缓冲层解决方案
我们很多基于外部的开发,外面浏览器去访问我们底层的网页的时候,网页需要去访问底层数据库,你若这样一次又一次地去查询,直接去访问底层的磁盘数据库的时候,性能是很低的,所以,一般企业在应用的时候,都会在底层的数据库之上构建一个缓冲层,缓冲层一般是用键值数据库去做缓冲的。
5.4.2 列族数据库
5.4.3 文档数据库
是最像关系数据库的,是介于关系数据库和 NoSQL 数据库之间的一种数据库,一般也会把它归到 NoSQL 数据库。
5.4.4 图数据库
5.5 NoSQL 的三大基石
5.5.1 CAP
一个分布式系统不可能同时满足一致性、可用性和分区容忍性这三个需求,最多只能同时满足其中两个,正所谓“鱼和熊掌不可兼得”
下面给出牺牲一致性来换取可用性的实例。假设分布式环境下存在两个节点 M1 和 M2 ,一个数据 V 的两个副本 V1 和 V2 分别保存在 M1 和 M2 上,两个副本的值都是 val0,现在假设有两个进程 P1 和 P2 分别对两个副本进行操作,进程 P1 向节点 M1 中的副本 V1 写入新值 val1,进程 P2 从节点 M2 中读取 V 的副本 V2 的值。
当整个过程完全正常执行时,会按照以下过程进行。
(1)进程 P1 向节点 M1 的副本 V1 写入新值 val1。
(2)节点 M1 向节点 M2 发送消息 MSG 以更新副本 V2 值,把副本 V2 值更新为 val1。
(3)进程 P2 在节点 M2 中读取副本 V2 的新值 val1。
但是当网络发生故障时,可能导致节点 M1 中的消息 MSG 无法发送到节点 M2,这时,进程 P2 在节点 M2 中读取到的副本 V2 的值仍然是旧值 val0。因此产生了不一致性的问题。
从这个实例可以看出,当我们希望两个进程 P1 和 P2 都实现高可用性,也就是能够快速访问到需要的数据时,就会牺牲数据一致性。
在面对 CAP 问题有以下几种选择
(1)CA。也就是强调一致性(C)和可用性(A),放弃分区容忍性(P),最简单的做法是把所有与事务相关地内容放到同一台机器上。很显然,这种做法会严重影响系统的可扩展性。传统的关系数据库(MySQL、SQL Server 和 PostgreSQL)都采用了这种设计原则,因此可扩展性都比较差。
(2)CP。也就是强调一致性(C)和分区容忍性(P),放弃可用性(A),当出现网络分区的情况时,受影响的服务器需要等待数据一致,因此在等待期间就无法对外提供服务。Neo4J、BigTable 和 HBase 等 NoSQL 数据库都采用了 CP 设计原则。
(3)AP。也就是强调可用性(A)和分区容忍性(P),放弃一致性(C),允许系统返回不一致的数据。这对于许多 Web 2.0 网站而言是可行的,这些网站的用户首先关注的是网站服务是否可用,当用户需要发布一条微博时,必须能够立即发布,否则,用户就会放弃使用,但是这条微博发布后什么时候能够被其他用户读取到,则不是非常重要的问题,不会影响到用户体验。因此,对于 Web 2.0 网站而言,可用性与分区容忍性优先级要高于数据一致性,网站一般会尽量朝着 AP 的方向设计。当然,在采用 AP 设计时,也可以不完全放弃一致性,转而采用最终一致性。Dynamo、Riak、CouchDB、Cassandrd 等 NoSQL 数据库就采用了 AP 设计原则。
5.5.2 BASE
5.5.3 最终一致性
根据更新数据后各进程访问到数据的时间和方式的不同,可以区分为
如何实现各种类型的一致性
假设有一个分布式系统
为了实现它的可靠性,要对数据进行冗余存储
N=2:一主一从,一个数据有一模一样的两份复制
W=2:表示同步复制,当数据写到主服务器中,只有它被更新到从服务器,写才能成功返回(必须要写入这两个副本,才能成功返回)
R=1:只要读取其中一个就能马上返回
R=1 指从其中任何一个读完就走,这时就可能会出现不一致,因为在写操作时,写完主服务器就走掉了,如果这个时候更新没有传到从服务器,马上去读从服务器,读到的数据肯定是旧的,就不一致了。
对于 HBase 数据库来讲
HBase 是借助底层的 HDFS 来实现其数据冗余备份
HDFS 采用强一致性,在数据未完全同步到 N 个节点前,写操作不会成功返回也就是说当 W=N,而读操作只需要读到一个值即可也就是说 R=1
5.6 从 NoSQL 到 NewSQL 数据库
数据库的发展
应用场景
NewSQL 数据库
NewSQL 同时具备 OldSQL 数据库和 NoSQL 数据库各自的优点
文档数据库 MongoDB
MongoDB 简介
MongoDB特点
MongoDB 的概念解析——概念术语
实例
关系型数据库设计实例
实例
关系数据库其中一条记录在文档数据库 MongoDB 中存储方式如下
数据库
文档
一个简单的文档例子如下
RDBMS 与 MongoDB 对应的术语
集合
安装 MongoDB
使用 MongoDB shell 访问 MongoDB
使用 Java 程序访问 MongoDB
(1)环境配置
(2)连接数据库
(3)创建集合
(4)插入文档