【NoSQL】NoSQL入门级资料整理(CAP原理、最终一致性)

前端之家收集整理的这篇文章主要介绍了【NoSQL】NoSQL入门级资料整理(CAP原理、最终一致性)前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。


http://blog.sina.com.cn/s/blog_3fe961ae010139u6.html

传统关系型数据库面临的挑战

lHighPerformance——对数据库高并发读写的需求

lHugeStorage——对海量数据的高效率存储的需求

lHighScalability&HighAvailablity——对数据库的高可扩展性和高可用性的需求。

对于当前的很多网站来说,关系数据库的很多主要特性往往无用武之地,例如:

l数据库事务一致性需求

很多系统并不要求严格的数据库事务,对读一致性的要求很低,因此数据库事务管理成了数据库负载下一个沉重的负担。

l数据库的实时性需求

对关系型数据库来说,插入一条数据后立刻查询,是肯定可以读出来这条数据的,但是对于很多Web应用而言,并不要求这么高的实时性,比方说我发一条微博之后,过几秒乃至十几秒后,别人才提示有新微博,这是完全可以的。

l对复杂的sql查询,特别是多表关联查询的需求

大数据量的Web系统,非常忌讳多个大表的关联查询,以及复杂的数据分析类型的sql报表查询,特别是SNS类型的网站,从需求以及产品设计角度,就避免这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分布查询sql功能被极大地弱化了。

什么是Nosql

现在一般认为Nosql全称是NotOnlysql,是一种不同于关系型数据库数据库管理系统设计方式。对Nosql最普遍的解释是“非关系型的”,强调Key-ValueStores和文档数据库的优点,而不是单纯的反对RDBMS

Nosql的理论基础

CAPBASE和最终一致性是Nosql数据库存在的三大基石。

ACIDvs.BASE

ACID,指数据库事务正确执行的四个基本要素的缩写。包含:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。


(这张PPTBrewer教授在PODC大会上用的PPT。)

BASE内容

lBasicallyAvailble——基本可用

Soft-state——软状态/柔性事务,状态可以有一段时间不同步

EventualConsistency——最终一致性

CAP原理

分布式系统中,有三种重要的属性,分别是:

l一致性(Consistency):任何一个读操作总是能读取到之前完成写操作结果,也就是在分布式环境中,多点的数据是一致的。

可用性(Availability):每一个操作总是能够在确定的时间内返回,也就是系统随时都是可用的。

分区容忍性(ToleranceofnetworkPartition):在出现网络分区(比如断网)的情况分离的系统也能正常运行。

CAP原理的意思是,一个分布式系统不能同时满足一致性,可用性和分区容错性这三个需求,最多只能同时满足两个。

注意:可用性与分区容忍性在一些情况下很容易混淆。举个例子,假设系统中有若干个节点宕机了,系统仍然能正常运行,那么应该说是系统的可用性高还是分区容忍性高呢?个人的理解是,这种应该理解为系统的分区容忍性高。因为若干个节点宕机,可以理解为这几个节点与其它正常的节点失去联系了,也就是出现了网络分区,按照定义,这属于分区容忍性的范畴。那么可用性是什么?个人的理解可用性更多强调的是,系统对于读写操作的反应快慢,反应越快,可用性越高

CAP原理是由美国著名科学家,Berkerly大学Brewer教授提出的。后来麻省理工学院的两位科学家证明了CAP原理的正确性。虽然在后来近十年的时间很多人对CAP原理出了很多异议,但是在Nosql的世界中,它还是非常有参考价值的。

一致性or可用性,鱼和熊掌不可得兼

下面是一个牺牲一致性换取可用性的小例子。

假设N1N2是分布式环境下的两个节点,它们有保存了共同的数据V,它们的值都是V0AB是两个分别对数据进行操作的进程。我们看看这么一个过程:AN1节点写入了新的VV1B读取V的值。

如果一切正常的话,这个过程看起来像是这样的:

(1)A写入V的新值V1

(2)N1N2发送消息M以更新V值。

(3)B读取V的新值V2

但是现实可能是这样子的:

由于网络分区,N1发向N2的消息很有可能没送达,那么,B节点将读取到一个过时的V值,不一致性产生了。并且当把节点的规模不断扩大的时候,不一致性问题也会更加严重。

所以如果我们希望AB都是高可用的(也就是低延迟),那么一致性通常就不能得到很好的保证,我们必须要容忍一定的不一致性以换取高可用性

从客户端角度看一致性

有很多种客户端一致性模型:

强一致性:读取到的数据总是最新的。

弱一致性:读取到的数据不一定是最新的。

最终一致性:属于弱一致性,不同的是,最终一致性的系统会在后台异步地更新所有的备份,所以最终所有的备份都会是最新的数据。

最终一致性有一些比较重要的变种,例如:

因果一致性:如果进程A更新了某数据,并通知进程B,那么进程B接下来的读操作将一定会读取到最新的数据,写操作一定能覆盖之前的数据。而另一与进程A无关的进程C则服从最终一致性的情况。

“读己之所写”一致性:客户端可以立即看到自己所作的更新,但不能立即看到其他客户端的更新。

会话一致性:对于客户端在一同会话作用域中发起的请求,提供“读己之所写”一致性。

单调读一致性:保证时间上的单调性,保证客户端在未来的请求中,只会读到比当前更为新的数据。

从服务器端角度看一致性

我们利用一个数学模型来分析一下服务器端对于一致性的实现。了解完这个部分,对于具体Nosql数据库的理解和分析就能事半功倍了。

QuorumNRW模型

先看下面这个图,并定义一些变量。

lN:存储备份的节点数目,可以理解为备份的数目。

lW:更新(写)操作成功之前所必须更新的最少备份数目。假设W=3,表示至少等到3个备份的数据得到更新时,更新操作才算完成。

lR:读操作所需要连接的最少备份数目。假设R=3,表示读取一个数据时,至少要读取到这个数据的3个备份,然后选其中最新的备份。

调整NWR的取值,数据库系统的性质就会发生改变。

lN越大,同一个数据的备份越多,系统相对也就越不容易丢失数据。

lW越大,系统的一致性会越高,但更新操作也就越慢。

lR越大,系统的一致性会越高,但读操作也就越慢。

lW+R>N,系统是强一致性的。为什么?举例来说,假设N=6W=R=3,当一个更新操作完成的时候,它至少更新了6个备份中的3个备份,那么当我们去读取这个数据的时候,因为R=3,所以我们至少得读3个数据,并从中选择最新的数据,而W+R>N就意味着读取的3个数据跟更新的3个数据至少有一个是重叠的,所以读取的3个数据中一定存在最新的数据,因而就能保证系统是强一致性的。

lW+R<=N,系统是弱一致性的。

几种特殊情况:

lW=1R=N,对写操作要求高性能高可用。

lR=1W=N,对读操作要求高性能高可用,比如类似cache之类业务。

lW=R=N/2+1一般应用适用,读写性能之间取得平衡。如N=3W=2R=2

不同类型的数据库CAP支持

参考资料

Nosql数据库综述》,作者范凯

Nosql的模式》,作者RickyHo

NoSQL数据库笔谈

Brewer'sCAPTheorem

EventuallyConsistent-Revisited

原文链接:https://www.f2er.com/nosql/204221.html

猜你在找的NoSQL相关文章