大数据技术基础笔记5 NoSQL数据库

5.1 NoSQL简介

在这里插入图片描述通常,NoSQL数据库具有以下几个特点:
(1)灵活的可扩展性
(2)灵活的数据模型
(3)与云计算紧密融合

5.2 NoSQL兴起的原因

关系数据库已经无法满足Web2.0的需求。主要表现在以下几个方面:
(1)无法满足海量数据的管理需求
(2)无法满足数据高并发的需求
(3)无法满足高可扩展性和高可用性的需求

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

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

关系数据库的关键特性包括完善的事务机制和高效的查询机制。但是,关系数据库引以为傲的两个关键特性,到了Web2.0时代却成了鸡肋,主要表现在以下几个方面:
(1)Web2.0网站系统通常不要求严格的数据库事务
(2)Web2.0并不要求严格的读写实时性
(3)Web2.0通常不包含大量复杂的SQL查询(去结构化,存储空间换取更好的查询性能)

5.3 NoSQL与关系数据库的比较

在这里插入图片描述在这里插入图片描述在这里插入图片描述
关系数据库
优势:以完善的关系代数理论作为基础,有严格的标准,支持事务ACID四性,借助索引机制可以实现高效的查询,技术成熟,有专业公司的技术支持
劣势:可扩展性较差,无法较好支持海量数据存储,数据模型过于死板、无法较好支持Web2.0应用,事务机制影响了系统的整体性能等

NoSQL数据库
优势:可以支持超大规模数据存储,灵活的数据模型可以很好地支持Web2.0应用,具有强大的横向扩展能力等
劣势:缺乏数学理论基础,复杂查询性能不高,大都不能实现事务强一致性,很难实现数据完整性,技术尚不成熟,缺乏专业团队的技术支持,维护较困难等

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

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

5.4 NoSQL的四大类型

NoSQL数据库虽然数量众多,但是,归结起来,典型的NoSQL数据库通常包括键值数据库、列族数据库、文档数据库和图形数据库
在这里插入图片描述在这里插入图片描述在这里插入图片描述
键值数据库

在这里插入图片描述键值数据库成为理想的缓冲层解决方案
在这里插入图片描述
Redis有时候会被人们称为“强化版的Memcached”
支持持久化、数据恢复、更多数据类型

列族数据库
在这里插入图片描述文档数据库
“文档”其实是一个数据记录,这个记录能够对包含的数据类型和内容进行“自我描述”。
XML文档、HTML文档和JSON 文档就属于这一类。
SequoiaDB就是使用JSON格式的文档数据库,它的存储的数据是这样的:
在这里插入图片描述在这里插入图片描述图形数据库

在这里插入图片描述不同类型数据库比较分析
在这里插入图片描述
数据库产品比较:
MySQL产生年代较早,尽管其没有什么大的改进,但是新兴的互联网使用的最多的数据库
MongoDB是个新生事物,提供更灵活的数据模型、异步提交、地理位置索引等五花十色的功能
HBase是个“仗势欺人”的大象兵。依仗着Hadoop的生态环境,可以有很好的扩展性,需要Hadoop才能驱使他
Redis是键值存储的代表,提供随机数据存储,功能最简单

5.5 NoSQL的三大基石

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

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

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

说起BASE(Basically Availble, Soft-state, Eventual consistency),不得不谈到ACID。
在这里插入图片描述一个数据库事务具有ACID四性:
A(Atomicity)原子性:是指事务必须是原子工作单元,对于其数据修改,要么全都执行,要么全都不执行
C(Consistency)一致性:是指事务在完成时,必须使所有的数据都保持一致状态
I(Isolation)隔离性:是指由并发事务所做的修改必须与任何其它并发事务所做的修改隔离
D(Durability)持久性:是指事务完成之后,它对于系统的影响是永久性的,该修改即使出现致命的系统故障也将一直保持

BASE的基本含义是基本可用(Basically Available)、软状态(Soft-state)和最终一致性(Eventual consistency)
基本可用
是指一个分布式系统的一部分发生问题变得不可用时,其他部分仍然可以正常使用,即允许分区失败的情形
软状态
软状态(soft-state)”是与“硬状态(hard-state)”相对应的一种提法。数据库保存的数据是“硬状态”时,可以保证数据一致性,即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步,滞后性
最终一致性
对于强一致性而言,当执行完一次更新操作后,后续的其他读操作就可以保证读到更新后的最新数据;反之,如果不能保证后续访问读到的都是更新后的最新数据,那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例.最常见的实现最终一致性的系统是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。
一些系统允许用户按需要设置N,R,W三个值,即使是设置成W+R<= N也是可以的,也就是说允许用户在强一致性和最终一致性之间自由选择。

5.6 小结

本章介绍了NoSQL数据库的相关知识

NoSQL数据库较好地满足了大数据时代的各种非结构化数据的存储需求,开始得到越来越广泛的应用。但是,需要指出的是,传统的关系数据库和NoSQL数据库各有所长,彼此都有各自的市场空间,不存在一方完全取代另一方的问题,在很长的一段时期内,二者都会共同存在,满足不同应用的差异化需求

NoSQL数据库主要包括键值数据库、列族数据库、文档型数据库和图形数据库等四种类型,不同产品都有各自的应用场合。CAP、BASE和最终一致性是NoSQL数据库的三大理论基石,是理解NoSQL数据库的基础

介绍了融合传统关系数据库和NoSQL优点的NewSQL数据库

本章最后介绍了具有代表性的NoSQL数据库——文档数据库MongoDB

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
关系型数据库NoSQL数据库 什么是NoSQL 大家有没有听说过“NoSQL”呢?近年,这个词极受关注。看到“NoSQL”这个词,大家可能会误以为是“No!SQL”的缩写,并深感愤怒:“SQL怎么会没有必要了呢?”但实际上,它是“Not Only SQL”的缩写。它的意义是:适用关系型数据库的时候就使用关系型数据库,不适用的时候也没有必要非使用关系型数据库不可,可以考虑使用更加合适的数据存储。 为弥补关系型数据库的不足,各种各样的NoSQL数据库应运而生。 为了更好地了解本书所介绍的NoSQL数据库,对关系型数据库的理解是必不可少的。那么,就让我们先来看一看关系型数据库的历史、分类和特征吧。 关系型数据库简史 1969年,埃德加•弗兰克•科德(Edgar Frank Codd)发表了划时代的论文,首次提出了关系数据模型的概念。但可惜的是,刊登论文的《IBM Research Report》只是IBM公司的内部刊物,因此论文反响平平。1970年,他再次在刊物《Communication of the ACM》上发表了题为“A Relational Model of Data for Large Shared Data banks”(大型共享数据库的关系模型)的论文,终于引起了大家的关注。 科德所提出的关系数据模型的概念成为了现今关系型数据库基础。当时的关系型数据库由于硬件性能低劣、处理速度过慢而迟迟没有得到实际应用。但之后随着硬件性能的提升,加之使用简单、性能优越等优点,关系型数据库得到了广泛的应用。 通用性及高性能 虽然本书是讲解NoSQL数据库的,但有一个重要的大前提,请大家一定不要误解。这个大前提就是“关系型数据库的性能绝对不低,它具有非常好的通用性和非常高的性能”。毫无疑问,对于绝大多数的应用来说它都是最有效的解决方案。 突出的优势 关系型数据库作为应用广泛的通用型数据库,它的突出优势主要有以下几点: 保持数据的一致性(事务处理) 由于以标准化为前提,数据更新的开销很小(相同的字段基本上都只有一处) 可以进行JOIN等复杂查询 存在很多实际成果和专业技术信息(成熟的技术) 这其中,能够保持数据的一致性是关系型数据库的最大优势。在需要严格保证数据一致性和处理完整性的情况下,用关系型数据库是肯定没有错的。但是有些情况不需要JOIN,对上述关系型数据库的优点也没有什么特别需要,这时似乎也就没有必要拘泥于关系型数据库了。 关系型数据库的不足 不擅长的处理 就像之前提到的那样,关系型数据库的性能非常高。但是它毕竟是一个通用型的数据库,并不能完全适应所有的用途。具体来说它并不擅长以下处理: 大量数据的写入处理 为有数据更新的表做索引或表结构(schema)变更 字段不固定时应用 对简单查询需要快速返回结果的处理 。。。。。。 NoSQL数据库 为了弥补关系型数据库的不足(特别是最近几年),NoSQL数据库出现了。关系型数据库应用广泛,能进行事务处理和JOIN等复杂处理。相对地,NoSQL数据库只应用在特定领域,基本上不进行复杂的处理,但它恰恰弥补了之前所列举的关系型数据库的不足之处。 易于数据的分散 如前所述,关系型数据库并不擅长大量数据的写入处理。原本关系型数据库就是以JOIN为前提的,就是说,各个数据之间存在关联是关系型数据库得名的主要原因。为了进行JOIN处理,关系型数据库不得不把数据存储在同一个服务器内,这不利于数据的分散。相反,NoSQL数据库原本就不支持JOIN处理,各个数据都是独立设计的,很容易把数据分散到多个服务器上。由于数据被分散到了多个服务器上,减少了每个服务器上的数据量,即使要进行大量数据的写入操作,处理起来也更加容易。同理,数据的读入操作当然也同样容易。 提升性能和增大规模 下面说一点题外话,如果想要使服务器能够轻松地处理更大量的数据,那么只有两个选择:一是提升性能,二是增大规模。下面我们来整理一下这两者的不同。 首先,提升性能指的就是通过提升现行服务器自身的性能来提高处理能力。这是非常简单的方法,程序方面也不需要进行变更,但需要一些费用。若要购买性能翻倍的服务器,需要花费的资金往往不只是原来的2倍,可能需要多达5到10倍。这种方法虽然简单,但是成本较高。 另一方面,增大规模指的是使用多台廉价的服务器来提高处理能力。它需要对程序进行变更,但由于使用廉价的服务器,可以控制成本。另外,以后只要依葫芦画瓢增加廉价服务器的数量就可以了。 不对大量数据进行处理的话就没有使用的必要吗? NoSQL数据库基本上来说为了“使大量数据的写入处理更加容易(让增加服务器数量更容易)”而设计的。但如果不是对大量数据进行操作的话,NoSQ

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值