NoSQL的三大基石(CAP、BASE和最终一致性)
CAP,BASE和最终一致性是NoSQL数据库存在的三大基石。而五分钟法则是内存数据存储了理论依据。这个是一切的源头。
CAP
C: Consistency 一致性
A: Availability 可用性(指的是快速获取数据)
P: Tolerance of network Partition 分区容忍性(分布式)
10年前,Eric Brewer教授指出了著名的CAP理论,后来Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。CAP理论告诉我们,一个分布式系统不可能满足一致性,可用性和分区容错性这三个需求,最多只能同时满足两个。
熊掌与鱼不可兼得也。关注的是一致性,那么您就需要处理因为系统不可用而导致的写操作失败的情况,而如果您关注的是可用性,那么您应该知道系统的read操作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同,相应的采用的策略也是不一样的,只有真正的理解了系统的需求,才有可能利用好CAP理论。
作为架构师,一般有两个方向来利用CAP理论
key-value存储,如Amaze Dynamo等,可根据CAP三原则灵活选择不同倾向的数据库产品。
领域模型 + 分布式缓存 + 存储 (Qi4j和NoSql运动),可根据CAP三原则结合自己项目定制灵活的分布式方案,难度高。
而对大型网站,可用性与分区容忍性优先级要高于数据一致性,一般会尽量朝着 A、P 的方向设计,然后通过其它手段保证对于一致性的商务需求。架构设计师不要精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。
不同数据对于一致性的要求是不同的。举例来讲,用户评论对不一致是不敏感的,可以容忍相对较长时间的不一致,这种不一致并不会影响交易和用户体验。而产品价格数据则是非常敏感的,通常不能容忍超过10秒的价格不一致。
CAP理论的证明:Brewer's CAP Theorem
最终一致性
一言以蔽之:过程松,结果紧,最终结果必须保持一致性
为了更好的描述客户端一致性,我们通过以下的场景来进行,这个场景中包括三个组成部分:
存储系统
存储系统可以理解为一个黑盒子,它为我们提供了可用性和持久性的保证。
Process A
ProcessA主要实现从存储系统write和read操作
Process B 和ProcessC
ProcessB和C是独立于A,并且B和C也相互独立的,它们同时也实现对存储系统的write和read操作。
下面以上面的场景来描述下不同程度的一致性:
强一致性
强一致性(即时一致性) 假如A先写入了一个值到存储系统,存储系统保证后续A,B,C的读取操作都将返回最新值
弱一致性
假如A先写入了一个值到存储系统,存储系统不能保证后续A,B,C的读取操作能读取到最新值。此种情况下有一个“不一致性窗口”的概念,它特指从A写入值,到后续操作A,B,C读取到最新值这一段时间。
最终一致性
最终一致性是弱一致性的一种特例。假如A首先write了一个值到存储系统,存储系统保证如果在A,B,C后续读取之前没有其它写操作更新同样的值的话,最终所有的读取操作都会读取到最A写入的最新值。此种情况下,如果没有失败发生的话,“不一致性窗口”的大小依赖于以下的几个因素:交互延迟,系统的负载,以及复制技术中replica的个数(这个可以理解为master/salve模式中,salve的个数),最终一致性方面最出名的系统可以说是DNS系统,当更新一个域名的IP以后,根据配置策略以及缓存控制策略的不同,最终所有的客户都会看到最新的值。
- Causal consistency(因果一致性)
如果Process A通知Process B它已经更新了数据,那么Process B的后续读取操作则读取A写入的最新值,而与A没有因果关系的C则可以最终一致性。
- Read-your-writes consistency
如果Process A写入了最新的值,那么Process A的后续操作都会读取到最新值。但是其它用户可能要过一会才可以看到。
- Session consistency
此种一致性要求客户端和存储系统交互的整个会话阶段保证Read-your-writes consistency.Hibernate的session提供的一致性保证就属于此种一致性。
- Monotonic read consistency
此种一致性要求如果Process A已经读取了对象的某个值,那么后续操作将不会读取到更早的值。
- Monotonic write consistency
此种一致性保证系统会序列化执行一个Process中的所有写操作。
BASE
说起来很有趣,BASE的英文意义是碱,而ACID是酸。真的是水火不容啊。
- Basically Availble --基本可用
- Soft-state --软状态/柔性事务
"Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的
- Eventual Consistency --最终一致性
最终一致性, 也是是 ACID 的最终目的。
BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性,获得可用性或可靠性: Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库) Soft state软状态 状态可以有一段时间不同步,异步。 Eventually consistent最终一致,最终数据是一致的就可以了,而不是时时一致。
BASE思想的主要实现有
1.按功能划分数据库
2.sharding碎片
BASE思想主要强调基本的可用性,如果你需要高可用性,也就是纯粹的高性能,那么就要以一致性或容错性为牺牲,BASE思想的方案在性能上还是有潜力可挖的。
I/O的五分钟法则
在 1987 年,Jim Gray 与 Gianfranco Putzolu 发表了这个"五分钟法则"的观点,简而言之,如果一条记录频繁被访问,就应该放到内存里,否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。 看上去像一条经验性的法则,实际上五分钟的评估标准是根据投入成本判断的,根据当时的硬件发展水准,在内存中保持
1KB 的数据成本相当于硬盘中存据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾,证实了五分钟法则依然有效(硬盘、内存实际上没有质的飞跃),而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。
随着闪存时代的来临,五分钟法则一分为二:是把 SSD 当成较慢的内存(extended buffer pool )使用还是当成较快的硬盘(extended disk)使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后,在闪存时代,5 分钟法则依然有效,只不过适合更大的内存页(适合 64KB 的页,这个页大小的变化恰恰体现了计算机硬件工艺的发展,以及带宽、延时)。
原文地址: http://wangwei.cao.blog.163.com/blog/static/102362526201052444254269/
NoSQL的三大基石(CAP、BASE和最终一致性)的更多相关文章
- 大数据技术原理与应用【第五讲】NoSQL数据库:5.4 NoSQL的三大基石
NoSQL的三大基石:cap,Base,最终一致性 5.4.1 cap理论(帽子理论): consistency:一致性availability:可用性partition tolerance: ...
- 大数据 --> CAP原理和最终一致性
CAP原理和最终一致性 CAP原理和最终一致性(Eventually Consistency)
- NoSql的三大基石:CAP理论&BASE&最终一致性
关系型数据库的局限 NoSql出现在关系型数据库之后,主要是为了解决关系型数据库的短板,我们先来看看随着软件行业的发展,关系型数据库面临了哪些挑战: 1.高并发 一个最典型的就是电商网站,例如双11, ...
- [转]CAP原理与最终一致性 强一致性 透析
在足球比赛里,一个球员在一场比赛中进三个球,称之为帽子戏法(Hat-trick).在分布式数据系统中,也有一个帽子原理(CAP Theorem),不过此帽子非彼帽子.CAP原理中,有三个要素: 一致性 ...
- CAP原理与最终一致性 强一致性 弱一致性
CAP原理中,有三个要素: 一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP原理指的是,这三个要素最多只能同时实现两点 ...
- 脑裂 CAP PAXOS 单元化 网络分区 最终一致性 BASE
阿里技术专家甘盘:浅谈双十一背后的支付宝LDC架构和其CAP分析 https://mp.weixin.qq.com/s/Cnzz5riMc9RH19zdjToyDg 汤波(甘盘) 技术琐话 2020- ...
- 分布式中 CAP BASE ACID 理解(转载)
概念理解(CAP,BASE, ACID) CAP CAP: Consistency, Availability, Partition-tolerance 强一致性(Consistency).系统在执 ...
- CAP理论与MongoDB一致性、可用性的一些思考
大约在五六年前,第一次接触到了当时已经是hot topic的NoSql.不过那个时候学的用的都是mysql,Nosql对于我而言还是新事物,并没有真正使用,只是不明觉厉.但是印象深刻的是这么一张图片( ...
- 分布式数据库中CAP原理(CAP+BASE)
分布式数据库中CAP原理(CAP+BASE) 传统的ACID 1)原子性(Atomicity): 事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功. 2)一致性(Con ...
随机推荐
- Redis基础知识之————空间换时间的查询案例
空间与时间 空间换时间是在数据库中经常出现的术语,简单说就是把查询需要的条件进行索引的存储,然后查询时为O(1)的时间复杂度来快速获取数据,从而达到了使用空间存储来换快速的时间响应!对于redis这个 ...
- HDU1542矩形面积并
取出纵向边按x坐标排序,在y方向上建立线段树. 每次查询当前有效长度len,ans += len*(x[i]-x[i-1]); 其中len为T[rt].len; 查询完毕后更新y方向上线段树,入边+1 ...
- 【转】C/C++ struct/class/union内存对齐
原文链接:http://www.cnblogs.com/Miranda-lym/p/5197805.html struct/class/union内存对齐原则有四个: 1).数据成员对齐规则:结构(s ...
- mysql 并发控制
1.多个线程同时修改数据,存在数据不一致的情况,也就是并发控制的问题.2.mysql提供读锁和写锁,读锁之上可以再加读锁,不能加写锁,而写锁之上不能加任何锁.也就是说,读锁是共享的,写锁是排他的.3. ...
- Android activity之间传值关键性代码
从当前activity中获取et 表单中的值,并跳转到myactivity.java所绑定的xml布局文件上. private EditText et; Intent intent=new Inten ...
- Android最佳性能实践(二)——分析内存的使用情况
由于Android是为移动设备开发的操作系统,我们在开发应用程序的时候应当始终把内存问题充分考虑在内.虽然Android系统拥有垃圾自动回收机制,但这并不意味着我们就可以完全忽略何时去分配或释放内存. ...
- netbeans for php常用快捷键
文本编辑 复制当前行到上一行/下一行ctl+shf+up 移动当前行到上一行/下一行shf+alt+left/right/down/up 删除当前行ctl+E 生成下一行shf+enter(回车) 大 ...
- Web服务器异常问题记录
1.使用命令,出现"-bash: 命令: Input/output error" 重启服务器后正常,网上查了下是说硬盘写入读取异常,经过和服务器厂商沟通后,确认是硬件问题导致(硬盘 ...
- 转:C++语言的15个晦涩特性
转自 http://blog.jobbole.com/54140/ 操作符重载和检查顺序 重载,(逗号),||或者&&操作符会引起混乱,因为它打破了正常的检查规则.通常情况下,逗号操作 ...
- opencl 学习资源
1.AMD opencl-optimization-guide http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated ...