paulwong

摘取了一部分，全文請(qǐng)查看

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

背景

“這是最好的時(shí)代，也是最壞的時(shí)代。” 

每個(gè)時(shí)代的人都在這么形容自己所處的時(shí)代。在一次次IT浪潮下面，有人覺得當(dāng)下乏味無聊，有人卻能銳意進(jìn)取，找到突破。數(shù)據(jù)存儲(chǔ)這個(gè)話題自從有了計(jì)算機(jī)之后，就一直是一個(gè)有趣或者無聊的主題。上世紀(jì)七十年代，關(guān)系數(shù)據(jù)庫理論的出現(xiàn)，造就了一批又一批傳奇，并推動(dòng)整個(gè)世界信息化到了一個(gè)新的高度。而進(jìn)入新千年以來，隨著SNS等應(yīng)用的出現(xiàn)，傳統(tǒng)的SQL數(shù)據(jù)庫已經(jīng)越來越不適應(yīng)海量數(shù)據(jù)的處理了。于是，這幾年NoSQL數(shù)據(jù)庫的呼聲也越來越高。

在NoSQL數(shù)據(jù)庫當(dāng)中，呼聲最高的是HBase和Cassandra兩個(gè)。雖然嚴(yán)格意義上來說，兩者服務(wù)的目的有所不同，側(cè)重點(diǎn)也不盡相同，但是作為當(dāng)前開源NoSQL數(shù)據(jù)庫的佼佼者，兩者經(jīng)常被用來做各種比較。

去年十月，F(xiàn)acebook推出了他的新的Message系統(tǒng)。Facebook宣布他們采用HBase作為后臺(tái)存儲(chǔ)系統(tǒng)。這引起了一片喧嘩聲。因?yàn)镃assandra恰恰是Facebook開發(fā)，并且于2008年開源。這讓很多人驚呼，是否是Cassandra已經(jīng)被Facebook放棄了？HBase在這場NoSQL數(shù)據(jù)庫的角力當(dāng)中取得了決定性的勝利？本文打算主要從技術(shù)角度分析，HBase和Cassandra的異同，并非要給出任何結(jié)論，只是共享自己研究的一些結(jié)果。

選手簡介

HBase

HBase是一個(gè)開源的分布式存儲(chǔ)系統(tǒng)。他可以看作是Google的Bigtable的開源實(shí)現(xiàn)。如同Google的Bigtable使用Google File System一樣，HBase構(gòu)建于和Google File System類似的Hadoop HDFS之上。

Cassandra

Cassandra可以看作是Amazon Dynamo的開源實(shí)現(xiàn)。和Dynamo不同之處在于，Cassandra結(jié)合了Google Bigtable的ColumnFamily的數(shù)據(jù)模型。可以簡單地認(rèn)為，Cassandra是一個(gè)P2P的，高可靠性并具有豐富的數(shù)據(jù)模型的分布式文件系統(tǒng)。

分布式文件系統(tǒng)的指標(biāo)

根據(jù)UC Berkeley的教授Eric Brewer于2000年提出猜測- CAP定理，一個(gè)分布式計(jì)算機(jī)系統(tǒng)，不可能同時(shí)滿足以下三個(gè)指標(biāo)：

Brewer教授推測，任何一個(gè)系統(tǒng)，同時(shí)只能滿足以上兩個(gè)指標(biāo)。

在2002年，MIT的Seth Gilbert和Nancy Lynch發(fā)表正式論文論證了CAP定理。

而HBase和Cassandra兩者都屬于分布式計(jì)算機(jī)系統(tǒng)。但是其設(shè)計(jì)的側(cè)重點(diǎn)則有所不同。HBase繼承于Bigtable的設(shè)計(jì)，側(cè)重于CA。而Cassandra則繼承于Dynamo的設(shè)計(jì)，側(cè)重于AP。

特性比較

由于HBase和Cassandra的數(shù)據(jù)模型比較接近，所以這里就不再比較兩者之間數(shù)據(jù)模型的異同了。接下來主要比較雙方在數(shù)據(jù)一致性、多拷貝復(fù)制的特性。

HBase

HBase保證寫入的一致性。當(dāng)一份數(shù)據(jù)被要求復(fù)制N份的時(shí)候，只有N份數(shù)據(jù)都被真正復(fù)制到N臺(tái)服務(wù)器上之后，客戶端才會(huì)成功返回。如果在復(fù)制過程中出現(xiàn)失敗，所有的復(fù)制都將失敗。連接上任何一臺(tái)服務(wù)器的客戶端都無法看到被復(fù)制的數(shù)據(jù)。HBase提供行鎖，但是不提供多行鎖和事務(wù)。HBase基于HDFS，因此數(shù)據(jù)的多份復(fù)制功能和可靠性將由HDFS提供。HBase和MapReduce天然集成。

Cassandra

寫入的時(shí)候，有多種模式可以選擇。當(dāng)一份數(shù)據(jù)模式被要求復(fù)制N份的時(shí)候，可以立即返回，可以成功復(fù)制到一個(gè)服務(wù)器之后返回，可以等到全部復(fù)制到N份服務(wù)器之后返回，還可以設(shè)定一個(gè)復(fù)制到quorum份服務(wù)器之后返回。Quorum后面會(huì)有具體解釋。復(fù)制不會(huì)失敗。最終所有節(jié)點(diǎn)數(shù)據(jù)都將被寫入。而在未被完全寫入的時(shí)間間隙，連接到不同服務(wù)器的客戶端有可能讀到不同的數(shù)據(jù)。在集群里面，所有的服務(wù)器都是等價(jià)的。不存在任何一個(gè)單點(diǎn)故障。節(jié)點(diǎn)和節(jié)點(diǎn)之間通過Gossip協(xié)議互相通信。寫入順序按照timestamp排序，不提供行鎖。新版本的Cassandra已經(jīng)集成了MapReduce了。

相對(duì)于配置Cassandra，配置HBase是一個(gè)艱辛、復(fù)雜充滿陷阱的工作。Facebook關(guān)于為何采取HBase，里面有一句，大意是，F(xiàn)acebook長期以來一直關(guān)注HBase的開發(fā)并且有一只專門的經(jīng)驗(yàn)豐富的HBase維護(hù)的team來負(fù)責(zé)HBase的安裝和維護(hù)。可以想象，F(xiàn)acebook內(nèi)部關(guān)于使用HBase和Cassandra有過激烈的斗爭，最終人數(shù)更多的HBase team占據(jù)了上風(fēng)。對(duì)于大公司來說，養(yǎng)一只相對(duì)龐大的類似DBA的team來維護(hù)HBase不算什么大的開銷，但是對(duì)于小公司，這實(shí)在不是一個(gè)可以負(fù)擔(dān)的起的開銷。

另外HBase在高可靠性上有一個(gè)很大的缺陷，就是HBase依賴HDFS。HDFS是Google File System的復(fù)制品，NameNode是HDFS的單點(diǎn)故障點(diǎn)。而到目前為止，HDFS還沒有加入NameNode的自我恢復(fù)功能。不過我相信，F(xiàn)acebook在內(nèi)部一定有恢復(fù)NameNode的手段，只是沒有開源出來而已。

相反，Cassandra的P2P和去中心化設(shè)計(jì)，沒有可能出現(xiàn)單點(diǎn)故障。從設(shè)計(jì)上來看，Cassandra比HBase更加可靠。

關(guān)于數(shù)據(jù)一致性，實(shí)際上，Cassandra也可以以犧牲響應(yīng)時(shí)間的代價(jià)來獲得和HBase一樣的一致性。而且，通過對(duì)Quorum的合適的設(shè)置，可以在響應(yīng)時(shí)間和數(shù)據(jù)一致性得到一個(gè)很好的折衷值。

主要表現(xiàn)在：

配置簡單，不需要多模塊協(xié)同操作。功能靈活性強(qiáng)，數(shù)據(jù)一致性和性能之間，可以根據(jù)應(yīng)用不同而做不同的設(shè)置。 可靠性更強(qiáng)，沒有單點(diǎn)故障。

盡管如此，Cassandra就沒有弱點(diǎn)嗎？當(dāng)然不是，Cassandra有一個(gè)致命的弱點(diǎn)。

這就是存儲(chǔ)大文件。雖然說，Cassandra的設(shè)計(jì)初衷就不是存儲(chǔ)大文件，但是Amazon的S3實(shí)際上就是基于Dynamo構(gòu)建的，總是會(huì)讓人想入非非地讓Cassandra去存儲(chǔ)超大文件。而和Cassandra不同，HBase基于HDFS，HDFS的設(shè)計(jì)初衷就是存儲(chǔ)超大規(guī)模文件并且提供最大吞吐量和最可靠的可訪問性。因此，從這一點(diǎn)來說，Cassandra由于背后不是一個(gè)類似HDFS的超大文件存儲(chǔ)的文件系統(tǒng)，對(duì)于存儲(chǔ)那種巨大的（幾百T甚至P）的超大文件目前是無能為力的。而且就算由Client手工去分割，這實(shí)際上是非常不明智和消耗Client CPU的工作的。

因此，如果我們要構(gòu)建一個(gè)類似Google的搜索引擎，最少，HDFS是我們所必不可少的。雖然目前HDFS的NameNode還是一個(gè)單點(diǎn)故障點(diǎn)，但是相應(yīng)的Hack可以讓NameNode變得更皮實(shí)。基于HDFS的HBase相應(yīng)地，也更適合做搜索引擎的背后倒排索引數(shù)據(jù)庫。事實(shí)上，Lucene和HBase的結(jié)合，遠(yuǎn)比Lucene結(jié)合Cassandra的項(xiàng)目Lucandra要順暢和高效的多。（Lucandra要求Cassandra使用OrderPreservingPartitioner,這將可能導(dǎo)致Key的分布不均勻，而無法做負(fù)載均衡，產(chǎn)生訪問熱點(diǎn)機(jī)器）。

所以我的結(jié)論是，在這個(gè)需求多樣化的年代，沒有贏者通吃的事情。而且我也越來越不相信在工程界存在一勞永逸和一成不變的解決方案。當(dāng)你僅僅是存儲(chǔ)海量增長的消息數(shù)據(jù)，存儲(chǔ)海量增長的圖片，小視頻的時(shí)候，你要求數(shù)據(jù)不能丟失，你要求人工維護(hù)盡可能少，你要求能迅速通過添加機(jī)器擴(kuò)充存儲(chǔ)，那么毫無疑問，Cassandra現(xiàn)在是占據(jù)上風(fēng)的。

但是如果你希望構(gòu)建一個(gè)超大規(guī)模的搜索引擎，產(chǎn)生超大規(guī)模的倒排索引文件（當(dāng)然是邏輯上的文件，真實(shí)文件實(shí)際上被切分存儲(chǔ)于不同的節(jié)點(diǎn)上），那么目前HDFS+HBase是你的首選。

就讓這個(gè)看起來永遠(yuǎn)正確的結(jié)論結(jié)尾吧，上帝的歸上帝，凱撒的歸凱撒。大家都有自己的地盤，野百合也會(huì)有春天的！