[轉載] HBase vs Cassandra：咱們遷移系統的緣由

轉載自http://www.csdn.net/article/2010-11-29/282698

個人團隊近來正在忙於一個全新的產品——即將發佈的網絡遊戲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中的數據不會有危險。