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，所以能通過輕松地添加新的節點來擴展這個集群;
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(文檔)
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)
這些數據庫對於分區容忍性方面比較不感冒，主要采用復制(Replication)這種方式來保證數據的安全性，常見的CA系統有：
1. 傳統關系型數據庫，比如Postgres和MySQL等(Relational) ;
2. Vertica (Column-oriented) ;
3. Aster Data (Relational) ;
4. Greenplum (Relational) ;
關注一致性和分區容忍性的(CP)
這種系統將數據分布在多個網絡分區的節點上，並保證這些數據的一致性，但是對於可用性的支持方面有問題，比如當集群出現問題的話，節點有可能因無法確保數據是一致性的而拒絕提供服務，主要的CP系統有：
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) ;