nosql特點：1、靈活的可擴展性；nosql去掉了關系數據庫的關系型特性，數據之間無關系，很簡單就能夠擴展。2、靈活的數據模型；NoSQL采用鍵/值、列族等非關系模型，允許在一個數據元素里存儲不同類型的數據。3、NoSQL可以憑借自身良好的橫向擴展能力，充分自由利用云計算基礎設施，很好地融人到云計算環境中。4、nosql有著非常高的讀寫性能，特別是在大數據量之下。5、高可用。

千萬級數據并發如何處理？進入學習

本教程操作環境：windows7系統、Dell G3電腦。

NoSQL簡介

NoSQL是一種不同于關系數據庫的數據庫管理系統設計方式，是對非關系型數據庫的統稱，它所采用的數據模型并非傳統關系數據庫的關系模型，而是類似鍵/值、列族、文檔等非關系模型。NoSQL數據庫沒有固定的表結構，通常也不存在連接操作，也沒有嚴格遵守ACID約束。因此，與關系數據庫相比，NoSQL具有靈活的水平可擴展性，可以支持海量數據存儲。

什么是ACID?

• 事務的原子性(Atomicity)：是指一個事務要么全部執行，要么不執行，也就是說一個事務不可能只執行了一半就停止了。比如你從取款機取錢，這個事務可以分成兩個步驟：1劃卡，2出錢。不可能劃了卡，而錢卻沒出來。這兩步必須同時完成，要么就不完成。
• 事務的一致性(Consistency)：是指事務的運行并不改變數據庫中數據的一致性。例如，完整性約束了a+b=10，一個事務改變了a，那么b也應該隨之改變。
• 獨立性(Isolation）：事務的獨立性也有稱作隔離性，是指兩個以上的事務不會出現交錯執行的狀態。因為這樣可能會導致數據不一致。
• 持久性(Durability）：事務的持久性是指事務執行成功以后，該事務對數據庫所作的更改便是持久的保存在數據庫之中，不會無緣無故的回滾

NoSQL數據庫的特點

（1）靈活的可擴展性

傳統的關系型數據庫由于自身設計機理的原因，通常很難實現“橫向擴展”，在面對數據庫負載大規模增加時，往往需要通過升級硬件來實現“縱向擴展”。NoSQL數據庫在設計之初就是為了滿足“橫向擴展”的需求，因此天生具備良好的水平擴展能力。

（2）靈活的數據模型

關系數據庫具有規范的定義，遵守各種嚴格的約束條件。這種做法雖然保證了業務系統對數據一致性的需求，但是過于死板的數據模型，也意味著無法滿足各種新興的業務需求。相反，NoSQL數據庫采用鍵/值、列族等非關系模型，允許在一個數據元素里存儲不同類型的數據。

（3）與云計算緊密融合

云計算具有很好的水平擴展能力，可以根據資源使用情況進行自由伸縮，各種資源可以動態加人或退出，NoSQL數據庫可以憑借自身良好的橫向擴展能力，充分自由利用云計算基礎設施，很好地融人到云計算環境中，構建基于NoSQL的云數據庫服務。

（4）大數據量，高性能

nosql數據庫都有著非常高的讀寫性能，特別是在大數據量之下，一樣也表現的非常的優秀，這主要得益于它的無關系性，數據庫的結構簡單。

通常的nosql使用Query Cache。

nosql的Cache是記錄級的，是一種細粒度的Cache，所以說，nosql從這個方面來說的話，性能就要高了很多了。

（5）高可用

高可用也是nosql很明顯的一個特點，nosql在不太影響性能的情況之下，就能夠非常方便的實現高可用的架構，典型的例如：Cassandra、HBase模型，通過模型的話也可以實現高可用。

NoSQL興起的原因

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

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

• 對于上述網站而言，很快就可以產生超過10億條的記錄，對于關系數據庫來說，在一張10億條記錄的表里進行SQL查詢，效率極其低下。

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

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

2、關系數據庫的關鍵特性在Web 2.0時代成為“雞肋”

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

（1） Web 2.0網站系統通常不要求嚴格的數據庫事務

對于許多Web 2.0網站而言，數據庫事務已經不是那么重要。數據庫事務通常有一套復雜的實現機制來保證數據庫一致性，需要大量系統開銷，對于包含大量頻繁實時讀寫請求的Web 2.0網站而言，實現事務的代價是難以承受的。

（2）Web 2.0并不要求嚴格的讀寫實時性

對于關系數據庫而言，一旦有一條數據記錄成功插人數據庫中，就可以立即被查詢。

對于Web 2.0而言，沒有這種實時讀寫需求。

（3）Web 2.0通常不包含大量復雜的SQL查詢

復雜的SQL查詢通常包含多表連接操作。但是，Web 2.0網站在設計時就已經盡量減少甚至避免這類操作，通常只采用單表的主鍵查詢，因此關系數據庫的查詢優化機制在Web 2.0中也就難以有所作為。

NoSQL與關系數據庫的比較

RDBMS：關系數據庫

NoSQL與關系數據庫比較 小結：

（1）關系數據庫

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

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

（2）NoSQL數據庫

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

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

（3）關系數據庫和NoSQL數據庫各有優缺點，彼此無法取代

關系數據庫應用場景：電信、銀行等領域的關鍵業務系統，需要保證強事務一致性

NoSQL數據庫應用場景：互聯網企業、傳統企業的非關鍵業務（比如數據分析）

采用混合架構

• 案例：亞馬遜公司就使用不同類型的數據庫來支撐它的電子商務應用
• 對于“購物籃”這種臨時性數據，采用鍵值存儲會更加高效
• 當前的產品和訂單信息則適合存放在關系數據庫中

NoSQL的四大類型

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

1.鍵值數據庫

鍵值數據庫(Key-Value Database) 的表中有一個特定的Key和一個指針指向特定的Value。Key可以用來定位Value，即存儲和檢索具體的Value。Value對數據庫而言是透明不可見的，不能對Value進行索引和查詢，只能通過Key進行查詢。Value可以用來存儲任意類型的數據，包括整型、字符型、數組、對象等。

應用場景:一個面向會話的應用程序（如 Web 應用程序）在用戶登錄時啟動會話，并保持活動狀態直到用戶注銷或會話超時。在此期間，應用程序將所有與會話相關的數據存儲在主內存或數據庫中。會話數據可能包括用戶資料信息、消息、個性化數據和主題、建議、有針對性的促銷和折扣。每個用戶會話具有唯一的標識符。除了主鍵之外，任何其他鍵都無法查詢會話數據，因此快速鍵值存儲更適合于會話數據。一般來說，鍵值數據庫所提供的每頁開銷可能比關系數據庫要小。

2.列族數據庫

3.文檔數據庫

4.圖形數據庫

5.不同類型數據庫比較分析

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

NoSQL的三大基石

所謂的CAP指的是：

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

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

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

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

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

• AP：也就是強調可用性（A）和分區容忍性（P），放棄一致性（C），允許系統返回不一致的數據

BASE

前面說到ACID ，現在淺談一下BASE（Basically Availble, Soft-state, Eventual consistency）

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

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

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

最終一致性

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