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

5.1 NoSQL简介

通常&＃xff0c;NoSQL数据库具有以下几个特点&＃xff1a;
&＃xff08;1&＃xff09;灵活的可扩展性
&＃xff08;2&＃xff09;灵活的数据模型
&＃xff08;3&＃xff09;与云计算紧密融合

5.2 NoSQL兴起的原因

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

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

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

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

5.3 NoSQL与关系数据库的比较

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

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

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

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

5.4 NoSQL的四大类型

NoSQL数据库虽然数量众多&＃xff0c;但是&＃xff0c;归结起来&＃xff0c;典型的NoSQL数据库通常包括键值数据库、列族数据库、文档数据库和图形数据库

键值数据库

键值数据库成为理想的缓冲层解决方案

Redis有时候会被人们称为“强化版的Memcached”
支持持久化、数据恢复、更多数据类型

列族数据库
文档数据库
“文档”其实是一个数据记录&＃xff0c;这个记录能够对包含的数据类型和内容进行“自我描述”。
XML文档、html文档和JSON 文档就属于这一类。
SequoiaDB就是使用JSON格式的文档数据库&＃xff0c;它的存储的数据是这样的&＃xff1a;
图形数据库

不同类型数据库比较分析

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

5.5 NoSQL的三大基石

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

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

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

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

BASE的基本含义是基本可用&＃xff08;Basically Available&＃xff09;、软状态&＃xff08;Soft-state&＃xff09;和最终一致性&＃xff08;Eventual consistency&＃xff09;
基本可用
是指一个分布式系统的一部分发生问题变得不可用时&＃xff0c;其他部分仍然可以正常使用&＃xff0c;即允许分区失败的情形
软状态
软状态&＃xff08;soft-state&＃xff09;”是与“硬状态&＃xff08;hard-state&＃xff09;”相对应的一种提法。数据库保存的数据是“硬状态”时&＃xff0c;可以保证数据一致性&＃xff0c;即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步&＃xff0c;滞后性
最终一致性
对于强一致性而言&＃xff0c;当执行完一次更新操作后&＃xff0c;后续的其他读操作就可以保证读到更新后的最新数据&＃xff1b;反之&＃xff0c;如果不能保证后续访问读到的都是更新后的最新数据&＃xff0c;那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例.最常见的实现最终一致性的系统是DNS

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同&＃xff0c;又可以区分为&＃xff1a;
因果一致性&＃xff1a;如果进程A通知进程B它已更新了一个数据项&＃xff0c;那么进程B的后续访问将获得A写入的最新值。而与进程A无因果关系的进程C的访问&＃xff0c;仍然遵守一般的最终一致性规则
“读己之所写”一致性&＃xff1a;可以视为因果一致性的一个特例。当进程A自己执行一个更新操作之后&＃xff0c;它自己总是可以访问到更新过的值&＃xff0c;绝不会看到旧值
单调读一致性&＃xff1a;如果进程已经看到过数据对象的某个值&＃xff0c;那么任何后续访问都不会返回在那个值之前的值

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同&＃xff0c;又可以区分为&＃xff1a;
会话一致性&＃xff1a;它把访问存储系统的进程放到会话&＃xff08;session&＃xff09;的上下文中&＃xff0c;只要会话还存在&＃xff0c;系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止&＃xff0c;就要建立新的会话&＃xff0c;而且系统保证不会延续到新的会话
单调写一致性&＃xff1a;系统保证来自同一个进程的写操作顺序执行。系统必须保证这种程度的一致性&＃xff0c;否则就非常难以编程了

如何实现各种类型的一致性&＃xff1f;
对于分布式数据系统&＃xff1a;
N — 数据复制的份数
W — 更新数据时需要保证写完成的节点数
R — 读取数据的时候需要读取的节点数
如果W&＃43;R>N&＃xff0c;写的节点和读的节点重叠&＃xff0c;则是强一致性。例如对于典型的一主一备同步复制的关系型数据库&＃xff0c;N&＃61;2,W&＃61;2,R&＃61;1&＃xff0c;则不管读的是主库还是备库的数据&＃xff0c;都是一致的。一般设定是R&＃xff0b;W &＃61; N&＃43;1&＃xff0c;这是保证强一致性的最小设定
如果W&＃43;R<&＃61;N&＃xff0c;则是弱一致性。例如对于一主一备异步复制的关系型数据库&＃xff0c;N&＃61;2,W&＃61;1,R&＃61;1&＃xff0c;则如果读的是备库&＃xff0c;就可能无法读取主库已经更新过的数据&＃xff0c;所以是弱一致性。

对于分布式系统&＃xff0c;为了保证高可用性&＃xff0c;一般设置N>&＃61;3。不同的N,W,R组合&＃xff0c;是在可用性和一致性之间取一个平衡&＃xff0c;以适应不同的应用场景。
如果N&＃61;W,R&＃61;1&＃xff0c;任何一个写节点失效&＃xff0c;都会导致写失败&＃xff0c;因此可用性会降低&＃xff0c;但是由于数据分布的N个节点是同步写入的&＃xff0c;因此可以保证强一致性。
实例&＃xff1a;HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前&＃xff0c;写操作是不会返回成功的。也就是说它的W&＃xff1d;N&＃xff0c;而读操作只需要读到一个值即可&＃xff0c;即R&＃xff1d;1。
一些系统允许用户按需要设置N&＃xff0c;R&＃xff0c;W三个值&＃xff0c;即使是设置成W&＃xff0b;R<&＃61; N也是可以的&＃xff0c;也就是说允许用户在强一致性和最终一致性之间自由选择。

5.6 小结

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

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

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

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

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