NoSQL 數據庫中的 CAP 理論

 

傳統的 ACID

關係型數據庫遵循ACID規則
事務在英文中是transaction，和現實世界中的交易很相似，它有以下四個特性：

A (Atomicity) 原子性

原子性很容易理解，也就是說事務裏的全部操做要麼所有作完，要麼都不作，事務成功的條件是事務裏的全部操做都成功，只要有一個操做失敗，整個事務就失敗，須要回滾。好比銀行轉帳，從A帳戶轉100元至B帳戶，分爲兩個步驟：1）從A帳戶取100元；2）存入100元至B帳戶。這兩步要麼一塊兒完成，要麼一塊兒不完成，若是隻完成第一步，第二步失敗，錢會莫名其妙少了100元。

C (Consistency) 一致性

一致性也比較容易理解，也就是說數據庫要一直處於一致的狀態，事務的運行不會改變數據庫本來的一致性約束。

I (Isolation) 獨立性

所謂的獨立性是指併發的事務之間不會互相影響，若是一個事務要訪問的數據正在被另一個事務修改，只要另一個事務未提交，它所訪問的數據就不受未提交事務的影響。好比現有有個交易是從A帳戶轉100元至B帳戶，在這個交易還未完成的狀況下，若是此時B查詢本身的帳戶，是看不到新增長的100元的

D (Durability) 持久性

持久性是指一旦事務提交後，它所作的修改將會永久的保存在數據庫上，即便出現宕機也不會丟失。

CAP

C:Consistency（強一致性）

A:Availability（可用性）

P:Partition tolerance（分區容錯性）

CAP 的 3 進 2 原則

CAP 理論就是說在分佈式存儲系統中，最多隻能實現上面的兩點。
而因爲當前的網絡硬件確定會出現延遲丟包等問題，因此

分區容忍性是咱們必須須要實現的。

因此咱們只能在一致性和可用性之間進行權衡，沒有 NoSQL 系統能同時保證這三點。

• CA：傳統 Oracle 數據庫
• AP：大多數網站架構的選擇
• CP：Redis、Mongodb

注意：分佈式架構的時候必須作出取捨。

一致性和可用性之間取一個平衡。多餘大多數 Web 應用，其實並不須要強一致性。
所以犧牲 C 換取 P，這是目前分佈式數據庫產品的方向

主要是一致性與可用性的決擇

對於web2.0網站來講，關係數據庫的不少主要特性卻每每無用武之地

數據庫事務一致性需求

不少web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低， 有些場合對寫一致性要求並不高。容許實現最終一致性。

數據庫的寫實時性和讀實時性需求

對關係數據庫來講，插入一條數據以後馬上查詢，是確定能夠讀出來這條數據的，可是對於不少web應用來講，並不要求這麼高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒以後，個人訂閱者纔看到這條動態是徹底能夠接受的。

對複雜的SQL查詢，特別是多表關聯查詢的需求

任何大數據量的web系統，都很是忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種狀況的產生。每每更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。

經典 CAP 圖

CAP理論的核心是：一個分佈式系統不可能同時很好的知足一致性，可用性和分區容錯性這三個需求，
最多隻能同時較好的知足兩個。

所以，根據 CAP 原理將 NoSQL 數據庫分紅了知足 CA 原則、知足 CP 原則和知足 AP 原則三 大類：

• CA - 單點集羣，知足一致性，可用性的系統，一般在可擴展性上不太強大。
• CP - 知足一致性，分區容忍必的系統，一般性能不是特別高。
• AP - 知足可用性，分區容忍性的系統，一般可能對一致性要求低一些。
  

BASE

BASE就是爲了解決關係數據庫強一致性引發的問題而引發的可用性下降而提出的解決方案。

BASE實際上是下面三個術語的縮寫：

• 基本可用（Basically Available）
• 軟狀態（Soft state）
• 最終一致（Eventually consistent）

它的思想是經過讓系統放鬆對某一時刻數據一致性的要求來換取系統總體伸縮性和性能上改觀。爲何這麼說呢，原因就在於大型系統每每因爲地域分佈和極高性能的要求，不可能採用分佈式事務來完成這些指標，要想得到這些指標，咱們必須採用另一種方式來完成，這裏BASE就是解決這個問題的辦法