NoSQL入門級整理(CAP原理、最終一致性) (3)

1、傳統(tǒng)關系型數(shù)據(jù)庫面臨的挑戰(zhàn)l High Performance對數(shù)據(jù)庫高并發(fā)讀寫的需求l Huge Storage對海量數(shù)據(jù)的高效率存儲的需求l High Scalability & High Availablity對數(shù)據(jù)庫的高可擴展性和高可用性的需求。 對于當前的很多網(wǎng)站來說，關系數(shù)據(jù)庫的很多主要特性往往無用武之地，例如：l 數(shù)據(jù)庫事務一致性需求很多系統(tǒng)并不要求嚴格的數(shù)據(jù)庫事務，對讀一致性的要求很低，因此數(shù)據(jù)庫事務管理成了數(shù)據(jù)庫高負載下一個沉重的負擔。l 數(shù)據(jù)庫的實時性需求對關系型數(shù)據(jù)庫來說，插入一條數(shù)據(jù)后立刻查詢，是肯定可以讀出來這條數(shù)據(jù)的，但是對于很多Web應用而言，并

2、不要求這么高的實時性，比方說我發(fā)一條微博之后，過幾秒乃至十幾秒后，別人才提示有新微博，這是完全可以的。l 對復雜的SQL查詢，特別是多表關聯(lián)查詢的需求大數(shù)據(jù)量的Web系統(tǒng)，非常忌諱多個大表的關聯(lián)查詢，以及復雜的數(shù)據(jù)分析類型的SQL報表查詢，特別是SNS類型的網(wǎng)站，從需求以及產(chǎn)品設計角度，就避免這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分布查詢，SQL的功能被極大地弱化了。 什么是NoSQL現(xiàn)在一般認為NoSQL全稱是Not Only SQL，是一種不同于關系型數(shù)據(jù)庫的數(shù)據(jù)庫管理系統(tǒng)設計方式。對NoSQL最普遍的解釋是“非關系型的”，強調(diào)Key-Value Sto

3、res和文檔數(shù)據(jù)庫的優(yōu)點，而不是單純的反對RDBMS。  NoSQL的理論基礎CAP，BASE和最終一致性是NoSQL數(shù)據(jù)庫存在的三大基石。 ACID vs. BASEACID，指數(shù)據(jù)庫事務正確執(zhí)行的四個基本要素的縮寫。包含：原子性(Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。 （這張PPT是Brewer教授在PODC大會上用的PPT。） BASE內(nèi)容：l Basically Availble 基本可用l Soft-state 軟狀態(tài)/柔性事務，狀態(tài)可以有一段時間不同步l Even

4、tual Consistency 最終一致性 CAP原理 分布式系統(tǒng)中，有三種重要的屬性，分別是：l 一致性(Consistency)：任何一個讀操作總是能讀取到之前完成的寫操作結(jié)果，也就是在分布式環(huán)境中，多點的數(shù)據(jù)是一致的。l 可用性(Availability)：每一個操作總是能夠在確定的時間內(nèi)返回，也就是系統(tǒng)隨時都是可用的。l 分區(qū)容忍性(Tolerance of network Partition)：在出現(xiàn)網(wǎng)絡分區(qū)（比如斷網(wǎng)）的情況下，分離的系統(tǒng)也能正常運行。CAP原理的意思是，一個分布式系統(tǒng)不能同時滿足一致性，可用性和分區(qū)容錯性這三個需求，最多只能同時滿足兩個。&#

5、160;注意：可用性與分區(qū)容忍性在一些情況下很容易混淆。舉個例子，假設系統(tǒng)中有若干個節(jié)點宕機了，系統(tǒng)仍然能正常運行，那么應該說是系統(tǒng)的可用性高還是分區(qū)容忍性高呢？個人的理解是，這種應該理解為系統(tǒng)的分區(qū)容忍性高。因為若干個節(jié)點宕機，可以理解為這幾個節(jié)點與其它正常的節(jié)點失去聯(lián)系了，也就是出現(xiàn)了網(wǎng)絡分區(qū)，按照定義，這屬于分區(qū)容忍性的范疇。那么可用性是什么？個人的理解可用性更多強調(diào)的是，系統(tǒng)對于讀寫操作的反應快慢，反應越快，可用性越高。 CAP原理是由美國著名科學家，Berkerly大學Brewer教授提出的。后來麻省理工學院的兩位科學家證明了CAP原理的正確性。雖然在后來近十年的時間很多人

6、對CAP原理出了很多異議，但是在NoSQL的世界中，它還是非常有參考價值的。 一致性or可用性，魚和熊掌不可得兼下面是一個犧牲一致性換取可用性的小例子。假設N1和N2是分布式環(huán)境下的兩個節(jié)點，它們有保存了共同的數(shù)據(jù)V，它們的值都是V0，A和B是兩個分別對數(shù)據(jù)進行操作的進程。我們看看這么一個過程：A向N1節(jié)點寫入了新的V值V1，B讀取V的值。如果一切正常的話，這個過程看起來像是這樣的：(1) A寫入V的新值V1。(2) N1向N2發(fā)送消息M以更新V值。(3) B讀取V的新值V2。  但是現(xiàn)實可能是這樣子的：  由于網(wǎng)絡分區(qū)，N

7、1發(fā)向N2的消息很有可能沒送達，那么，B節(jié)點將讀取到一個過時的V值，不一致性產(chǎn)生了。并且當把節(jié)點的規(guī)模不斷擴大的時候，不一致性問題也會更加嚴重。所以如果我們希望A B都是高可用的（也就是低延遲），那么一致性通常就不能得到很好的保證，我們必須要容忍一定的不一致性以換取高可用性。 從客戶端角度看一致性有很多種客戶端一致性模型：強一致性：讀取到的數(shù)據(jù)總是最新的。弱一致性：讀取到的數(shù)據(jù)不一定是最新的。最終一致性：屬于弱一致性，不同的是，最終一致性的系統(tǒng)會在后臺異步地更新所有的備份，所以最終所有的備份都會是最新的數(shù)據(jù)。最終一致性有一些比較重要的變種，例如：因果一致性：如果進程A更新了某數(shù)據(jù)，并

8、通知進程B，那么進程B接下來的讀操作將一定會讀取到最新的數(shù)據(jù)，寫操作一定能覆蓋之前的數(shù)據(jù)。而另一與進程A無關的進程C則服從最終一致性的情況。“讀己之所寫”一致性：客戶端可以立即看到自己所作的更新，但不能立即看到其他客戶端的更新。會話一致性：對于客戶端在一同會話作用域中發(fā)起的請求，提供“讀己之所寫”一致性。單調(diào)讀一致性：保證時間上的單調(diào)性，保證客戶端在未來的請求中，只會讀到比當前更為新的數(shù)據(jù)。  從服務器端角度看一致性我們利用一個數(shù)學模型來分析一下服務器端對于一致性的實現(xiàn)。了解完這個部分，對于具體NoSQL數(shù)據(jù)庫的理解和分析就能事半功倍了。 Quorum NRW 模

9、型先看下面這個圖，并定義一些變量。 l N：存儲備份的節(jié)點數(shù)目，可以理解為備份的數(shù)目。l W：更新（寫）操作成功之前所必須更新的最少備份數(shù)目。假設W=3，表示至少等到3個備份的數(shù)據(jù)得到更新時，更新操作才算完成。l R：讀操作所需要連接的最少備份數(shù)目。假設R=3，表示讀取一個數(shù)據(jù)時，至少要讀取到這個數(shù)據(jù)的3個備份，然后選其中最新的備份。 調(diào)整N、W、R的取值，數(shù)據(jù)庫系統(tǒng)的性質(zhì)就會發(fā)生改變。l N越大，同一個數(shù)據(jù)的備份越多，系統(tǒng)相對也就越不容易丟失數(shù)據(jù)。l W越大，系統(tǒng)的一致性會越高，但更新操作也就越慢。l R越大，系統(tǒng)的一致性會越高，但讀操作也就越慢。l W+R>N，系

10、統(tǒng)是強一致性的。為什么？舉例來說，假設N=6，W=R=3，當一個更新操作完成的時候，它至少更新了6個備份中的3個備份，那么當我們?nèi)プx取這個數(shù)據(jù)的時候，因為R=3，所以我們至少得讀3個數(shù)據(jù)，并從中選擇最新的數(shù)據(jù)，而W+R>N就意味著讀取的3個數(shù)據(jù)跟更新的3個數(shù)據(jù)至少有一個是重疊的，所以讀取的3個數(shù)據(jù)中一定存在最新的數(shù)據(jù)，因而就能保證系統(tǒng)是強一致性的。l W+R<=N，系統(tǒng)是弱一致性的。 幾種特殊情況：l W = 1，R = N，對寫操作要求高性能高可用。l R = 1，W = N，對讀操作要求高性能高可用，比如類似cache之類業(yè)務。l W = R = N / 2 + 1 一般應用適用，讀寫性能之間取得平衡。如N=3，W=2，R=