NoSQL資料庫

1、NoSQL簡介

最初表示“反SQL”運動，用新型的非關係型資料庫取代關係資料庫；現在表示“Not only SQL”關係和非關係型資料庫各有優缺點，彼此都無法互相取代。

通常，NoSQL資料庫具有以下幾個特點：

（1）靈活的可擴展性

（2）靈活的數據模型

（3）與雲計算近緊密融合

2、NoSQL興起的原因

1.關係資料庫已經無法滿足Web2.0的需求。主要表現在以下幾個方面：

（1）無法滿足海量數據的管理需求

（2）無法滿足數據高併發的需求

（3）無法滿足高可擴展性和高可用性的需求

MySQL集群是否可以完全解決問題？

• 複雜性：部署、管理、配置很複雜
• 資料庫複製：MySQL主備份之間採用複製方式，只能是非同步複製，當主庫壓力較大時可能產生較大延遲，主備切換可能會對視最後一部分更新事務，這時往往需要人工介入，備份和恢復不方便
• 擴容問題：如果系統壓力過大需要增加新的機器，這個過程涉及數據重新劃分，整個過程比較複雜，且容易出錯
• 動態資料庫遷移問題：如果某個資料庫組壓力過大，需要將其中部分數據遷移出去，遷移過程需要總控節點整體協調，以及資料庫節點的配合。這個過程很難做到自動化

2.“One size fits all”模式很難適用於截然不同的業務場景

• 關係模型作為統一的數據模型即被用於數據分析，也被用於線上業務。但這兩者一個強調高吞吐，一個強調低時延，已經演化出不同的架構。用同一套模型來抽象顯然是不合適的
• Hadoop就是針對數據分析
• MongoDB、Redis等是針對線上業務，兩者都拋棄了關係模型

3.關係資料庫的關鍵特性包括完善的事務機制和高效的查詢機制。但是，關係資料庫引以為傲的兩個特性，到了Web2.0時代卻成了雞肋，主要表現在以下幾個方面：

（1）Web2.0網站系統通常不要求嚴格的資料庫事務

（2）Web2.0並不要求嚴格的讀寫實時性

（3）Web2.0通常不包含大量複雜的SQL查詢（去結構化，避免多表查詢，存儲空間換取更好的查詢性能）

3、NoSQL與關係資料庫的比較

NoSQL和關係資料庫的簡單比較

總結：

（1）關係資料庫

優勢：以完善的關係代數理論作為基礎，有嚴格的標準，支持事務ACID四性，藉助索引機制可以實現高效的查詢，技術成熟，有專業公司的技術支持。

劣勢：可擴展性較差，無法較好支持海量數據存儲，數據模型過於死板、無法較好支持Web2.0應用，事務機制影響了系統的整體性能等。

（2）NoSQL資料庫

優勢：可以支持超大規模數據存儲，靈活的數據模型可以很好地支持Web2.0應用，具有強大的橫向擴展能力等。

劣勢：缺乏數學理論基礎，複雜查詢性能不高，大都不能實現事務強一致性，很難實現數據完整性，技術尚不成熟，缺乏專業團隊的技術支持，維護較困難等。

關係資料庫和NoSQL資料庫各有優缺點，彼此無法取代

• 關係資料庫應用場景：電信、銀行等領域的關鍵業務系統，需要保證強事務一致性
• NoSQL資料庫應用場景：互聯網企業、傳統企業的非關鍵業務（比如數據分析）

採用混合架構：

案例：亞馬遜公司就使用不同類型的資料庫來支撐它的電子商務應用

對於“購物籃”這種臨時性數據，採用鍵值存儲會更加高效； 當前的產品和訂單信息則適合存放在關係資料庫中； 大量的歷史訂單信息則適合保存在類似MongoDB的文檔資料庫中

4、NoSQL的四大類型

NoSQL資料庫雖然數量眾多，但是，歸結起來，典型的NoSQL資料庫通常包括鍵值資料庫、列族資料庫、文檔資料庫和圖形資料庫。

• 文檔資料庫：MarkLogic、Couchbase、mongoDB
• 圖形資料庫：Neo4j、InfiniteGraph
• 鍵值資料庫：redis、Amazon DynamoDB、riak
• 列族資料庫：HYPERTABLE、accumulo、HBASE、Amazon SimpleDB

1.鍵值資料庫

鍵值資料庫成為理想的緩衝層解決方案。 Redis有時候會被人們稱為“強化版的Memcached”支持持久化、數據恢復、更多數據類型。

2.列族資料庫

3.文檔資料庫

“文檔”其實是一個數據記錄，這個記錄能夠對包含的數據類型和內容進行“自我描述”。XML文檔、HTML文檔和JSON文檔就屬於這一類。SequoiaDB就是使用JSON文檔格式的文檔資料庫，它的存儲的數據是這樣的：

{
    "ID" : 1,
    "NAME" : "SequoiaDB",
    "Tel" : {
        "Office" : "123123" , "Mobile" : "132132132"
        }
    "Addr" : "China,GZ"
}

• 數據是不規則的，每一條記錄包含了所有的有關“SequoiaDB”的信息而沒有任何外部的引用，這條記錄就是“自包含”的
• 這使得記錄很容易完全移動到其他伺服器，因為這條記錄的所有信息都包含在裡面了，不需要考慮還有信息在別的表沒有一起遷移走
• 同時，因為在移動過程中，只有被移動的那一條記錄（文檔）需要操作，而不像關係型中每個有關聯的表都需要鎖住來保證一致性，這樣一來ACID的保證就會變得更快速，讀寫的速度也會有很大的提升

4.圖形資料庫

不同類型資料庫比較分析

• MySQL產生年代較早，而且隨著LAMP大潮得以成熟。儘管其沒有什麼大的改進，但是新興的互聯網使用的最多的資料庫
• MongoDB是個新生事物，提供更靈活的數據模型、非同步提交、地理位置索引等五花十色的功能
• HBase是個“仗勢欺人”的大象兵。依仗著Hadoop的生態環境，可以有很好的擴展性。但是就像象兵一樣，使用者需要養一頭大象（Hadoop），才能驅使他
• Redis<是鍵值存儲的代表，功能最簡單。提供隨機數據存儲。就像一根棒子一樣，沒有多餘的構造。但是也正是因此，它的伸縮性特別好。就像悟空手裡的金箍棒，大可捅破天，小能縮成針。

5、NoSQL的三大基石

CAP、最終一致性、BASE

CAP指的是：

• C（Consistency）：一致性，是指任何一個讀操作總是能夠讀到之前完成的寫操作的結果，也就是在分散式環境中，多點的數據是一致的，或者說，所有節點在同一時間具有相同的數據；
• A（Availability）：可用性，是指快速獲取數據，可以在確定的時間內返回操作結果，保證每個請求不管成功或者失敗都有響應；
• P（Tolerance of Network Partition）：分區容忍性，是指當出現網路分區的情況時（即系統中的一部分節點無法和其他節點進行通行），分離的系統也能夠正常運行，也就是說，系統中任意信息的丟失或失敗不會影響系統

CAP理論告訴我們，一個分散式系統不可能同時滿足一致性、可用性和分區容忍性這三個需求，最多只能同時滿足其中兩個，正所謂“魚和熊掌不可兼得”。

當處理CAP的問題時，可以有幾個明顯的選擇：

1.CA：也就是強調一致性（C）和可用性（A），放棄分區容忍性（P），最簡單的做法是把所有與事務相關的內容都放到同一臺機器上。很顯然，這種做法會嚴重影響系統的可擴展性。傳統的關係型資料庫（MySQL、SQL Server和PostgreSQL），都採用了這種設計原則，因此，擴展性都比較差。

2.CP：也就是強調一致性（C）和分區容忍性（P），放棄可用性（A），當出現網路分區的情況時，受影響的服務需要等待數據一致，因此在等待期間就無法對外提供服務（Neo4J、Bigtable、MongoDB、Hbase、Hypertable、Redis）

3.AP：也就是強調可用性（A）和分區容忍性（P），放棄一致性（C），允許系統返回不一致的數據（Dynamo、Cassandar、Voldemort、CouchDB、Riak） BASE（Basically Availble,Soft-state,Eventual consistency）

一個資料庫事務具有ACID四性：

BASE的基本含義是基本可用（Basically Availble）軟狀態（Soft-state）和最終一致性（Eventual consistency）：

基本可用：

基本可用，是指一個分散式系統的一部分發生問題變得不可用時，其他部分仍然可以正常使用，也就是允許分區失敗的情形出現

軟狀態：

“軟狀態（soft-state）”是與“硬狀態（hard-state）”相對應的一種提法。資料庫保存的數據是“硬狀態”時，可以保證數據一致性，即保證數據一直是正確的。“軟狀態”是指狀態可以有一段時間不同步，具有一定滯後性

最終一致性：

一致性的類型包括強一致性和弱一致性，二者的主要區別在於高併發的數據訪問操作下，後續操作是否能夠獲取最新的數據。對於強一致性而言，當執行完一次更新操作後，後續的其他讀操作就可以保證讀到更新後的最新數據；反之，如果不能保證後續訪問讀到的都是更新後的最新數據，那麼就是弱一致性。而最終一致性只不過是弱一致性的一種特例，允許後續的訪問操作可以暫時讀不到更新後的數據，但是經過一段時間之後，必須最終讀到更新後的數據。

最常見的實現最終一致性的系統是DNS（功能變數名稱系統）。一個功能變數名稱更新操作根據配置形式被分發出去，並結合有過期機制的緩存；最終所有的客戶端可以看到最新的值。

最終一致性根據更新數據後各進程訪問到數據的時間和方式的不同，又可以區分為：

 因果一致性：如果進程A通知進程B它已更新了一個數據項，那麼進程B的後續訪問將獲得A寫入的最新值。而與進程A無因果關係的進程C的訪問，仍然遵守一般的最終一致性規則

 “讀己之所寫”一致性：可以視為因果一致性的一個特例。當進程A自己執行一個更新操作之後，它自己總是可以訪問到更新過的值，絕不會看到舊值

 單調讀一致性：如果進程已經看到過數據對象的某個值，那麼任何後續訪問都不會返回在那個值之前的值

 會話一致性：它把訪問數據系統的進程放到會話（session）的上下文中，只要會話還存在，系統就保證“讀己之所寫”一致性。如果由於某些失敗情形令會話終止，就要建立新的會話，而且系統保證不會延續到新的會話

 單調寫一致性：系統保證來自同一個進程的寫操作順序執行。系統必須保證這種程式的一致性，否則就非常難以編程了

如何實現各種類型的一致性？

對於分散式數據系統：

• N ： 數據複製的份數
• W ： 更新數據是需要保證寫完成的節點數
• R ： 讀取數據的時候需要讀取的節點數

如果 W+R > N ，寫的節點和讀的節點重疊，則是強一致性，例如對於典型的一主一備同步複製的關係型資料庫，N=2，W=2，R=1，則不管讀的是主庫還是備庫的數據，都是一致的。一般設定是 R+W = N+1 ，這是保證強一致性的最小設定

如果 W+R <= N，則是弱一致性。例如對於一主一備非同步複製的關係型資料庫，N=2， W=1，R=1，則如果讀的是備庫，就可以無法讀取主庫已經更新過的數據，所以是弱一致性。

對於分散式系統，為了保證高可用性，一般設置N >= 3。不同的N，W，R組合，是在可用性和一致性之間取一個平衡，以適應不同的應用場景。

如果N=W，R=1，任何一個寫節點失效，都會導致寫失敗，因此可用性會降低，但是由於數據分佈的N個節點是同步寫入的，因此可以保證強一致性。

實例：HBASE是藉助其底層的HDFS來實現其數據冗餘備份的。HDFS採用的就是強一致性保證。在數據沒有完全同步到N個節點前，寫操作是不會返回成功的。也就是說它的W=N，而讀操作只需要讀到一個值即可，也就是說它R=1。

像Voldemort，Cassandra和Riak這些類Dynamo的系統，通常都允許用戶按需要設置N，R，W三個值，即使是設置成W+R <= N也是可以的。也就是說他允許用戶在強一致性和最終一致性之間自由選擇。而在用戶選擇了最終一致性，或者是W < N的強一致性時，則總會出現一段“各個節點數據不同步導致系統處理不一致的時間”。為了提供最終一致性的支持，這些系統會提供一些工具來使數據更新被最終同步到所有的相關節點。

6、從NoSQL到NewSQL資料庫

針對不同的應用採用不同的資料庫，使用OldSQL支持事務處理，使用NoSQL支持互聯網應用，NewSQL同時具備關係型資料庫和NoSQL資料庫的優點。