云計算背后的秘密(6)-NoSQL數(shù)據(jù)庫綜述
我本來一直覺得NoSQL其實很容易理解的，我本身也已經(jīng)對NoSQL有了非常深入的研究，但是在最近準(zhǔn)備YunTable的Chart的時候，發(fā)現(xiàn)NoSQL不僅非常博大精深，而且我個人對NoSQL的理解也只是皮毛而已，但我還算是一個“知恥而后勇”的人，所以經(jīng)過一段時間的學(xué)習(xí)之后，從本系列第六篇開始，就將和大家聊聊NoSQL，而本篇將主要給大家做一下NoSQL數(shù)據(jù)庫的綜述。
首先將和大家聊聊為什么NoSQL會在關(guān)系型數(shù)據(jù)庫已經(jīng)非常普及的情況下異軍突起?
誕生的原因
隨著互聯(lián)網(wǎng)的不斷發(fā)展，各種類型的應(yīng)用層出不窮，所以導(dǎo)致在這個云計算的時代，對技術(shù)提出了更多的需求，主要體現(xiàn)在下面這四個方面：
1. 低延遲的讀寫速度：應(yīng)用快速地反應(yīng)能極大地提升用戶的滿意度;
2. 支撐海量的數(shù)據(jù)和流量：對于搜索這樣大型應(yīng)用而言，需要利用PB級別的數(shù)據(jù)和能應(yīng)對百萬級的流量;
3. 大規(guī)模集群的管理：系統(tǒng)管理員希望分布式應(yīng)用能更簡單的部署和管理;
4. 龐大運營成本的考量：IT經(jīng)理們希望在硬件成本、軟件成本和人力成本能夠有大幅度地降低;
雖然關(guān)系型數(shù)據(jù)庫已經(jīng)在業(yè)界的數(shù)據(jù)存儲方面占據(jù)不可動搖的地位，但是由于其天生的幾個限制，使其很難滿足上面這幾個需求：
1. 擴展困難：由于存在類似Join這樣多表查詢機制，使得數(shù)據(jù)庫在擴展方面很艱難;
2. 讀寫慢：這種情況主要發(fā)生在數(shù)據(jù)量達到一定規(guī)模時由于關(guān)系型數(shù)據(jù)庫的系統(tǒng)邏輯非常復(fù)雜，使得其非常容易發(fā)生死鎖等的并發(fā)問題，所以導(dǎo)致其讀寫速度下滑非常嚴(yán)重;
3. 成本高：企業(yè)級數(shù)據(jù)庫的License價格很驚人，并且隨著系統(tǒng)的規(guī)模，而不斷上升;
4. 有限的支撐容量：現(xiàn)有關(guān)系型解決方案還無法支撐Google這樣海量的數(shù)據(jù)存儲;
業(yè)界為了解決上面提到的幾個需求，推出了多款新類型的數(shù)據(jù)庫，并且由于它們在設(shè)計上和傳統(tǒng)的NoSQL數(shù)據(jù)庫相比有很大的不同，所以被統(tǒng)稱為“NoSQL”系列數(shù)據(jù)庫?？偟膩碚f，在設(shè)計上，它們非常關(guān)注對數(shù)據(jù)高并發(fā)地讀寫和對海量數(shù)據(jù)的存儲等，與關(guān)系型數(shù)據(jù)庫相比，它們在架構(gòu)和數(shù)據(jù)模型方量面做了“減法”，而在擴展和并發(fā)等方面做了“加法”。現(xiàn)在主流的NoSQL數(shù)據(jù)庫有BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB和Redis等。接下來，將關(guān)注NoSQL數(shù)據(jù)庫到底存在哪些優(yōu)缺點。
#p#
優(yōu)缺點
在優(yōu)勢方面，主要體現(xiàn)在下面這三點：
1. 簡單的擴展：典型例子是Cassandra，由于其架構(gòu)是類似于經(jīng)典的P2P，所以能通過輕松地添加新的節(jié)點來擴展這個集群;
2. 快速的讀寫：主要例子有Redis，由于其邏輯簡單，而且純內(nèi)存操作，使得其性能非常出色，單節(jié)點每秒可以處理超過10萬次讀寫操作;
3. 低廉的成本：這是大多數(shù)分布式數(shù)據(jù)庫共有的特點，因為主要都是開源軟件，沒有昂貴的License成本;
但瑕不掩瑜，NoSQL數(shù)據(jù)庫還存在著很多的不足，常見主要有下面這幾個：
1. 不提供對SQL的支持：如果不支持SQL這樣的工業(yè)標(biāo)準(zhǔn)，將會對用戶產(chǎn)生一定的學(xué)習(xí)和應(yīng)用遷移成本;
2. 支持的特性不夠豐富：現(xiàn)有產(chǎn)品所提供的功能都比較有限，大多數(shù)NoSQL數(shù)據(jù)庫都不支持事務(wù)，也不像MS SQL Server和Oracle那樣能提供各種附加功能，比如BI和報表等;
3. 現(xiàn)有產(chǎn)品的不夠成熟：大多數(shù)產(chǎn)品都還處于初創(chuàng)期，和關(guān)系型數(shù)據(jù)庫幾十年的完善不可同日而語;
上面NoSQL產(chǎn)品的優(yōu)缺點都是些比較共通的，在實際情況下，每個產(chǎn)品都會根據(jù)自己所遵從的數(shù)據(jù)模型和CAP理念而有所不同，接下來，將給大家介紹NoSQL兩個最重要的概念：數(shù)據(jù)模型和CAP理念，并在本文最后，對主流的NoSQL數(shù)據(jù)庫進行分類。
#p#
數(shù)據(jù)模型
傳統(tǒng)的數(shù)據(jù)庫在數(shù)據(jù)模型方面，主要是關(guān)系型，它的特色是對Join類操作和ACID事務(wù)的支持。在NoSQL領(lǐng)域，主要有三種主流的數(shù)據(jù)模型：
Column-oriented(列式)
列式也主要使用Table這樣的模型，但是它并不支持類似Join這樣多表的操作，它的主要特點是在存儲數(shù)據(jù)時，主要圍繞著“列(Column)”，而不是像傳統(tǒng)的關(guān)系型數(shù)據(jù)庫那樣根據(jù)“行(Row)”進行存儲，也就是說，屬于同一列的數(shù)據(jù)會盡可能地存儲在硬盤同一個頁(Page)中，而不是將屬于同一個行的數(shù)據(jù)存放在一起，這樣做的好處是，對于很多類似數(shù)據(jù)倉庫(Data Warehouse)的應(yīng)用，雖然每次查詢都會處理很多數(shù)據(jù)，但是每次所涉及的列并沒有很多，這樣如果使用列式數(shù)據(jù)庫的話，將會節(jié)省大量I/O，并且大多數(shù)列式數(shù)據(jù)庫都支持Column Family這個特性，通過這個特性能將多個Column并為一個小組，這樣做好處是能將相似Column放在一起存儲，這樣能提高這些Column的存儲和查詢效率。總體而言，這種數(shù)據(jù)模型的優(yōu)點是比較適合匯總(Aggregation)和數(shù)據(jù)倉庫這類應(yīng)用。.
Key-value
雖然Key-value這種模型和傳統(tǒng)的關(guān)系型相比較簡單，有點類似常見的HashTable，一個Key對應(yīng)一個Value，但是其能提供非?？斓牟樵兯俣?、大的數(shù)據(jù)存放量和高并發(fā)操作，并非常適合通過主鍵對數(shù)據(jù)進行查詢和修改等操作，雖然不支持復(fù)雜的操作，但是可以通過上層的開發(fā)來彌補這個缺陷。
Document(文檔)
在結(jié)構(gòu)上，Document和Key-value是非常相似的，也是一個Key對應(yīng)一個Value，但是這個Value主要以JSON或者XML等格式的文檔來進行存儲，是有語義的，并且Document DB一般可以對Value來創(chuàng)建Secondary Index來方便上層的應(yīng)用，而這點是普通Key-Value DB所無法支持的。
#p#
CAP理論
這個理論是由美國著名科學(xué)家，同時也是著名互聯(lián)網(wǎng)企業(yè)Inktomi的創(chuàng)始人Eric Brewer在2000年P(guān)ODC(Symposium on Principles of Distributed Computing)大會上提出的，后來Seth Gilbert 和 Nancy lynch兩人也證明了CAP理論的正確性，雖然在后來近十年的時間很多人對CAP理論提出了很多異議，但是在NoSQL的世界中，它還是非常有參考價值的。它的意思是，一個分布式系統(tǒng)不能同時滿足一致性，可用性和分區(qū)容錯性這三個需求，最多只能同時滿足兩個。
1. 一致性(Consistency)：任何一個讀操作總是能讀取到之前完成的寫操作結(jié)果，也就是在分布式環(huán)境中，多點的數(shù)據(jù)是一致的;
2. 可用性(Availability)：每一個操作總是能夠在確定的時間內(nèi)返回，也就是系統(tǒng)隨時都是可用的。
3. 分區(qū)容忍性(Partition Tolerance)： 在出現(xiàn)網(wǎng)絡(luò)分區(qū)(比如斷網(wǎng))的情況下，分離的系統(tǒng)也能正常運行。
由于一致性、可用性和分區(qū)容忍性這三方面只能選擇兩個，所以大多數(shù)NoSQL系統(tǒng)都會根據(jù)自己的設(shè)計理念來進行相應(yīng)的選擇，但由于許多NoSQL數(shù)據(jù)庫都以水平擴展著稱，所以在CAP的選擇上面，都傾向于堅持分區(qū)容忍性，而放棄一致性或者可用性，它們的做法主要是通過消減關(guān)系型和事務(wù)相關(guān)的功能。
#p#
具體分類
下面的具體分類是來自于Visual Guide to NoSQL Systems一文，雖然對于這塊分類我個人覺得還存在一些牽強的地方，比如將能支持多種CAP配置的Dynamo和其衍生產(chǎn)品Cassandra歸類為AP，但是總體而言，這個分類還是相當(dāng)不錯，在現(xiàn)階段非常具有參考價值，在每個相關(guān)的數(shù)據(jù)庫后面還會介紹對應(yīng)的數(shù)據(jù)模型。
▲圖1. NoSQL產(chǎn)品分類圖(參考1)
關(guān)注一致性和可用性的 (CA)
這些數(shù)據(jù)庫對于分區(qū)容忍性方面比較不感冒，主要采用復(fù)制(Replication)這種方式來保證數(shù)據(jù)的安全性，常見的CA系統(tǒng)有：
1. 傳統(tǒng)關(guān)系型數(shù)據(jù)庫，比如Postgres和MySQL等(Relational) ;
2. Vertica (Column-oriented) ;
3. Aster Data (Relational) ;
4. Greenplum (Relational) ;
關(guān)注一致性和分區(qū)容忍性的(CP)
這種系統(tǒng)將數(shù)據(jù)分布在多個網(wǎng)絡(luò)分區(qū)的節(jié)點上，并保證這些數(shù)據(jù)的一致性，但是對于可用性的支持方面有問題，比如當(dāng)集群出現(xiàn)問題的話，節(jié)點有可能因無法確保數(shù)據(jù)是一致性的而拒絕提供服務(wù)，主要的CP系統(tǒng)有：
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) ;
關(guān)于可用性和分區(qū)容忍性的(AP)
這類系統(tǒng)主要以實現(xiàn)"最終一致性(Eventual Consistency)"來確保可用性和分區(qū)容忍性，AP的系統(tǒng)有：
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) ;
在下一期云計算背后的秘密中，將重點給大家介紹我個人設(shè)計一款的NoSQL數(shù)據(jù)庫，名為YunTable。
參考資料
1. Visual Guide to NoSQL Systems
2. NoSQL數(shù)據(jù)庫筆談
3. NoSQL數(shù)據(jù)庫探討之一 - 為什么要用非關(guān)系數(shù)據(jù)庫?
作者簡介
吳朱華，之前在IBM中國研究院參與過多個云計算產(chǎn)品的開發(fā)工作，現(xiàn)在專注于YunTable【http://code.google.com/p/yuntable/】和YunEngine【http://yunengine.com/】的研發(fā)，并即將發(fā)表《剖析云計算》一書，敬請期待。
【編輯推薦】
