NoSQL数据库-CAP-BASE-最终一致性

上传人:马*** 文档编号:113834674 上传时间:2022-06-27 格式:PPT 页数:29 大小:253.07KB
收藏 版权申诉 举报 下载
NoSQL数据库-CAP-BASE-最终一致性_第1页
第1页 / 共29页
NoSQL数据库-CAP-BASE-最终一致性_第2页
第2页 / 共29页
NoSQL数据库-CAP-BASE-最终一致性_第3页
第3页 / 共29页
资源描述:

《NoSQL数据库-CAP-BASE-最终一致性》由会员分享,可在线阅读,更多相关《NoSQL数据库-CAP-BASE-最终一致性(29页珍藏版)》请在装配图网上搜索。

1、NoSQL数据库CAP/BASE/最终一致性 NoSQL概念介绍 NoSQL的理论基础 为什么要用NoSQL数据库 NoSQL数据库分类NoSQL概念介绍什么是NoSQL一般的解释 Not only SQL,不限于SQL,是一类范围非常广泛的数据持久化解决方案,它们不遵循关系数据库模型,也不使用SQL作为查询语言。更加正确的解释 NoREL - http:/en.wikipedia.org/wiki/Nosql NoSQL的重点是non-relational,而传统的数据库是relational1998年开始的一个由Carlo Strozzi发起的一项运动,这项运动的主旨就是“要找到存储和检索

2、数据的其他高效的途径,而不是盲目地在任何情况下都把关系数据库当作万金油”非关系型数据库我们基本上都认为它是NoSQL数据库。http:/nosql-database.org/为什么要用NoSQL数据库传统关系型数据库的缺陷 最大的缺陷就是扩展性 虽然各个数据库厂商都有cluster的解决方案,但是不管share storage或share nothing的解决方案,扩展性都是很有限的。 目前解决数据库扩展性的思路主要有两个 水平分区(数据分片 sharing)或垂直分区(功能业务分区) 这样虽然可以很好解决数据库的扩展性问题,但是在实际使用中,一旦采用了数据分片或者功能分区,必然导致牺牲“关系

3、型”数据库的最大优势-join,对业务的局限性会很大,而且数据库也退化成为一个简单的存储系统。 Master-Slave复制方式 通过读写分离在某种程度上解决扩展性的问题,但是这种方案中,由于每个数据库节点必须保存所有的数据,这样每个存储的IO必然会成为扩展的瓶颈,并且master也是一个瓶颈 总的来说,传统的关系型数据库的扩展能力都是十分有限的。NoSQL是否会取代关系型数据库 应用场景 其实,NoSQL的数据库使用场景比较特殊 NoSQL无法做到通用 NoSQL对于很多人来说是此之蜜糖,彼之砒霜 使用习惯 更多的技术人员更习惯使用关系型数据库 关系型数据库也能够伪装成非关系型数据库NoSQ

4、L理论基础一切的源头 CAP,BASE和最终一致性是NoSQL数据库存在的三大基石。 而五分钟法则是内存数据存储了理论依据。这个是一切的源头。 CAPC:Consistency一致性:任何一个读操作总是能够读取之前完成的写操作A:Availability可用性(指的是快速获取数据)每一次操作总是能够在确定的时间返回P:ToleranceofnetworkPartition分区容忍性(分布式)在出现网络分区的情况下,仍然能够满足一致性和可用性。取舍10年前,Eric Brewer教授指出了著名的CAP理论,后来Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。CA

5、P理论告诉我们:一个分布式系统不可能满足一致性,可用性和分区容错性这三个需求,最多只能同时满足两个。 熊掌与鱼不可兼得也。关注的是一致性,那么您就需要处理因为系统不可用而导致的写操作失败的情况,而如果您关注的是可用性,那么您应该知道系统的read操 作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同,相应的采用的策略也是不一样的,只有真正的理解了系统的需求,才有可能利用好 CAP理论。 CA:传统关系数据库 AP:key-value数据库 而对大型网站,可用性与分区容忍性优先级要高于数据一致性,一般会尽量朝着 A、P 的方向设计,然后通过其它手段保证对于一致性的商务需求。架

6、构设计师不要精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。 不同数据对于一致性的要求是不同的。举例来讲,用户评论对不一致是不敏感的,可以容忍相对较长时间的不一致,这种不一致并不会影响交易和用户体验。而产品价格数据则是非常敏感的,通常不能容忍超过10秒的价格不一致。CAP理论的证明:Brewers CAP Theorem 一致性强一致性 ACID 在单机环境中,强一致性可以由数据库的事务来保证。 在多机环境中,强一致性很难做到。分布式事务:性能太差,在互联网的应用中不适合弱一致性(包括最终一致性) 通过提交处理的半同步、半异步或全异步,取得最终一致性效果。 最终一致性使得数据的

7、提交具有延时性,而在一定范围的延时性范围内(比如一秒),应用的可用性是OK的一言以蔽之:过程松,结果紧,最终结果必须保证一致性http:/ 为了更好的描述客户端一致性,我们通过以下的场景来进行,这个场景包括三个组成部分: 存储系统 存储系统可以理解为一个黑盒子,它为我们提供了可用性和持久性的保证 ProcessA ProcessA主要实现从存储系统write和read操作 ProcessB和ProcessC ProcessB和C是独立于A,并且B和C也相互独立,它们同时也实现对存储系统的write和read操作不同程度的一致性处理方式强一致性强一致性(即时一致性)假如A先写入一个值到存储系统,

8、存储系统保证后续的A,B,C的读操作都返回最新值弱一致性假如A先写入了一个值到存储系统,存储系统不能保证后续A,B,C的读取操作能够读到最新值。这种情况下有一个“不一致性窗口”的概念,它特指从A写入值,到后续操作A,B,C读取到最新值这一段时间。最终一致性最终一致性是弱一致性的一种特例假如A首先write了一个值到存储系统,存储系统保证如果在A,B,C后续读取之前没有其他写操作更新同样的值的话,最终所有的读取操作都会读取到A写入的最新的值。这种情况下,如果没有失败发生的话,“不一致性窗口”的大小依赖以下的几个因素:交互延迟系统的负载复制架构中replica的个数(可以理解为master/sla

9、ve模式中,slave的个数)在最终一致性方面最出名的应该是DNS系统但更新一个域名的IP以后,根据配置策略以及缓存控制策略的不同,最终所有的客户都可以看到最新的域名和IP的映射其他一致性变体的处理方式Causal consistency(因果一致性) 如果Process A通知Process B它已经更新了数据,那么Process B的后续读取操作则读取A写入的最新值,而与A没有因果关系的C则可以最终一致性。 Read-your-writes consistency(过程一致性) 如果Process A写入了最新的值,那么Process A的后续操作都会读取到最新值。但是其它用户可能要过一会

10、才可以看到。 Session consistency(会话一致性) 此种一致性要求客户端和存储系统交互的整个会话阶段保证Read-your-writes consistency Hibernate的session提供的一致性保证就属于此种一致性。 Monotonic read consistency(简单读一致性) 此种一致性要求如果Process A已经读取了对象的某个值,那么后续操作将不会读取到更早的值。 Monotonic write consistency(简单写一致性) 此种一致性保证系统会序列化执行一个Process中的所有写操作。 服务器一致性概念N:节点的个数W:更新的时候需要

11、确认已经被更新的节点个数R:读数据的时候读取数据的节点个数如果W+RN,那么分布式系统就会提供强一致性的保证,因为读取数据节点和被写入的节点是有重叠的。在一个RDBMS的复制模型中(Master/Slave),假如N=2,那么W=2,R=1,此时是一种强一致性,但是这样造成的问题就是可用性的减低,因为要想写操作成功,必须要等2个节点都完成以后才可以。在分布式系统中,一般都要有容错性,因此一般N都大于3的,此时根据CAP理论,一致性,可用性和分区容错性最多只能满足两个,那么我们就需要在一致性和分区容错性之间做一个平衡。如果要高的一致性,那么就配置为N=W,R=1,这个时候可用性就会大大降低如果想

12、要高的可用性,那么此时就需要放松一致性的要求,此时可以配置W=1,这样使得写操作延迟最低,同时通过异步的机制剩余的N-W个节点服务器一致性 当存储系统保证最终一致性时,存储系统的配置一般是W+R=N,此时读取和写入操作是不重叠的。 不一致窗口就依赖存储系统的异步实现方式,不一致窗口大小也就等于从更新开始到所有节点都异步更新完成之间的时间 N,R,W的例子 (N,R,W) 的值典型设置为 (3, 2 ,2),兼顾性能与可用性 W = 1, R = N,对写操作要求高性能高可用。 R = 1, W = N , 对读操作要求高性能高可用,比如类似cache之类业务。 W = Q, R = Q whe

13、re Q = N / 2 + 1 一般应用适用,读写性能之间取得平衡。如N=3,W=2,R=2BASEBASE(Basically Available,Soft state,Eventually consistent)是对CAP中的AP的衍生 在单机环境中,ACID是数据的属性 而在分布式环境中,BASE就是数据的属性BASE模型完全不同于ACID模型,它通过牺牲高一致性,获得可用性和可靠性(容错性)BASE思想主要实现有 按功能划分数据库 SharingBASE思想主要强调基本的可用性,如果你需要高可用性,也就是纯粹的高性能,那么就要以一致性或容错性为牺牲,BASE思想的方案在性能上还是有潜

14、力可挖的。五分钟法则http:/queue.acm.org/detail.cfm?id=1413264http:/developers.solidot.org/article.pl?sid=09/07/06/0522101987年发表的这个“五分钟法则” 评估了在内存中保留数据和在硬盘上储存数据之间的利益权衡:如果数据被频繁访问,那么它应该放在内存里;否则就储存在硬盘内,其临界点便是五分钟在内存中保持1KB的数据成本相当于硬盘中存储同样大小数据400秒的开销随着闪存时代的来临,五分钟法则一分为二:是把 SSD 当成较慢的内存(extended buffer pool )使用还是当成较快的硬盘(

15、extended disk)使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后,在闪存时代,5 分钟法则依然有效,只不过适合更大的内存页(适合 64KB 的页,这个页大小的变化恰恰体现了计算机硬件工艺的发展,以及带宽、延时)。一致性哈希 Consistent Hash我们把每台server分成v个虚拟节点,再把所有虚拟节点(n*v)随机分配到一致性哈希的圆环上,这样所有的用户从自己圆环上的位置顺时针往下取到第一个vnode就是自己所属节点。当此节点存在故障时,再顺时针取下一个作为替代节点。优点:发生单点故障时负载会均衡分散到其他所有节点,

16、程序实现也比较优雅。优点:发生单点故障时负载会均衡分散到其他所有节点,程序实现也比较优雅。NoSQL数据库分类NoSQL数据库分类一般来说,基本上分为以下几种:Key/Value Stores (键/值存储库)Amazon SimpleDBhttp:/ DBhttp:/ Stores (文档库)CouchDBhttp:/couchdb.apache.org/MongoDBhttp:/www.mongodb.org/Graph Database (图形数据库)Neo4jhttp:/www.neo4j.org/Wide Column Stores (列存储库)Hadoophttp:/hadoop.

17、apache.org/Cassandrahttp:/incubator.apache.org/cassandra/NoSQL的整体架构接口层(Interfaces) 这层的主要作用是为上层应用提供合适和方便的数据调用接口,而且提供的选择远多于传统的关系型数据库,主要有六大类接口: 其一是常见的 REST(Representational State Transfer),采用REST的产品有HBase和CouchDB等。 其二是源自Facebook的RPC协议Thrift,支持Thrift的产品 有HBase和Cassandra等。 其三是用于大规模数据处理的Map Reduce,其相关产品有H

18、Base,CouchDB和MongoDB等。 其四是类似于Memcached的Get/Put方式,采用Get/Put的 产品有Voldemort等。 其五是提供语言特定(Language Specific)的API,比如Java,在这方面做的不错是MongoDB。 最后一个是提供SQL的子集,虽然“Join”在NoSQL属于禁忌,但 是提供一个SQL的基本子集来方便用户也是一个不错的想法。 数据逻辑模型层(Logical Data Model)这层的主要作用是描述数据的逻辑表现形式,而且与关系型数据库相比NoSQL在逻辑表现形式方面相当灵活,主要有四种形式: 最普通的Key- Value形式,

19、这种形式在表现形式是比较单一,但是在扩展方面很有优势,采用Key-Value形式产品的有Voldemort等。 列式 (Column Family),这种形式与Key-Value相比其能支持更复杂的数据,但是在扩展方面稍逊一筹,其相关产品有BigTable,HBase和 Cassnadra等。 文档(Doucument)形式,文档形式源自于著名协作软件Lotus Notes,并且本质上与Key-Value形式非常相似,主要区别在于是那个Value只能存储文档形式的数据,同时文档形式在对复杂数据的支持和扩展 这两方面表现都还可以,采用文档形式的产品有Couch DB和MongoDB等。 图(Gr

20、aph)式,图式的使用场景不是很广,主要是为基于图数据结构的数据“度身定做”的,比如SNS应用中的关系等,其最知名的产品就是 Neo4j。数据分布层(Data Distribution Model) 这层的主要作用是定义了数据是如何分布的,和关系型数据库不同的是NoSQL数据库可选择的机制比较多,主要有三种: 其一是用于水平扩展的CAP机制,支 持CAP的产品有HBase,MongoDB和Cassandra等。 其二是对多数据中心的支持,通过这个机制能够保证横跨多数据中心的NoSQL数据库 能非常平稳地运行,相关的产品有Cassandra等。 其三是支持动态部署,也就是能在一个生产集群中能动态

21、并且平滑地添加或者删去一个节点数据持久层(Data Persistence) 这层主要作用是定义了数据的存储形式,主要有四种形式: 基于内存形式,这种形式速度最快,但是存在丢失数据的可能性,采 用内存的有Redis等。 基于硬盘形式,这种形式,在数据耐久性方面表现不错,但是在速度方面远不如基于内存的,其相关产品有MongoDB等。 基于 内存和硬盘的形式,因为这种形式主要结合前面两者的优点,所以其在速度上表现不错,同时数据也不会丢失,而且常被认为是最合适的方案,采用这种形式的产品 有HBase和Cassandra等。 定制可插拔(Custom Pluggable)形式,这种形式以灵活著称注意 虽然分四层,但并不意味着每个产品只能在每一层选择一个特性,而是可以选择多个特性。 比如,在接口层HBase支持REST,Thrift和Map Reduce这三种接口,而在数据分布层,Cassandra即支持CAP,又对多数据中心有所支撑。谢谢

展开阅读全文
温馨提示:
1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!