怎樣理解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

 

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM