原文: http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/
原作者：Dominic Williams
原文發(fā)布日期：February 24, 2010 at 7:27 pm
譯者：王旭（http://wangxu.me/blog/ , @gnawux）
翻譯時(shí)間：2010年3月21-25日

我的團(tuán)隊(duì)近來正在忙于一個(gè)全新的產(chǎn)品——即將發(fā)布的網(wǎng)絡(luò)游戲 www.FightMyMonster.com。這讓我們得以奢侈地去構(gòu)建一個(gè)全新的 NOSQL 數(shù)據(jù)庫，也就是說，我們可以把恐怖的 MySQL sharding 和昂貴的可伸縮性拋在腦后了。最近有很多人一直在問，為什么我們要把注意力從 HBase 上轉(zhuǎn)移到 Cassandra 上去。我確認(rèn)，確實(shí)有這樣的變化，實(shí)際上我們基本上已經(jīng)把代碼移植到了 Cassandra 上了，這里我將給出解釋。

為了那些不熟悉 NOSQL 的讀者，后面的其他文章中，我會(huì)介紹為什么我們將會(huì)在未來幾年中看到地震式的從 SQL 到 NOSQL 的遷移，這正和向云計(jì)算的遷移一樣重要。后面的文章還會(huì)嘗試解釋為什么我認(rèn)為 NOSQL 可能會(huì)是貴公司的正確選擇。不過本文我只是解釋我們選擇 Cassandra 作為我們的 NOSQL 解決方案的選擇。

免責(zé)聲明——如果你正在尋找一個(gè)捷徑來決定你的系統(tǒng)選擇，你必須要明白，這可不是一個(gè)詳盡而嚴(yán)格的比較，它只是概述了另一個(gè)初創(chuàng)團(tuán)隊(duì)在有限時(shí)間和資源的情況下的邏輯。

Cassandra 的血統(tǒng)是否預(yù)言了它的未來

我最喜歡的一個(gè)工程師們用來找 bug 的謁語是“廣度優(yōu)先而非深度優(yōu)先”。這可以可能對(duì)那些解決技術(shù)細(xì)節(jié)的人來說很惱人，因?yàn)樗凳局绻麄冎皇强纯吹脑?，解決方法就會(huì)簡(jiǎn)單很多（忠告：只對(duì)那些能夠原諒你的同事說這個(gè)）。我造出這個(gè)謁語的原因在于，我發(fā)現(xiàn)，軟件問題中，如果我們強(qiáng)迫我們自己在進(jìn)入某行代碼的細(xì)節(jié)層面之前，先去看看那些高層次的考慮的話，可以節(jié)省大量時(shí)間。

所以，在談?wù)摷夹g(shù)之前，我在做 HBase 和 Cassandra 之間的選擇問題上先應(yīng)用一下我的箴言。我們選擇切換的技術(shù)結(jié)論可能已經(jīng)可以預(yù)測(cè)了：Hbase和Cassandra有著迥異的血統(tǒng)和基因，而我認(rèn)為這會(huì)影響到他們對(duì)我們的業(yè)務(wù)的適用性。

嚴(yán)格的說，Hbase 和它的支持系統(tǒng)源于著名的 Google BigTable 和 Google 文件系統(tǒng)設(shè)計(jì)（GFS 的論文發(fā)于 2003 年，BigTable 的論文發(fā)于 2006 年）。而 Cassandra 則是最近 Facebook 的數(shù)據(jù)庫系統(tǒng)的開源分支，她在實(shí)現(xiàn)了 BigTable 的數(shù)據(jù)模型的同時(shí)，使用了基于 Amazon 的 Dynamo 的系統(tǒng)架構(gòu)來存儲(chǔ)數(shù)據(jù)（實(shí)際上，Cassandra 的最初開發(fā)工作就是由兩位從 Amazon 跳槽到 Facebook 的 Dynamo 工程師完成的）。

在我看來，這些不同的歷史也導(dǎo)致Hbase更加適合于數(shù)據(jù)倉庫、大型數(shù)據(jù)的處理和分析（如進(jìn)行Web頁面的索引等），而 Cassandra 則更適合于實(shí)時(shí)事務(wù)處理和提供交互型數(shù)據(jù)。要進(jìn)行系統(tǒng)研究來證明這個(gè)觀點(diǎn)超出了本文的范疇，但我相信你在考慮數(shù)據(jù)庫的時(shí)候總能發(fā)現(xiàn)這個(gè)差異的存在。

注意：如果你在尋找一個(gè)簡(jiǎn)單的證明，你可以通過主要 committer 的關(guān)注點(diǎn)來進(jìn)行驗(yàn)證：大部分 HBase 的 committer 都為 Bing 工作（M$ 去年收購了他們的搜索公司，并允許他們?cè)跀?shù)月之后繼續(xù)提交開源代碼）。與之對(duì)應(yīng)，Cassandra 的主要 committer 來自 Rackspace，用來可以自由獲得的支持先進(jìn)的通用的 NOSQL 的解決方案，用來和 Google, Yahoo, Amazon EC2 等提供的那些鎖定在專有的 NOSQL 系統(tǒng)的方案相抗衡。

Malcolm Gladwell 會(huì)說只是根據(jù)這些背景的不同就可以簡(jiǎn)單地選擇了 Cassandra。不過這是小馬過河的問題。但當(dāng)然，閉著眼睛就進(jìn)行一個(gè)商業(yè)選擇是相當(dāng)困難的……

哪個(gè) NOSQL數(shù)據(jù)庫風(fēng)頭更勁?

另一個(gè)說服我們轉(zhuǎn)向 Cassandra 的原因是我們社區(qū)中的大風(fēng)向。如你所知，軟件平臺(tái)行業(yè)里，大者恒大——那些被普遍看好的平臺(tái)，會(huì)有更多人聚集在這個(gè)平臺(tái)周圍，于是，從長(zhǎng)遠(yuǎn)看，你可以得到更好的生態(tài)系統(tǒng)的支持（也就是說，大部分支持的軟件可以從社區(qū)中獲得，也有更多的開發(fā)者可以雇傭）。

如果從 HBase 開始時(shí)，我的印象就是它后面有巨大的社區(qū)力量，但我現(xiàn)在相信，Cassandra 更加強(qiáng)大。最初的印象部分來源于 StumpleUpon 和 Streamy 的兩位 CTO 的兩個(gè)非常有說服力的出色的講演，他們是 Web 行業(yè)中兩個(gè)在 Cassandra 成為一個(gè)可選系統(tǒng)之前的 HBase 的兩個(gè)重要的貢獻(xiàn)者，同時(shí)也部分來源于快速閱讀了一篇名為“HBase vs Cassandra： NoSQL 戰(zhàn)役！”的文章（大部分內(nèi)容都被廣泛證實(shí)了）。

勢(shì)頭是很難確證的，你不得不自己進(jìn)行研究，不過我可以找到的一個(gè)重要的標(biāo)志是 IRC 上的開發(fā)者動(dòng)向。如果你在 freenode.org 上比較 #hbase 和 #cassandra 的開發(fā)這頻道，你會(huì)發(fā)現(xiàn) Cassandra 差不多在任何時(shí)候都有兩倍的開發(fā)者在線。

如果你用考慮 HBase 一般的時(shí)間來考察 Cassandra，你就能發(fā)現(xiàn) Cassandra 的背后確實(shí)有非常明顯的加速勢(shì)頭。你可能還會(huì)發(fā)現(xiàn)那些逐漸出現(xiàn)的鼎鼎大名，如 Twitter，他們也計(jì)劃廣泛使用 Cassandra（這里）。

注：Cassandra 的網(wǎng)站看起來比 HBase 的好看多了，但認(rèn)真的說，這可能不僅是市場(chǎng)的趨勢(shì)。繼續(xù)吧。

深入到技術(shù)部分: CAP 和 CA 與 AP 的神話

對(duì)于分布式系統(tǒng)，有個(gè)非常重要的理論（這里我們?cè)谟懻摲植际綌?shù)據(jù)庫，我相信你注意到了）。這個(gè)理論被稱為 CAP 理論，由 Inktomi 的 聯(lián)合創(chuàng)始人兼首席科學(xué)家 Eric Brewer 博士提出。

這個(gè)理論說明，分布式（或共享數(shù)據(jù)）系統(tǒng)的設(shè)計(jì)中，至多只能夠提供三個(gè)重要特性中的兩個(gè)——一致性、可用性和容忍網(wǎng)絡(luò)分區(qū)。簡(jiǎn)單的說，一致性指如果一個(gè)人向數(shù)據(jù)庫寫了一個(gè)值，那么其他用戶能夠立刻讀取這個(gè)值，可用性意味著如果一些節(jié)點(diǎn)失效了，集群中的分布式系統(tǒng)仍然能繼續(xù)工作，而容忍分區(qū)意味著，如果節(jié)點(diǎn)被分割成兩組無法互相通信的節(jié)點(diǎn)，系統(tǒng)仍然能夠繼續(xù)工作。

Brewer教授是一個(gè)杰出的人物，許多開發(fā)者，包括 HBase 社區(qū)的很多人，都把此理論牢記在心，并用于他們的設(shè)計(jì)當(dāng)中。事實(shí)上，如果你搜索線上的關(guān)于 HBase 和 Cassandra 比較的文章，你通常會(huì)發(fā)現(xiàn)，HBase 社區(qū)解釋他們選擇了 CP，而 Cassandra 選擇了 AP ——毫無疑問，大多數(shù)開發(fā)者需要某種程度的一致性 （C）。

不過，我需要請(qǐng)你注意，事實(shí)上這些生命基于一個(gè)不完全的推論。CAP 理論僅僅適用于一個(gè)分布式算法（我希望 Brewer 教授可以統(tǒng)一）。但沒有說明你不能設(shè)計(jì)一個(gè)系統(tǒng)，在其中的各種操作的底層算法選擇上進(jìn)行這種。所以，在一個(gè)系統(tǒng)中，確實(shí)一個(gè)操作職能提供這些特性中的兩個(gè)，但被忽視的問題是在系統(tǒng)設(shè)計(jì)中，實(shí)際是可以允許調(diào)用者來選擇他們的某個(gè)操作時(shí)需要哪些特性的。不僅如此，現(xiàn)實(shí)世界并不簡(jiǎn)單的劃分為黑白兩色，所有這些特性都可以以某種程度來提供。這就是 Cassandra。

這點(diǎn)非常重要，我重申：Cassandra 的優(yōu)點(diǎn)在于你可以根據(jù)具體情況來選擇一個(gè)最佳的折衷，來滿足特定操作的需求。Cassandra 證明，你可以超越通常的 CAP 理論的解讀，而世界仍然在轉(zhuǎn)動(dòng)。

我們來看看兩種不同的極端。比如我必須從數(shù)據(jù)庫中讀取一個(gè)要求具有很高一致性的值，也就是說，我必須 100%保證能夠讀取到先前寫入的最新的內(nèi)容。在這種情況下，我可以通過指定一致性水平為“ALL”來從 Cassandra 讀取數(shù)據(jù)，這時(shí)要求所有節(jié)點(diǎn)都有數(shù)據(jù)的一致的副本。這里我們不具有對(duì)任何節(jié)點(diǎn)失效和網(wǎng)絡(luò)分裂的容錯(cuò)性。在另一個(gè)極端的方面，如果我不特別關(guān)心一致性，或僅僅就是希望最佳性能，我可以使用一致性級(jí)別“ONE”來訪問數(shù)據(jù)。在這種情況下，從任意一個(gè)保存有這個(gè)副本的節(jié)點(diǎn)獲取數(shù)據(jù)都可以——即使數(shù)據(jù)有三個(gè)副本，也并不在意其他兩個(gè)有副本的節(jié)點(diǎn)是否失效或是否有不同，當(dāng)然，這種情況下我們讀到的數(shù)據(jù)可能不是最新的。

不僅如此，你不必被迫生活在黑白世界中。比如，在我們的一個(gè)特定的應(yīng)用中，重要的讀寫操作通常使用“QUORUM”一致性級(jí)別，這意味著大部分存有此數(shù)據(jù)的節(jié)點(diǎn)上的副本是一致的——我這里是個(gè)簡(jiǎn)要描述，具體寫你的 Cassandra 程序之前最好還是仔細(xì)研究一下。從我們的視角看，這這提供了一個(gè)合理的節(jié)點(diǎn)失效與網(wǎng)絡(luò)分裂的耐受性，同時(shí)也提供了很高的一致性。而在一般情況下，我們使用前面提到的“ONE”一致性級(jí)別，者可以提供最高的性能。就是這樣。

對(duì)我們來說，這是 Cassandra 的一個(gè)巨大的加分項(xiàng)目。我們不僅能輕易地調(diào)整我們的系統(tǒng)，也可以設(shè)計(jì)它。比如，當(dāng)一定數(shù)量的節(jié)點(diǎn)失效或出現(xiàn)網(wǎng)絡(luò)連接故障時(shí)，我們的大部分服務(wù)仍然可以繼續(xù)工作，只有那些需要數(shù)據(jù)一致性的服務(wù)會(huì)失效。HBase并沒有這么靈活，它單純地追求系統(tǒng)的一個(gè)方面（CP），這讓我再次看到了 SQL 開發(fā)者和查詢優(yōu)化人員們之間的那道隔閡——有些事情最好能夠超越它，HBase！

In our project then, Cassandra has proven by far the most flexible system, although you may find your brain at first loses consistency when considering your QUORUMs.在我們的項(xiàng)目之后，卡桑德拉已被證明是迄今為止最靈活的系統(tǒng)，雖然你可能發(fā)現(xiàn)一致性第一失去你的大腦在考慮您的法定人數(shù)。

在我們的項(xiàng)目中，Cassandra 已經(jīng)證明了它是有史以來最靈活的系統(tǒng)，雖然你可能在對(duì)這個(gè)問題進(jìn)行投票（QUORUM）的時(shí)候發(fā)現(xiàn)的大腦失去了一致性。

什么時(shí)候單體會(huì)比模塊化強(qiáng)？

Cassandra 和 HBase 的一個(gè)重要區(qū)別是， Cassandra 在每個(gè)節(jié)點(diǎn)是是一個(gè)單 Java 進(jìn)程，而完整的 HBase 解決方案卻由不同部分組成：有數(shù)據(jù)庫進(jìn)程本身，它可能會(huì)運(yùn)行在多個(gè)模式；一個(gè)配置好的 hadoop HDFS 分布式文件系統(tǒng)，以及一個(gè) Zookeeper 系統(tǒng)來協(xié)調(diào)不同的 HBase 進(jìn)程。那么，這是否意味著 HBase 有更好的模塊化結(jié)構(gòu)呢？

雖然 HBase 的這種架構(gòu)可能確實(shí)可以平衡不同開發(fā)團(tuán)隊(duì)的利益，在系統(tǒng)管理方面，模塊化的 HBase 卻無法視為一個(gè)加分項(xiàng)目。事實(shí)上，特別是對(duì)于一些小的初創(chuàng)公司，模塊化倒是一個(gè)很大的負(fù)面因素。

HBase的下層相當(dāng)復(fù)雜，任何對(duì)此有疑惑的人應(yīng)該讀讀 Google 的 GFS 和 BigTable 的論文。即使是在一個(gè)單一節(jié)點(diǎn)的偽分布式模式下來架設(shè) HBase 也很困難——事實(shí)上，我曾經(jīng)費(fèi)力寫過一篇快速入門的教程（如果你要試試HBase的話看看這里）。在這個(gè)指南里你可以看到，設(shè)置好 HBase 并啟動(dòng)它實(shí)際包含了兩個(gè)不同系統(tǒng)的手工設(shè)置：首先是 hadoop HDFS，然后才是 HBase 本身。

然后，HBase 的配置文件本身就是個(gè)怪獸，而你的設(shè)置可能和缺省的網(wǎng)絡(luò)配置有極大的不同（在文章里我寫了兩個(gè)不同的Ubuntu的缺省網(wǎng)絡(luò)設(shè)置，以及 EC2 里易變的 Elastic IP 和內(nèi)部分配的域名）。當(dāng)系統(tǒng)工作不正常的時(shí)候，你需要查看大量的日志。所有的需要修復(fù)的東西的信息都在日志里，而如果你是一個(gè)經(jīng)驗(yàn)豐富的管理員的話，就能發(fā)現(xiàn)并處理問題。

但是，如果是在生產(chǎn)過程中出現(xiàn)問題，而你又沒有時(shí)間耐心查找問題呢？如果你和我們一樣，只有一個(gè)小的開發(fā)團(tuán)隊(duì)卻有遠(yuǎn)大的目標(biāo)，沒有經(jīng)歷去 7*24 的進(jìn)行系統(tǒng)監(jiān)控管理會(huì)怎么樣呢？

嚴(yán)肅地說，如果你是一個(gè)希望學(xué)習(xí) NoSQL 系統(tǒng)的高級(jí) DB 管理員的話，那么選擇 HBase。這個(gè)系統(tǒng)超級(jí)復(fù)雜，有靈巧雙手的管理員肯定能拿到高薪。

但是如果你們是一個(gè)向我們一樣盡力去發(fā)現(xiàn)隧道盡頭的小團(tuán)隊(duì)的話，還是等著聽聽別的閑話吧

勝在 Gossip！

Cassandra 是一個(gè)完全對(duì)稱的系統(tǒng)。也就是說，沒有主節(jié)點(diǎn)或像 HBase 里的 region server 這樣的東西——每個(gè)節(jié)點(diǎn)的角色是完全一樣的。不會(huì)有任何特定的節(jié)點(diǎn)或其他實(shí)體來充當(dāng)協(xié)調(diào)者的角色，集群中的節(jié)點(diǎn)使用稱為 “Cossip” 的純 P2P 通信協(xié)議來協(xié)調(diào)他們的行為。

對(duì) Gossip 的詳細(xì)描述和使用 Gossip 的模型超過了本文的內(nèi)容，但 Cassandra 所采用的 P2P 通信模型都是論證過的，比如發(fā)現(xiàn)節(jié)點(diǎn)失效的消息傳播到整個(gè)系統(tǒng)的時(shí)間，或是一個(gè)客戶應(yīng)用的請(qǐng)求被路由到保存數(shù)據(jù)的節(jié)點(diǎn)的時(shí)間，所有這些過程所消耗的時(shí)間都毫無疑問的非常的短。我個(gè)人相信，Cassandra 代表了當(dāng)今最振奮的一種 P2P 技術(shù)，當(dāng)然，這和你的 NOSQL 數(shù)據(jù)庫的選擇無關(guān)。

那么，這個(gè)基于 Gossip 的架構(gòu)究竟給 Cassandra 用戶帶來什么顯示的好處呢。首先，繼續(xù)我們的系統(tǒng)管理主體，系統(tǒng)管理變得簡(jiǎn)單多了。比如，增加一個(gè)新節(jié)點(diǎn)到系統(tǒng)中就是啟動(dòng)一個(gè) Cassandra 進(jìn)程并告訴它一個(gè)種子節(jié)點(diǎn)（一個(gè)已知的在集群中的節(jié)點(diǎn)）這么簡(jiǎn)單。試想當(dāng)你的分布式集群可能運(yùn)行在上百個(gè)節(jié)點(diǎn)的規(guī)模上的時(shí)候，如此輕易地增加新節(jié)點(diǎn)簡(jiǎn)直是難以置信。更進(jìn)一步，當(dāng)有什么出錯(cuò)的時(shí)候，你不需要考慮是哪種節(jié)點(diǎn)出了問題——所有節(jié)點(diǎn)都是一樣的，這讓調(diào)試成為了一個(gè)更加易于進(jìn)行且可重復(fù)的過程。

第二，我可以得出結(jié)論，Cassandra 的 P2P 架構(gòu)給了它更好的性能和可用性。這樣的系統(tǒng)中，負(fù)載可以被均衡地三步倒各個(gè)節(jié)點(diǎn)上，來最大化潛在的并行性，這個(gè)能力讓系統(tǒng)面臨網(wǎng)絡(luò)分裂和節(jié)點(diǎn)失效的時(shí)候都能更加的無縫，并且節(jié)點(diǎn)的對(duì)稱性防止了 HBase 中發(fā)現(xiàn)的那種在節(jié)點(diǎn)加入和刪除時(shí)的暫時(shí)性的性能都懂（Cassandra 啟動(dòng)非常迅速，并且性能可以隨著節(jié)點(diǎn)的加入而平滑擴(kuò)展）。

如果你想尋找更多更多的證據(jù)，你會(huì)對(duì)一個(gè)原來一直關(guān)注 hadoop 的小組（應(yīng)該對(duì) HBase 更加偏愛）的報(bào)告很感興趣……

一份報(bào)告勝過千言萬語。我是指圖表

Yahoo！進(jìn)行的第一個(gè) NOSQL 系統(tǒng)的完整評(píng)測(cè)。研究似乎證實(shí)了 Cassandra 所享有的性能優(yōu)勢(shì)，從圖表上看，非常傾向于 Cassandra。

目前這些論文還是草稿，你可以從這里找到這些論文：
http://www.brianfrankcooper.net/pubs/ycsb-v4.pdf
http://www.brianfrankcooper.net/pubs/ycsb.pdf

注意：這份報(bào)告中 HBase 僅在對(duì)一個(gè)范圍的記錄進(jìn)行掃描這一項(xiàng)上優(yōu)于 Cassandra。雖然 Cassandra 團(tuán)隊(duì)相信他們可以很快達(dá)到 HBase 的時(shí)間，但還是值得指出，在通常的 Cassandra 配置中，區(qū)間掃描幾乎是不可能的。我建議你可以無視這一點(diǎn)，因?yàn)閷?shí)際上你應(yīng)該在 Cassandra 上面來實(shí)現(xiàn)你自己的索引，而非使用區(qū)間掃描。如果你對(duì)區(qū)間掃描和在 Cassandra 中存儲(chǔ)索引相關(guān)問題有興趣，可以看我的這篇文章。

最后一點(diǎn)： 這篇文章背后的 Yahoo！研究團(tuán)隊(duì)正嘗試讓它們的評(píng)測(cè)應(yīng)用通過法律部門的評(píng)估，并將它發(fā)布給社區(qū)。如果他們成功的話，我當(dāng)然希望他們成功，我們將能夠看到一個(gè)持續(xù)的競(jìng)爭(zhēng)場(chǎng)面，不論 HBase 還是 Cassandra 無疑都會(huì)進(jìn)一步提高他們的性能。

鎖和有用的模塊性

毫無疑問，你會(huì)從 HBase 陣營(yíng)聽到這樣的聲音：HBase 的復(fù)雜結(jié)構(gòu)讓它可以提供 Cassandra 的 P2P 架構(gòu)無法提供的東西。其中一個(gè)例子可能就是 Hbase 提供給開發(fā)者行鎖機(jī)制，而 Cassandra 則沒有（在 HBase 中，因?yàn)閿?shù)據(jù)副本發(fā)生在 hadoop 底層，行鎖可以由 region server 控制，而在 Cassandra 的 P2P 架構(gòu)中，所有節(jié)點(diǎn)都是平等的，所以也就沒有節(jié)點(diǎn)可以像一個(gè)網(wǎng)管囊樣負(fù)責(zé)鎖定有副本的數(shù)據(jù)）。

不夠，我還是把這個(gè)問題返回到關(guān)于模塊化的爭(zhēng)論中，這實(shí)際是對(duì) Cassandra 有理的。Cassandra 通過在對(duì)稱節(jié)點(diǎn)上分布式存儲(chǔ)數(shù)據(jù)來實(shí)現(xiàn)了 BigTable 的數(shù)據(jù)模型。它完整地實(shí)現(xiàn)了這些功能，而且是以最靈活和高性能的方式實(shí)現(xiàn)的。但如果你需要鎖、事務(wù)和其它功能的話，這些可以以模塊的方式添加到你的系統(tǒng)之中——比如，我們發(fā)現(xiàn)我們可以使用 Zookeeper 和相關(guān)的工具來很簡(jiǎn)單地為我們的應(yīng)用提供可擴(kuò)展的鎖功能（對(duì)于這個(gè)功能，Hazelcast 等系統(tǒng)可能也可以實(shí)現(xiàn)這個(gè)功能，雖然我們沒有進(jìn)行研究）。

通過為一個(gè)窄領(lǐng)域目的來最小化它的功能，對(duì)我來說，Cassandra 的設(shè)計(jì)達(dá)到了它的目的——比如前面指出可配置的 CAP 的折衷。這種模塊性意味著你可以依據(jù)你的需求來構(gòu)建一個(gè)系統(tǒng)——需要鎖，那么拿來 Zookeeper，需要存儲(chǔ)全文索引，拿來 Lucandra ，等等。對(duì)于我們這樣的開發(fā)者來說，這意味著我們不必部署復(fù)雜度超出我們實(shí)際需要的系統(tǒng)，給我們提供了更加靈活的構(gòu)建我們需要的應(yīng)用的終極道路。

MapReduce，別提 MapReduce！

Cassandra 做的還不夠好的一件事情就是 MapReduce！對(duì)于不精通此項(xiàng)技術(shù)同學(xué)簡(jiǎn)單的解釋一句，這是一個(gè)用于并行處理大量數(shù)據(jù)的系統(tǒng)，比如從上百萬從網(wǎng)絡(luò)上抓取的頁面提取統(tǒng)計(jì)信息。MapReduce 和相關(guān)系統(tǒng)，比如 Pig 和 Hive 可以和 HBase 一起良好協(xié)作，因?yàn)樗褂?HDFS 來存儲(chǔ)數(shù)據(jù)，這些系統(tǒng)也是設(shè)計(jì)用來使用 HDFS 的。如果你需要進(jìn)行這樣的數(shù)據(jù)處理和分析的話，HBase 可能是你目前的最佳選擇。

記住，這就像小馬過河！

因此，我停止了對(duì) Cassandra  的優(yōu)點(diǎn)的贊美，實(shí)際上，HBase 和 Cassandra 并不一定是一對(duì)完全的競(jìng)爭(zhēng)對(duì)手。雖然它們常?？梢杂糜谕瑯拥挠猛荆?MySQL 和 PostgreSQL 類似，我相信在將來它們將會(huì)成為不同應(yīng)用的首選解決方案。比如，據(jù)我所知 StumbleUpon 使用了 HBase 和 hadoop MapReduce 技術(shù)，來處理其業(yè)務(wù)的大量數(shù)據(jù)。Twitter 現(xiàn)在使用 Cassandra 來存儲(chǔ)實(shí)時(shí)交互的社區(qū)發(fā)言，可能你已經(jīng)在某種程度上使用它了。

作為一個(gè)有爭(zhēng)議的臨別贈(zèng)言，下面我們進(jìn)入下一個(gè)話題。

注意：在繼續(xù)下一個(gè)小節(jié)之前，我要指出，Cassandra 在 0.6 版本會(huì)有 hadoop 支持，所以 MapReduce 整合能獲得更好的支持。

兄弟，我不能失去數(shù)據(jù)…

作為先前 CAP 理論爭(zhēng)議的一個(gè)可能結(jié)果，可能有這樣的印象，HBase 的數(shù)據(jù)似乎比 Cassandra 中的數(shù)據(jù)更安全。這是我希望揭露的最后一個(gè)關(guān)于 Cassandra 的秘密，當(dāng)你寫入新數(shù)據(jù)的時(shí)候，它實(shí)際上立刻將它寫入一個(gè)將要存儲(chǔ)副本的仲裁節(jié)點(diǎn)的 commit log 當(dāng)中了，也被復(fù)制到了節(jié)點(diǎn)們的內(nèi)存中。這意味著如果你完全讓你的集群掉電，只可能會(huì)損失極少數(shù)據(jù)。更進(jìn)一步，在系統(tǒng)中，通過使用 Merkle tree 來組織數(shù)據(jù)的過分不一致（數(shù)據(jù)熵），更加增加了數(shù)據(jù)的安全性

事實(shí)上，我對(duì) HBase 的情況并不是非常確切——如果能有更細(xì)節(jié)的情況，我回盡快更新這里的內(nèi)容的——但現(xiàn)在我的理解是，因?yàn)?hadoop 還不支持 append，HBase 不能有效地將修改的塊信息刷入 HDFS （新的對(duì)數(shù)據(jù)變化會(huì)被復(fù)制為多個(gè)副本并永久化保存）。這意味著會(huì)有一個(gè)更大的缺口，你最新的更改是不可見的（如果我錯(cuò)了，可能是這樣，請(qǐng)告訴我，我回修正本文）。

所以，盡管希臘神話中的 Cassandra 非常不幸（譯注：Cassandra 是希臘神話里，特洛伊的那個(gè)可憐的女先知的名字，如果你不知道詳情的話，可以參考wiki），但你的 Cassandra 中的數(shù)據(jù)不會(huì)有危險(xiǎn)。

注意：Wade Amold 指出， hadoop .21 很快就會(huì)發(fā)布，其中將會(huì)解決 HBase 的這個(gè)問題。