赞
踩
NoSQL是一种不同于关系数据库的数据库管理系统设计方式,是对非关系型数据库的统称,它所采用的数据模型并非传统关系数据库的关系模型,而是类似键值、列族、文档等非关系模型。NoSQL数据库没有固定的表结构,通常也不存在连接操作,也没有严格遵守ACID约束。因此,与关系数据库相比,NoSQL具有灵活的水平可扩展性,可以支持海量数据存储。此外,NoSQL数据库支持MapReduce风格的编程,可以较好地应用于大数据时代的各种数据管理。NoSQL 数据库的出现,一方面弥补了关系数据库在当前商业应用中存在的各种缺陷,另一方面也撼动了关系数据库的传统垄断地位。当应用场合需要简单的数据模型、灵活性的IT系统、较高的数据库性能和较低的数据库一致性时,NoSQL数据库是一个很好的选择。通常NoSQL数据库具有以下3个特点。
主从备份(master sliver)所有写操作针对主服务器,写入后同步到从服务器(同步传播or异步传播)
“One size fits all”模式很难适用于截然不同的业务场景
关系模型作为统一的数据模型既被用于数据分析,也被用于在线业务。但这两者一个强调高吞吐,一个强调低延时,已经演化出完全不同的架构。用同一套模型来抽象显然是不合适的
•Hadoop就是针对数据分析
•MongoDB、 Redis等是针对在线业务,两者都抛弃了关系模型
比较标准 | RDBMS | NoSQL | 备注 |
---|---|---|---|
数据库原理 | 完全支持 | 部分支持 | RDBMS有关系代数理论作为基础,NoSQL没有统一的理论基础 |
数据规模 | 大 | 超大 | RDBMS很难实现横向扩展, 纵向扩展的空间也比较有限, 性能会随着数据规模的增大而降低NoSQL可以很容易通过添加更多设备来支持更大规模的数据 |
数据库模式 | 固定 | 灵活 | RDBMS需要定义数据库模式, 严格遵守数据定义和相关约束条件。NoSQL不存在数据库模式, 可以自由灵活定义并存储各种不同类型的数据 |
数据库模式 | 固定 | 灵活 | RDBMS需要定义数据库模式, 严格遵守数据定义和相关约束条件。NoSQL不存在数据库模式, 可以自由灵活定义并存储各种不同类型的数据 |
一致性 | 强一致性 | 弱一致性 | RDBMS严格遵守事务ACID模型, 可以保证事务强一致性。很多NoSQL数据库放松了对事务ACID四性的要求, 而是遵守BASE模型, 只能保证最终一致性 |
数据完整性 | 容易实现 | 很难实现 | 任何一个RDBMS都可以很容易实现数据完整性,比如通过主键或者非空约束来实现实体完整性,通过主键、 外键来实现参照完整性, 通过约束或者触发器来实现用户自定义完整性但是, 在NoSQL数据库却无法实现 |
扩展性 | 一般 | 好 | RDBMS很难实现横向扩展, 纵向扩展的空间也比较有限。NoSQL在设计之初就充分考虑了横向扩展的需求, 可以很容易通过添加廉价设备实现扩展 |
可用性 | 好 | 很好 | RDBMS在任何时候都以保证数据一致性为优先目标, 其次才是优化系统性能, 随着数据规模的增大, RDBMS为了保证严格的一致性, 只能提供相对较弱的可用性大多数NoSQL都能提供较高的可用性 |
标准化 | 是 | 否 | RDBMS已经标准化(SQL)NoSQL还没有行业标准, 不同的NoSQL数据库都有自己的查询语言, 很难规范应用程序接口 |
技术支持 | 高 | 低 | RDBMS经过几十年的发展, 已经非常成熟,Oracle等大型厂商都可以提供很好的技术支持。NoSQL在技术支持方面仍然处于起步阶段, 还不成熟, 缺乏有力的技术支持 |
可维护性 | 复杂 | 复杂 | RDBMS需要专门的数据库管理员(DBA)维护。NoSQL数据库虽然没有DBMS复杂, 也难以维护 |
总结:
( 1)关系数据库
优势:以完善的关系代数理论作为基础,有严格的标准,支持事务ACID四性,借助索引机制可以实现高效的查询,技术成熟,有专业公司的技术支持
劣势:可扩展性较差,无法较好支持海量数据存储,数据模型过于死板、无法较好支持Web2.0应用,事务机制影响了系统的整体性能等
( 2) NoSQL数据库
优势:可以支持超大规模数据存储,灵活的数据模型可以很好地支持Web2.0应用,具有强大的横向扩展能力等
劣势:缺乏数学理论基础,复杂查询性能不高,大都不能实现事务强一致性,很难实现数据完整性,技术尚不成熟,缺乏专业团队的技术支持,维护较困难等
关系数据库和NoSQL数据库各有优缺点,彼此无法取代
关系数据库应用场景:电信、银行等领域的关键业务系统,需要保证强事务一致性
NoSQL数据库应用场景:互联网企业、传统企业的非关键业务(比如数据分析)
采用混合架构
•案例:亚马逊公司就使用不同类型的数据库来支撑它的电子商务应用
对于“购物篮”这种临时性数据,采用键值存储会更加高效
当前的产品和订单信息则适合存放在关系数据库中
大量的历史订单信息则适合保存在类似MongoDB的文档数据库中
NoSQL数据库虽然数量众多, 但是, 归结起来, 典型的NoSQL数库通常包括键值数据库、 列族数据库、 文档数据库和图数据库。
所谓的CAP指的是:
C( Consistency): 一致性,是指任何一个读操作总是能够读到之前完成的写操作的结果,也就是在分布式环境中,多点的数据是一致的,或者说,所有节点在同一时间具有相同的数据
A:( Availability): 可用性,是指快速获取数据,可以在确定的时间内返回操作结果,保证每个请求不管成功或者失败都有响应;
P( Tolerance of Network Partition): 分区容忍性,是指当出现网络分区的情况时(即系统中的一部分节点无法和其他节点进行通信),分离的系统也能够正常运行,也就是说,系统中任意信息的丢失或失败不会影响系统的继续运作。
CAP理论告诉我们,一个分布式系统不可能同时满足一致性、可用性和分区容忍性这三个需求,最多只能同时满足其中两个,正所谓“鱼和熊掌不可兼得”。
当处理CAP的问题时,可以有几个明显的选择:
1.CA:也就是强调一致性(C)和可用性(A),放弃分区容忍性(P),最简单的做法是把所有与事务相关的内容都放到同一台机器上。很显然,这种做法会严重影响系统的可扩展性。传统的关系数据库(MySQL、 SQL Server和PostgreSQL),都采用了这种设计原则,因此,扩展性都比较差
2.CP:也就是强调一致性(C)和分区容忍性(P),放弃可用性(A),当出现网络分区的情况时,受影响的服务需要等待数据一致,因此在等待期间就无法对外提供服务
3.AP:也就是强调可用性(A)和分区容忍性(P),放弃一致性(C),允许系统返回不一致的数据
BASE的基本含义是基本可用(Basically Availble)、软状态(Softstate)和最终一致性(Eventual consistency) :
最终一致性根据更新数据后各进程访问到数据的时间和方式的不同,又可以区分为:
如何实现各种类型的一致性?
对于分布式数据系统:
•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。
•像Voldemort, Cassandra和Riak这些类Dynamo的系统,通常都允许用户按需要设置N, R, W三个值,即使是设置成W+R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性,或者是W<N的强一致性时,则总会出现一段“各个节点数据不同步导致系统处理不一致的时间”。为了提供最终一致性的支持,这些系统会提供一些工具来使数据更新被最终同步到所有相关节点。
ACID,指数据库事务正确执行的四个基本要素的缩写。包含:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。一个支持事务(Transaction)的数据库,必需要具有这四种特性,否则在事务过程(Transaction processing)当中无法保证数据的正确性,交易过程极可能达不到交易方的要求。
原子性(Atomicity)
整个事务中的所有操作,要么全部完成,要么全部不完成,不可能停滞在中间某个环节。事务在执行过程中发生错误,会被 回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。
一致性(Consistency)
一个事务可以封装状态改变(除非它是一个只读的)。事务必须始终保持系统处于一致的状态,不管在任何给定的时间 并发事务有多少。
也就是说:如果事务是 并发多个,系统也必须如同串行事务一样操作。其主要特征是保护性和不变性(Preserving an Invariant),以转账 案例为例,假设有五个账户,每个账户余额是100元,那么五个账户总额是500元,如果在这个5个账户之间同时发生多个转账,无论 并发多少个,比如在A与B账户之间转账5元,在C与D账户之间转账10元,在B与E之间转账15元,五个账户总额也应该还是500元,这就是保护性和不变性
隔离性(Isolation)
隔离状态执行事务,使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务,运行在相同的时间内,执行相同的功能,事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为 串行化,为了防止事务操作间的混淆,必须串行化或序列化请求,使得在同一时间仅有一个请求用于同一数据。
持久性(Durability)
在事务完成以后,该事务对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。
由于一项操作通常会包含许多子操作,而这些子操作可能会因为硬件的损坏或其他因素产生问题,要正确实现ACID并不容易。ACID建议数据库将所有需要更新以及修改的资料一次操作完毕,但实际上并不可行。
目前主要有两种方式实现ACID:第一种是Write ahead logging,也就是日志式的方式(现代数据库均基于这种方式)。第二种是Shadow paging。
相对于WAL(write ahead logging)技术,shadow paging技术实现起来比较简单,消除了写日志记录的开销恢复的速度也快(不需要redo和undo)。shadow paging的缺点就是事务提交时要输出多个块,这使得提交的开销很大,而且以块为单位,很难应用到允许多个事务并发执行的情况——这是它致命的缺点。
WAL 的中心思想是对数据文件 的修改(它们是表和索引的载体)必须是只能发生在这些修改已经 记录了日志之后 ——也就是说,在日志记录冲刷到永久存储器之后. 如果我们遵循这个过程,那么我们就不需要在每次事务提交的时候 都把数据页冲刷到磁盘,因为我们知道在出现崩溃的情况下, 我们可以用日志来恢复数据库:任何尚未附加到数据页的记录 都将先从日志记录中重做(这叫向前滚动恢复,也叫做 REDO) 然后那些未提交的事务做的修改将被从数据页中删除 (这叫向后滚动恢复 UNDO)。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。