原文: 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日

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

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

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

Cassandra 的血統是否預言了它的未來(lái)

我最喜歡的一個(gè)工程師們用來(lái)找 bug 的謁語(yǔ)是“廣度優(yōu)先而非深度優(yōu)先”。這可以可能對那些解決技術(shù)細節的人來(lái)說(shuō)很惱人，因為它暗示著(zhù)如果他們只是看看的話(huà)，解決方法就會(huì )簡(jiǎn)單很多（忠告：只對那些能夠原諒你的同事說(shuō)這個(gè)）。我造出這個(gè)謁語(yǔ)的原因在于，我發(fā)現，軟件問(wèn)題中，如果我們強迫我們自己在進(jìn)入某行代碼的細節層面之前，先去看看那些高層次的考慮的話(huà)，可以節省大量時(shí)間。

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

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

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

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

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

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

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

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

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

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

注：Cassandra 的網(wǎng)站看起來(lái)比 HBase 的好看多了，但認真的說(shuō)，這可能不僅是市場(chǎng)的趨勢。繼續吧。

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

對于分布式系統，有個(gè)非常重要的理論（這里我們在討論分布式數據庫，我相信你注意到了）。這個(gè)理論被稱(chēng)為 CAP 理論，由 Inktomi 的 聯(lián)合創(chuàng )始人兼首席科學(xué)家 Eric Brewer 博士提出。

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

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

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

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

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

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

對我們來(lái)說(shuō)，這是 Cassandra 的一個(gè)巨大的加分項目。我們不僅能輕易地調整我們的系統，也可以設計它。比如，當一定數量的節點(diǎn)失效或出現網(wǎng)絡(luò )連接故障時(shí)，我們的大部分服務(wù)仍然可以繼續工作，只有那些需要數據一致性的服務(wù)會(huì )失效。HBase并沒(méi)有這么靈活，它單純地追求系統的一個(gè)方面（CP），這讓我再次看到了 SQL 開(kāi)發(fā)者和查詢(xún)優(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.在我們的項目之后，卡桑德拉已被證明是迄今為止最靈活的系統，雖然你可能發(fā)現一致性第一失去你的大腦在考慮您的法定人數。

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

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

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

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

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

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

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

嚴肅地說(shuō)，如果你是一個(gè)希望學(xué)習 NoSQL 系統的高級 DB 管理員的話(huà)，那么選擇 HBase。這個(gè)系統超級復雜，有靈巧雙手的管理員肯定能拿到高薪。

但是如果你們是一個(gè)向我們一樣盡力去發(fā)現隧道盡頭的小團隊的話(huà)，還是等著(zhù)聽(tīng)聽(tīng)別的閑話(huà)吧

勝在 Gossip！

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

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

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

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

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

一份報告勝過(guò)千言萬(wàn)語(yǔ)。我是指圖表

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

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

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

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

鎖和有用的模塊性

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

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

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

MapReduce，別提 MapReduce！

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

記住，這就像小馬過(guò)河！

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

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

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

兄弟，我不能失去數據…

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

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

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

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