zoukankan      html  css  js  c++  java
  • 怎样理解NoSQL的一致性等

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

    1. l High Performance——对数据库高并发读写的需求
    2. l Huge Storage——对海量数据的高效率存储的需求
    3. l High Scalability & High Availablity——对数据库的高可扩展性和高可用性的需求。

     


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

    (1) 数据库事务一致性需求(关于一致性的理解,下面的图表很形象)

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

    (2)数据库的实时性需求

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

    (3)对复杂的SQL查询,特别是多表关联查询的需求

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

     


    什么是NoSQL

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

     


    NoSQL的理论基础

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

     


    ACID vs. BASE

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


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

     

    BASE内容:

    • Basically Availble ——基本可用

    所谓的高可用性是指:每次插入或者删除一条数据,执行的速度必须要快。也可以说,我们的每一次查询都必须有结果返回。(尽管结果可能由于延迟而导致两次的结果不一致)。在换句话说,也就是低延迟!

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

    也就是一致性。见下面的图表解释

    • Eventual Consistency ——最终一致性

     最终我们获得的是一致的,能达到这样的目的就是正确的。


    CAP原理

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

    1. 一致性(Consistency):任何一个读操作总是能读取到之前完成的写操作结果,也就是在分布式环境中,多点的数据是一致的。
    2. 可用性(Availability):每一个操作总是能够在确定的时间内返回,也就是系统随时都是可用的。
    3. 分区容忍性(Tolerance of network Partition):在出现网络分区(比如断网)的情况下,分离的系统也能正常运行

    这个概念比较难理解。

     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值,不一致性产生了。并且当把节点的规模不断扩大的时候,不一致性问题也会更加严重。

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

     


    参考资料

     感谢博客:http://blog.sina.com.cn/s/blog_3fe961ae010139u6.html

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

    NoSQL的模式》,作者Ricky Ho

    NoSQL数据库笔谈

    Brewer's CAP Theorem

    Eventually Consistent - Revisited

     

  • 相关阅读:
    Java实现 蓝桥杯 算法提高 特等奖学金(暴力)
    Java实现 蓝桥杯 算法提高 特等奖学金(暴力)
    Java实现 蓝桥杯 算法提高 GPA(暴力)
    Java实现 蓝桥杯 算法提高 GPA(暴力)
    Java实现 蓝桥杯 算法提高 GPA(暴力)
    Java实现 蓝桥杯 算法提高 套正方形(暴力)
    Java实现 蓝桥杯 算法提高 套正方形(暴力)
    第一届云原生应用大赛火热报名中! helm install “一键安装”应用触手可及!
    云原生时代,2个方案轻松加速百万级镜像
    Knative 基本功能深入剖析:Knative Serving 自动扩缩容 Autoscaler
  • 原文地址:https://www.cnblogs.com/CBDoctor/p/2879883.html
Copyright © 2011-2022 走看看