NOSQL數據模型和CAP原理

NOSQL數據模型和CAP原理

http://blog.sina.com.cn/s/blog_7800d9210100t33v.html

我原本一直以爲NoSQL其實很容易理解的，我自己也已經對NoSQL有了很是深刻的研究，可是在最近準備YunTable的Chart的時候，發現NoSQL不只很是博大精深，並且我我的對NoSQL的理解也只是皮毛而已，但我還算是一個「知恥然後勇」的人，因此通過一段時間的學習以後，從本系列第六篇開始，就將和你們聊聊NoSQL，而本篇將主要給你們作一下NoSQL數據庫的綜述。

首先將和你們聊聊爲何NoSQL會在關係型數據庫已經很是普及的狀況下異軍突起?

誕生的緣由

隨着互聯網的不斷髮展，各類類型的應用層出不窮，因此致使在這個雲計算的時代，對技術提出了更多的需求，主要體如今下面這四個方面：

1. 低延遲的讀寫速度：應用快速地反應能極大地提高用戶的滿意度;
2. 支撐海量的數據和流量：對於搜索這樣大型應用而言，須要利用PB級別的數據和能應對百萬級的流量;
3. 大規模集羣的管理：系統管理員但願分佈式應用能更簡單的部署和管理;
4. 龐大運營成本的考量：IT經理們但願在硬件成本、軟件成本和人力成本可以有大幅度地下降;

雖然關係型數據庫已經在業界的數據存儲方面佔據不可動搖的地位，可是因爲其天生的幾個限制，使其很難知足上面這幾個需求：

1. 擴展困難：因爲存在相似Join這樣多表查詢機制，使得數據庫在擴展方面很艱難;
2. 讀寫慢：這種狀況主要發生在數據量達到必定規模時因爲關係型數據庫的系統邏輯很是複雜，使得其很是容易發生死鎖等的併發問題，因此致使其讀寫速度下滑很是嚴重;
3. 成本高：企業級數據庫的License價格很驚人，而且隨着系統的規模，而不斷上升;
4. 有限的支撐容量：現有關係型解決方案還沒法支撐Google這樣海量的數據存儲;

業界爲了解決上面提到的幾個需求，推出了多款新類型的數據庫，而且因爲它們在設計上和傳統的NoSQL數據庫相比有很大的不一樣，因此被統稱爲 「NoSQL」系列數據庫。總的來講，在設計上，它們很是關注對數據高併發地讀寫和對海量數據的存儲等，與關係型數據庫相比，它們在架構和數據模型方量面作了「減法」，而在擴展和併發等方面作了「加法」。如今主流的NoSQL數據庫有BigTable、HBase、Cassandra、SimpleDB、 CouchDB、MongoDB和Redis等。接下來，將關注NoSQL數據庫到底存在哪些優缺點。

優缺點

在優點方面，主要體如今下面這三點：

1. 簡單的擴展：典型例子是Cassandra，因爲其架構是相似於經典的P2P，因此能經過輕鬆地添加新的節點來擴展這個集羣;

2. 快速的讀寫：主要例子有Redis，因爲其邏輯簡單，並且純內存操做，使得其性能很是出色，單節點每秒能夠處理超過10萬次讀寫操做;
3. 低廉的成本：這是大多數分佈式數據庫共有的特色，由於主要都是開源軟件，沒有昂貴的License成本;

但瑕不掩瑜，NoSQL數據庫還存在着不少的不足，常見主要有下面這幾個：

1. 不提供對SQL的支持：若是不支持SQL這樣的工業標準，將會對用戶產生必定的學習和應用遷移成本;
2. 支持的特性不夠豐富：現有產品所提供的功能都比較有限，大多數NoSQL數據庫都不支持事務，也不像MS SQL Server和Oracle那樣能提供各類附加功能，好比BI和報表等;
3. 現有產品的不夠成熟：大多數產品都還處於初創期，和關係型數據庫幾十年的完善不可同日而語;

上面NoSQL產品的優缺點都是些比較共通的，在實際狀況下，每一個產品都會根據本身所聽從的數據模型和CAP理念而有所不一樣，接下來，將給你們介紹NoSQL兩個最重要的概念：數據模型和CAP理念，並在本文最後，對主流的NoSQL數據庫進行分類。

數據模型

傳統的數據庫在數據模型方面，主要是關係型，它的特點是對Join類操做和ACID事務的支持。在NoSQL領域，主要有三種主流的數據模型：

Column-oriented(列式)

列式也主要使用Table這樣的模型，可是它並不支持相似Join這樣多表的操做，它的主要特色是在存儲數據時，主要圍繞着「列(Column)」，而不是像傳統的關係型數據庫那樣根據「行(Row)」進行存儲，也就是說，屬於同一列的數據會盡量地存儲在硬盤同一個頁(Page)中，而不是將屬於同一個行的數據存放在一塊兒，這樣作的好處是，對於不少相似數據倉庫(Data Warehouse)的應用，雖然每次查詢都會處理不少數據，可是每次所涉及的列並無不少，這樣若是使用列式數據庫的話，將會節省大量I/O，而且大多數列式數據庫都支持Column Family這個特性，經過這個特性能將多個Column併爲一個小組，這樣作好處是能將類似Column放在一塊兒存儲，這樣能提升這些Column的存儲和查詢效率。整體而言，這種數據模型的優勢是比較適合彙總(Aggregation)和數據倉庫這類應用。.

Key-value

雖然Key-value這種模型和傳統的關係型相比較簡單，有點相似常見的HashTable，一個Key對應一個Value，可是其能提供很是快的查詢速度、大的數據存放量和高併發操做，並不是常適合經過主鍵對數據進行查詢和修改等操做，雖然不支持複雜的操做，可是能夠經過上層的開發來彌補這個缺陷。

Document(文檔)

在結構上，Document和Key-value是很是類似的，也是一個Key對應一個Value，可是這個Value主要以JSON或者XML等格式的文檔來進行存儲，是有語義的，而且Document DB通常能夠對Value來建立Secondary Index來方便上層的應用，而這點是普通Key-Value DB所沒法支持的。

CAP理論

這個理論是由美國著名科學家，同時也是著名互聯網企業Inktomi的創始人Eric Brewer在2000年PODC(Symposium on Principles of Distributed Computing)大會上提出的，後來Seth Gilbert 和 Nancy lynch兩人也證實了CAP理論的正確性，雖然在後來近十年的時間不少人對CAP理論提出了不少異議，可是在NoSQL的世界中，它仍是很是有參考價值的。它的意思是，一個分佈式系統不能同時知足一致性，可用性和分區容錯性這三個需求，最多隻能同時知足兩個。

1. 一致性(Consistency)：任何一個讀操做老是能讀取到以前完成的寫操做結果，也就是在分佈式環境中，多點的數據是一致的;
2. 可用性(Availability)：每個操做老是可以在肯定的時間內返回，也就是系統隨時都是可用的。
3. 分區容忍性(Partition Tolerance)： 在出現網絡分區(好比斷網)的狀況下，分離的系統也能正常運行。

因爲一致性、可用性和分區容忍性這三方面只能選擇兩個，因此大多數NoSQL系統都會根據本身的設計理念來進行相應的選擇，但因爲許多NoSQL數據庫都以水平擴展著稱，因此在CAP的選擇上面，都傾向於堅持分區容忍性，而放棄一致性或者可用性，它們的作法主要是經過消減關係型和事務相關的功能。

具體分類

下面的具體分類是來自於Visual Guide to NoSQL Systems一文，雖然對於這塊分類我我的以爲還存在一些牽強的地方，好比將能支持多種CAP配置的Dynamo和其衍生產品Cassandra歸類爲 AP，可是整體而言，這個分類仍是至關不錯，在現階段很是具備參考價值，在每一個相關的數據庫後面還會介紹對應的數據模型。

▲圖1. NoSQL產品分類圖(參考1)

關注一致性和可用性的 (CA)

這些數據庫對於分區容忍性方面比較不感冒，主要採用複製(Replication)這種方式來保證數據的安全性，常見的CA系統有：

1. 傳統關係型數據庫，好比Postgres和MySQL等(Relational) ;
2. Vertica (Column-oriented) ;
3. Aster Data (Relational) ;
4. Greenplum (Relational) ;

關注一致性和分區容忍性的(CP)

這種系統將數據分佈在多個網絡分區的節點上，並保證這些數據的一致性，可是對於可用性的支持方面有問題，好比當集羣出現問題的話，節點有可能因沒法確保數據是一致性的而拒絕提供服務，主要的CP系統有：

1. BigTable (Column-oriented) ;2. Hypertable (Column-oriented);3. HBase (Column-oriented) ;4. MongoDB (Document) ;5. Terrastore (Document) ;6. Redis (Key-value) ;7. Scalaris (Key-value) ;8. MemcacheDB (Key-value) ;9. Berkeley DB (Key-value) ;關於可用性和分區容忍性的(AP)這類系統主要以實現"最終一致性(Eventual Consistency)"來確保可用性和分區容忍性，AP的系統有：1. Dynamo (Key-value);2. Voldemort (Key-value) ;3. Tokyo Cabinet (Key-value) ;4. KAI (Key-value) ;5. Cassandra (Column-oriented) ;6. CouchDB (Document-oriented) ;7. SimpleDB (Document-oriented) ;8. Riak (Document-oriented) ;