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

1、传统关系型数据库面临的挑战l High Performance对数据库高并发读写的需求l Huge Storage对海量数据的高效率存储的需求l High Scalability & High Availablity对数据库的高可扩展性和高可用性的需求。对于当前的很多网站来说，关系数据库的很多主要特性往往无用武之地，例如：l 数据库事务一致性需求很多系统并不要求严格的数据库事务，对读一致性的要求很低，因此数据库事务管理成了数据库高负载下一个沉重的负担。l 数据库的实时性需求对关系型数据库来说，插入一条数据后立刻查询，是肯定可以读出来这条数据的，但是对于很多Web应用而言，并不要求这么高的实时性

2、，比方说我发一条微博之后，过几秒乃至十几秒后，别人才提示有新微博，这是完全可以的。l 对复杂的SQL查询，特别是多表关联查询的需求大数据量的Web系统，非常忌讳多个大表的关联查询，以及复杂的数据分析类型的SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分布查询，SQL的功能被极大地弱化了。什么是NoSQL现在一般认为NoSQL全称是Not Only SQL，是一种不同于关系型数据库的数据库管理系统设计方式。对NoSQL最普遍的解释是“非关系型的”，强调Key-Value Stores和文档数据库的优点，而不是

3、单纯的反对RDBMS。NoSQL的理论基础CAP，BASE和最终一致性是NoSQL数据库存在的三大基石。ACID vs. BASEACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性(Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。 （这张PPT是Brewer教授在PODC大会上用的PPT。）BASE内容：l Basically Availble 基本可用l Soft-state 软状态/柔性事务，状态可以有一段时间不同步l Eventual Consistency 最终一致性CAP原理分布式系统中，有三种重要的

4、属性，分别是：l 一致性(Consistency)：任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的。l 可用性(Availability)：每一个操作总是能够在确定的时间内返回，也就是系统随时都是可用的。l 分区容忍性(Tolerance of network Partition)：在出现网络分区（比如断网）的情况下，分离的系统也能正常运行。CAP原理的意思是，一个分布式系统不能同时满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。注意：可用性与分区容忍性在一些情况下很容易混淆。举个例子，假设系统中有若干个节点宕机了，系统仍然能正常运行，

5、那么应该说是系统的可用性高还是分区容忍性高呢？个人的理解是，这种应该理解为系统的分区容忍性高。因为若干个节点宕机，可以理解为这几个节点与其它正常的节点失去联系了，也就是出现了网络分区，按照定义，这属于分区容忍性的范畴。那么可用性是什么？个人的理解可用性更多强调的是，系统对于读写操作的反应快慢，反应越快，可用性越高。CAP原理是由美国著名科学家，Berkerly大学Brewer教授提出的。后来麻省理工学院的两位科学家证明了CAP原理的正确性。虽然在后来近十年的时间很多人对CAP原理出了很多异议，但是在NoSQL的世界中，它还是非常有参考价值的。一致性or可用性，鱼和熊掌不可得兼下面是一个牺牲一致

6、性换取可用性的小例子。假设N1和N2是分布式环境下的两个节点，它们有保存了共同的数据V，它们的值都是V0，A和B是两个分别对数据进行操作的进程。我们看看这么一个过程：A向N1节点写入了新的V值V1，B读取V的值。如果一切正常的话，这个过程看起来像是这样的：(1)A写入V的新值V1。(2)N1向N2发送消息M以更新V值。(3)B读取V的新值V2。 但是现实可能是这样子的：由于网络分区，N1发向N2的消息很有可能没送达，那么，B节点将读取到一个过时的V值，不一致性产生了。并且当把节点的规模不断扩大的时候，不一致性问题也会更加严重。所以如果我们希望A B都是高可用的（也就是低延迟），那么一致性通常就

7、不能得到很好的保证，我们必须要容忍一定的不一致性以换取高可用性。从客户端角度看一致性有很多种客户端一致性模型：强一致性：读取到的数据总是最新的。弱一致性：读取到的数据不一定是最新的。最终一致性：属于弱一致性，不同的是，最终一致性的系统会在后台异步地更新所有的备份，所以最终所有的备份都会是最新的数据。最终一致性有一些比较重要的变种，例如：因果一致性：如果进程A更新了某数据，并通知进程B，那么进程B接下来的读操作将一定会读取到最新的数据，写操作一定能覆盖之前的数据。而另一与进程A无关的进程C则服从最终一致性的情况。“读己之所写”一致性：客户端可以立即看到自己所作的更新，但不能立即看到其他客户端的更

8、新。会话一致性：对于客户端在一同会话作用域中发起的请求，提供“读己之所写”一致性。单调读一致性：保证时间上的单调性，保证客户端在未来的请求中，只会读到比当前更为新的数据。从服务器端角度看一致性我们利用一个数学模型来分析一下服务器端对于一致性的实现。了解完这个部分，对于具体NoSQL数据库的理解和分析就能事半功倍了。Quorum NRW 模型先看下面这个图，并定义一些变量。l N：存储备份的节点数目，可以理解为备份的数目。l W：更新（写）操作成功之前所必须更新的最少备份数目。假设W=3，表示至少等到3个备份的数据得到更新时，更新操作才算完成。l R：读操作所需要连接的最少备份数目。假设R=3，

9、表示读取一个数据时，至少要读取到这个数据的3个备份，然后选其中最新的备份。调整N、W、R的取值，数据库系统的性质就会发生改变。l N越大，同一个数据的备份越多，系统相对也就越不容易丢失数据。l W越大，系统的一致性会越高，但更新操作也就越慢。l R越大，系统的一致性会越高，但读操作也就越慢。l W+RN，系统是强一致性的。为什么？举例来说，假设N=6，W=R=3，当一个更新操作完成的时候，它至少更新了6个备份中的3个备份，那么当我们去读取这个数据的时候，因为R=3，所以我们至少得读3个数据，并从中选择最新的数据，而W+RN就意味着读取的3个数据跟更新的3个数据至少有一个是重叠的，所以读取的3个数据中一定存在最新的数据，因而就能保证系统是强一致性的。l W+R=N，系统是弱一致性的。几种特殊情况：l W = 1，R = N，对写操作要求高性能高可用。l R = 1，W = N，对读操作要求高性能高可用，比如类似cache之类业务。l W = R = N