原文: http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/
原作者：Dominic Williams
原文發布日期：February 24, 2010 at 7:27 pm
譯者：王旭（http://wangxu.me/blog/ , @gnawux）
翻譯時間：2010年3月21-25日
我的團隊近來正在忙于一個全新的產品——即將發布的網絡游戲 www.FightMyMonster.com。這讓我們得以奢侈地去構建一個全新的 NOSQL 數據庫，也就是說，我們可以把恐怖的 MySQL sharding 和昂貴的可伸縮性拋在腦后了。最近有很多人一直在問，為什么我們要把注意力從 HBase 上轉移到 Cassandra 上去。我確認，確實有這樣的變化，實際上我們基本上已經把代碼移植到了 Cassandra 上了，這里我將給出解釋。
為了那些不熟悉 NOSQL 的讀者，后面的其他文章中，我會介紹為什么我們將會在未來幾年中看到地震式的從 SQL 到 NOSQL 的遷移，這正和向云計算的遷移一樣重要。后面的文章還會嘗試解釋為什么我認為 NOSQL 可能會是貴公司的正確選擇。不過本文我只是解釋我們選擇 Cassandra 作為我們的 NOSQL 解決方案的選擇。
免責聲明——如果你正在尋找一個捷徑來決定你的系統選擇，你必須要明白，這可不是一個詳盡而嚴格的比較，它只是概述了另一個初創團隊在有限時間和資源的情況下的邏輯。
Cassandra 的血統是否預言了它的未來
我最喜歡的一個工程師們用來找 bug 的謁語是“廣度優先而非深度優先”。這可以可能對那些解決技術細節的人來說很惱人，因為它暗示著如果他們只是看看的話，解決方法就會簡單很多（忠告：只對那些能夠原諒你的同事說這個）。我造出這個謁語的原因在于，我發現，軟件問題中，如果我們強迫我們自己在進入某行代碼的細節層面之前，先去看看那些高層次的考慮的話，可以節省大量時間。
所以，在談論技術之前，我在做 HBase 和 Cassandra 之間的選擇問題上先應用一下我的箴言。我們選擇切換的技術結論可能已經可以預測了：Hbase和Cassandra有著迥異的血統和基因，而我認為這會影響到他們對我們的業務的適用性。
嚴格的說，Hbase 和它的支持系統源于著名的 Google BigTable 和 Google 文件系統設計（GFS 的論文發于 2003 年，BigTable 的論文發于 2006 年）。而 Cassandra 則是最近 Facebook 的數據庫系統的開源分支，她在實現了 BigTable 的數據模型的同時，使用了基于 Amazon 的 Dynamo 的系統架構來存儲數據（實際上，Cassandra 的最初開發工作就是由兩位從 Amazon 跳槽到 Facebook 的 Dynamo 工程師完成的）。
在我看來，這些不同的歷史也導致Hbase更加適合于數據倉庫、大型數據的處理和分析（如進行Web頁面的索引等），而 Cassandra 則更適合于實時事務處理和提供交互型數據。要進行系統研究來證明這個觀點超出了本文的范疇，但我相信你在考慮數據庫的時候總能發現這個差異的存在。
注意：如果你在尋找一個簡單的證明，你可以通過主要 committer 的關注點來進行驗證：大部分 HBase 的 committer 都為 Bing 工作（M$ 去年收購了他們的搜索公司，并允許他們在數月之后繼續提交開源代碼）。與之對應，Cassandra 的主要 committer 來自 Rackspace，用來可以自由獲得的支持先進的通用的 NOSQL 的解決方案，用來和 Google, Yahoo, Amazon EC2 等提供的那些鎖定在專有的 NOSQL 系統的方案相抗衡。
Malcolm Gladwell 會說只是根據這些背景的不同就可以簡單地選擇了 Cassandra。不過這是小馬過河的問題。但當然，閉著眼睛就進行一個商業選擇是相當困難的……
哪個 NOSQL數據庫風頭更勁?
另一個說服我們轉向 Cassandra 的原因是我們社區中的大風向。如你所知，軟件平臺行業里，大者恒大——那些被普遍看好的平臺，會有更多人聚集在這個平臺周圍，于是，從長遠看，你可以得到更好的生態系統的支持（也就是說，大部分支持的軟件可以從社區中獲得，也有更多的開發者可以雇傭）。
如果從 HBase 開始時，我的印象就是它后面有巨大的社區力量，但我現在相信，Cassandra 更加強大。最初的印象部分來源于 StumpleUpon 和 Streamy 的兩位 CTO 的兩個非常有說服力的出色的講演，他們是 Web 行業中兩個在 Cassandra 成為一個可選系統之前的 HBase 的兩個重要的貢獻者，同時也部分來源于快速閱讀了一篇名為“HBase vs Cassandra： NoSQL 戰役！”的文章（大部分內容都被廣泛證實了）。
勢頭是很難確證的，你不得不自己進行研究，不過我可以找到的一個重要的標志是 IRC 上的開發者動向。如果你在 freenode.org 上比較 #hbase 和 #cassandra 的開發這頻道，你會發現 Cassandra 差不多在任何時候都有兩倍的開發者在線。
如果你用考慮 HBase 一般的時間來考察 Cassandra，你就能發現 Cassandra 的背后確實有非常明顯的加速勢頭。你可能還會發現那些逐漸出現的鼎鼎大名，如 Twitter，他們也計劃廣泛使用 Cassandra（這里）。
注：Cassandra 的網站看起來比 HBase 的好看多了，但認真的說，這可能不僅是市場的趨勢。繼續吧。
深入到技術部分: CAP 和 CA 與 AP 的神話
對于分布式系統，有個非常重要的理論（這里我們在討論分布式數據庫，我相信你注意到了）。這個理論被稱為 CAP 理論，由 Inktomi 的 聯合創始人兼首席科學家 Eric Brewer 博士提出。
這個理論說明，分布式（或共享數據）系統的設計中，至多只能夠提供三個重要特性中的兩個——一致性、可用性和容忍網絡分區。簡單的說，一致性指如果一個人向數據庫寫了一個值，那么其他用戶能夠立刻讀取這個值，可用性意味著如果一些節點失效了，集群中的分布式系統仍然能繼續工作，而容忍分區意味著，如果節點被分割成兩組無法互相通信的節點，系統仍然能夠繼續工作。
Brewer教授是一個杰出的人物，許多開發者，包括 HBase 社區的很多人，都把此理論牢記在心，并用于他們的設計當中。事實上，如果你搜索線上的關于 HBase 和 Cassandra 比較的文章，你通常會發現，HBase 社區解釋他們選擇了 CP，而 Cassandra 選擇了 AP ——毫無疑問，大多數開發者需要某種程度的一致性 （C）。
不過，我需要請你注意，事實上這些生命基于一個不完全的推論。CAP 理論僅僅適用于一個分布式算法（我希望 Brewer 教授可以統一）。但沒有說明你不能設計一個系統，在其中的各種操作的底層算法選擇上進行這種。所以，在一個系統中，確實一個操作職能提供這些特性中的兩個，但被忽視的問題是在系統設計中，實際是可以允許調用者來選擇他們的某個操作時需要哪些特性的。不僅如此，現實世界并不簡單的劃分為黑白兩色，所有這些特性都可以以某種程度來提供。這就是 Cassandra。
這點非常重要，我重申：Cassandra 的優點在于你可以根據具體情況來選擇一個最佳的折衷，來滿足特定操作的需求。Cassandra 證明，你可以超越通常的 CAP 理論的解讀，而世界仍然在轉動。
我們來看看兩種不同的極端。比如我必須從數據庫中讀取一個要求具有很高一致性的值，也就是說，我必須 100%保證能夠讀取到先前寫入的最新的內容。在這種情況下，我可以通過指定一致性水平為“ALL”來從 Cassandra 讀取數據，這時要求所有節點都有數據的一致的副本。這里我們不具有對任何節點失效和網絡分裂的容錯性。在另一個極端的方面，如果我不特別關心一致性，或僅僅就是希望最佳性能，我可以使用一致性級別“ONE”來訪問數據。在這種情況下，從任意一個保存有這個副本的節點獲取數據都可以——即使數據有三個副本，也并不在意其他兩個有副本的節點是否失效或是否有不同，當然，這種情況下我們讀到的數據可能不是最新的。
不僅如此，你不必被迫生活在黑白世界中。比如，在我們的一個特定的應用中，重要的讀寫操作通常使用“QUORUM”一致性級別，這意味著大部分存有此數據的節點上的副本是一致的——我這里是個簡要描述，具體寫你的 Cassandra 程序之前最好還是仔細研究一下。從我們的視角看，這這提供了一個合理的節點失效與網絡分裂的耐受性，同時也提供了很高的一致性。而在一般情況下，我們使用前面提到的“ONE”一致性級別，者可以提供最高的性能。就是這樣。
對我們來說，這是 Cassandra 的一個巨大的加分項目。我們不僅能輕易地調整我們的系統，也可以設計它。比如，當一定數量的節點失效或出現網絡連接故障時，我們的大部分服務仍然可以繼續工作，只有那些需要數據一致性的服務會失效。HBase并沒有這么靈活，它單純地追求系統的一個方面（CP），這讓我再次看到了 SQL 開發者和查詢優化人員們之間的那道隔閡——有些事情最好能夠超越它，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.在我們的項目之后，卡桑德拉已被證明是迄今為止最靈活的系統，雖然你可能發現一致性第一失去你的大腦在考慮您的法定人數。
在我們的項目中，Cassandra 已經證明了它是有史以來最靈活的系統，雖然你可能在對這個問題進行投票（QUORUM）的時候發現的大腦失去了一致性。
什么時候單體會比模塊化強？
Cassandra 和 HBase 的一個重要區別是， Cassandra 在每個節點是是一個單 Java 進程，而完整的 HBase 解決方案卻由不同部分組成：有數據庫進程本身，它可能會運行在多個模式；一個配置好的 hadoop HDFS 分布式文件系統，以及一個 Zookeeper 系統來協調不同的 HBase 進程。那么，這是否意味著 HBase 有更好的模塊化結構呢？
雖然 HBase 的這種架構可能確實可以平衡不同開發團隊的利益，在系統管理方面，模塊化的 HBase 卻無法視為一個加分項目。事實上，特別是對于一些小的初創公司，模塊化倒是一個很大的負面因素。
HBase的下層相當復雜，任何對此有疑惑的人應該讀讀 Google 的 GFS 和 BigTable 的論文。即使是在一個單一節點的偽分布式模式下來架設 HBase 也很困難——事實上，我曾經費力寫過一篇快速入門的教程（如果你要試試HBase的話看看這里）。在這個指南里你可以看到，設置好 HBase 并啟動它實際包含了兩個不同系統的手工設置：首先是 hadoop HDFS，然后才是 HBase 本身。
然后，HBase 的配置文件本身就是個怪獸，而你的設置可能和缺省的網絡配置有極大的不同（在文章里我寫了兩個不同的Ubuntu的缺省網絡設置，以及 EC2 里易變的 Elastic IP 和內部分配的域名）。當系統工作不正常的時候，你需要查看大量的日志。所有的需要修復的東西的信息都在日志里，而如果你是一個經驗豐富的管理員的話，就能發現并處理問題。
但是，如果是在生產過程中出現問題，而你又沒有時間耐心查找問題呢？如果你和我們一樣，只有一個小的開發團隊卻有遠大的目標，沒有經歷去 7*24 的進行系統監控管理會怎么樣呢？
嚴肅地說，如果你是一個希望學習 NoSQL 系統的高級 DB 管理員的話，那么選擇 HBase。這個系統超級復雜，有靈巧雙手的管理員肯定能拿到高薪。
但是如果你們是一個向我們一樣盡力去發現隧道盡頭的小團隊的話，還是等著聽聽別的閑話吧
勝在 Gossip！
Cassandra 是一個完全對稱的系統。也就是說，沒有主節點或像 HBase 里的 region server 這樣的東西——每個節點的角色是完全一樣的。不會有任何特定的節點或其他實體來充當協調者的角色，集群中的節點使用稱為 “Cossip” 的純 P2P 通信協議來協調他們的行為。
對 Gossip 的詳細描述和使用 Gossip 的模型超過了本文的內容，但 Cassandra 所采用的 P2P 通信模型都是論證過的，比如發現節點失效的消息傳播到整個系統的時間，或是一個客戶應用的請求被路由到保存數據的節點的時間，所有這些過程所消耗的時間都毫無疑問的非常的短。我個人相信，Cassandra 代表了當今最振奮的一種 P2P 技術，當然，這和你的 NOSQL 數據庫的選擇無關。
那么，這個基于 Gossip 的架構究竟給 Cassandra 用戶帶來什么顯示的好處呢。首先，繼續我們的系統管理主體，系統管理變得簡單多了。比如，增加一個新節點到系統中就是啟動一個 Cassandra 進程并告訴它一個種子節點（一個已知的在集群中的節點）這么簡單。試想當你的分布式集群可能運行在上百個節點的規模上的時候，如此輕易地增加新節點簡直是難以置信。更進一步，當有什么出錯的時候，你不需要考慮是哪種節點出了問題——所有節點都是一樣的，這讓調試成為了一個更加易于進行且可重復的過程。
第二，我可以得出結論，Cassandra 的 P2P 架構給了它更好的性能和可用性。這樣的系統中，負載可以被均衡地三步倒各個節點上，來最大化潛在的并行性，這個能力讓系統面臨網絡分裂和節點失效的時候都能更加的無縫，并且節點的對稱性防止了 HBase 中發現的那種在節點加入和刪除時的暫時性的性能都懂（Cassandra 啟動非常迅速，并且性能可以隨著節點的加入而平滑擴展）。
如果你想尋找更多更多的證據，你會對一個原來一直關注 hadoop 的小組（應該對 HBase 更加偏愛）的報告很感興趣……
一份報告勝過千言萬語。我是指圖表
Yahoo！進行的第一個 NOSQL 系統的完整評測。研究似乎證實了 Cassandra 所享有的性能優勢，從圖表上看，非常傾向于 Cassandra。
目前這些論文還是草稿，你可以從這里找到這些論文：
http://www.brianfrankcooper.net/pubs/ycsb-v4.pdf
http://www.brianfrankcooper.net/pubs/ycsb.pdf
注意：這份報告中 HBase 僅在對一個范圍的記錄進行掃描這一項上優于 Cassandra。雖然 Cassandra 團隊相信他們可以很快達到 HBase 的時間，但還是值得指出，在通常的 Cassandra 配置中，區間掃描幾乎是不可能的。我建議你可以無視這一點，因為實際上你應該在 Cassandra 上面來實現你自己的索引，而非使用區間掃描。如果你對區間掃描和在 Cassandra 中存儲索引相關問題有興趣，可以看我的這篇文章。
最后一點： 這篇文章背后的 Yahoo！研究團隊正嘗試讓它們的評測應用通過法律部門的評估，并將它發布給社區。如果他們成功的話，我當然希望他們成功，我們將能夠看到一個持續的競爭場面，不論 HBase 還是 Cassandra 無疑都會進一步提高他們的性能。
鎖和有用的模塊性
毫無疑問，你會從 HBase 陣營聽到這樣的聲音：HBase 的復雜結構讓它可以提供 Cassandra 的 P2P 架構無法提供的東西。其中一個例子可能就是 Hbase 提供給開發者行鎖機制，而 Cassandra 則沒有（在 HBase 中，因為數據副本發生在 hadoop 底層，行鎖可以由 region server 控制，而在 Cassandra 的 P2P 架構中，所有節點都是平等的，所以也就沒有節點可以像一個網管囊樣負責鎖定有副本的數據）。
不夠，我還是把這個問題返回到關于模塊化的爭論中，這實際是對 Cassandra 有理的。Cassandra 通過在對稱節點上分布式存儲數據來實現了 BigTable 的數據模型。它完整地實現了這些功能，而且是以最靈活和高性能的方式實現的。但如果你需要鎖、事務和其它功能的話，這些可以以模塊的方式添加到你的系統之中——比如，我們發現我們可以使用 Zookeeper 和相關的工具來很簡單地為我們的應用提供可擴展的鎖功能（對于這個功能，Hazelcast 等系統可能也可以實現這個功能，雖然我們沒有進行研究）。
通過為一個窄領域目的來最小化它的功能，對我來說，Cassandra 的設計達到了它的目的——比如前面指出可配置的 CAP 的折衷。這種模塊性意味著你可以依據你的需求來構建一個系統——需要鎖，那么拿來 Zookeeper，需要存儲全文索引，拿來 Lucandra ，等等。對于我們這樣的開發者來說，這意味著我們不必部署復雜度超出我們實際需要的系統，給我們提供了更加靈活的構建我們需要的應用的終極道路。
MapReduce，別提 MapReduce！
Cassandra 做的還不夠好的一件事情就是 MapReduce！對于不精通此項技術同學簡單的解釋一句，這是一個用于并行處理大量數據的系統，比如從上百萬從網絡上抓取的頁面提取統計信息。MapReduce 和相關系統，比如 Pig 和 Hive 可以和 HBase 一起良好協作，因為它使用 HDFS 來存儲數據，這些系統也是設計用來使用 HDFS 的。如果你需要進行這樣的數據處理和分析的話，HBase 可能是你目前的最佳選擇。
記住，這就像小馬過河！
因此，我停止了對 Cassandra 的優點的贊美，實際上，HBase 和 Cassandra 并不一定是一對完全的競爭對手。雖然它們常常可以用于同樣的用途，和 MySQL 和 PostgreSQL 類似，我相信在將來它們將會成為不同應用的首選解決方案。比如，據我所知 StumbleUpon 使用了 HBase 和 hadoop MapReduce 技術，來處理其業務的大量數據。Twitter 現在使用 Cassandra 來存儲實時交互的社區發言，可能你已經在某種程度上使用它了。
作為一個有爭議的臨別贈言，下面我們進入下一個話題。
注意：在繼續下一個小節之前，我要指出，Cassandra 在 0.6 版本會有 hadoop 支持，所以 MapReduce 整合能獲得更好的支持。
兄弟，我不能失去數據…
作為先前 CAP 理論爭議的一個可能結果，可能有這樣的印象，HBase 的數據似乎比 Cassandra 中的數據更安全。這是我希望揭露的最后一個關于 Cassandra 的秘密，當你寫入新數據的時候，它實際上立刻將它寫入一個將要存儲副本的仲裁節點的 commit log 當中了，也被復制到了節點們的內存中。這意味著如果你完全讓你的集群掉電，只可能會損失極少數據。更進一步，在系統中，通過使用 Merkle tree 來組織數據的過分不一致（數據熵），更加增加了數據的安全性
事實上，我對 HBase 的情況并不是非常確切——如果能有更細節的情況，我回盡快更新這里的內容的——但現在我的理解是，因為 hadoop 還不支持 append，HBase 不能有效地將修改的塊信息刷入 HDFS （新的對數據變化會被復制為多個副本并永久化保存）。這意味著會有一個更大的缺口，你最新的更改是不可見的（如果我錯了，可能是這樣，請告訴我，我回修正本文）。
所以，盡管希臘神話中的 Cassandra 非常不幸（譯注：Cassandra 是希臘神話里，特洛伊的那個可憐的女先知的名字，如果你不知道詳情的話，可以參考wiki），但你的 Cassandra 中的數據不會有危險。
注意：Wade Amold 指出， hadoop .21 很快就會發布，其中將會解決 HBase 的這個問題。