HBase vs. Cassandra: NoSQL Battle! [轉]
from
http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
目前分佈式的，可擴展的數據庫正被猛烈的需要着，從社會媒體新興公司需要構建海量數據倉庫，到生物公司的蛋白質鏈分析。“大數據”每一天都變得更重要了。儘管Hadoop目前已經是大數據問題處理方面事實存在的標準。但仍然存在一些其他的分佈式數據庫，每個都有他們獨特的優勢。
有兩個數據庫獲得了最多的關注：HBase 和 Cassandra。關於這兩個雄心勃勃的項目的分歧可以歸納爲特性和架構方面的不同。HBase 像是山寨版的BigTable。而Cassandra 聲稱是BigTable/Dynamo 的混血兒。
就我看來，儘管Cassandra宣稱“寫不會失敗”是其優勢，在大多數使用場景下，HBase 是一個更健壯的數據庫。Cassandra 主要依賴Key-Value對作爲存儲對象，輔以類似表結構的方式增加數據的健壯性。一個事實是，儘管近來兩者越來越相似了，相對Cassandra 來說，當前使用HBase的人要更多。
CAP 和你的關注點
本文簡短描述一下 CAP理論（Consistency一致性, Availability 可獲得性, Partitioning tolerance 分區容忍）以及 起源於BigTable的HBase 和 起自Dynamo的Cassandra 在這方面有什麼不一樣。
在我們進一步深入前，讓我們做個簡單的分解
Consistency 一致性：“我當前正看到的數據和其他某個地方的別人看到的是一致的嗎？”
Availability: 可用性：“如果我的數據庫宕機了，會發生什麼事情，數據還能訪問嗎？”
Partitioning tolerance 分區容忍：“如果網絡間連接中斷，被分割在各自獨立的子網絡中，會發生什麼事，數據還能訪問嗎”
（此處原文和我的翻譯都不是很好，關於CAP理論，可參考http://pt.alibaba-inc.com/wp/dev_related_728/brewers-cap-theorem.html中描述）
CAP理論指出分佈式系統不得不在三種因素中做妥協。HBase認爲高一致性和高可用性更有價值。Cassandra 認爲高可用性和分區容忍更有價值。複製是一種設計上的折中處理。HBase目前還不支持複製，但正準備支持。Cassandra 支持複製，但附帶一些告誡和不利後果
讓我們對這兩種數據存儲做一些比較吧：
功能比較
1)處理能力
HBase 是Hadoop生態系統的一部分，有許多有用的分佈式處理框架支持，比如PIG,Cascading, Hive, 等等。這是的複雜的數據分析變得相對簡單一些，沒有重排序和手工編碼的需要。另一方面，在Cassandra上有效的運行MapReduce 是比較複雜的，因爲它的所有鍵存放在一個大“空間”中，因此MapReduce 框架不知道如何順利的分解和分配數據。這需要一些hackery 去處理這種情況（不知道怎麼翻譯這句話）。
事實上，這兒就有些補丁代碼用來集成 Cassandra/Hadoop
+ /*
+ FIXME This is basically a huge kludge because we needed access to
+ cassandra internals, and needed access to hadoop internals and so we
+ have to boot cassandra when we run hadoop. This is all pretty
+ fucking awful.
+
+ P.S. it does not boot the thrift interface.
+ */
這讓我感到害怕。
概要來說，Cassandra 也許在存儲方面是比較有效的，但是在數據處理方面，HBase更具有優勢。
2)安裝和易用性
Cassandra 是簡單的Rubygems方式安裝，這讓人印象深刻。但你仍需要做相當部分的手工配置。然而，HBase 是一種.tar格式的安裝文件，你需要自己一步步的安裝和設置。HBase 有詳盡的文檔，這讓安裝過程變得簡單了些。
HBase同時還發布了一個非常好的Ruby shell，簡化了數據庫的創建和修改、設置和檢索數據。我們經常地用它來測試我們的代碼。而Cassandra 並沒有這樣的shell腳本，只有基本的API。HBase 此外還有很好的基於Web的UI，你可以用來查看集羣狀態，確定哪個節點存儲了什麼樣的數據，等等操作。Cassandra 缺少WEB UI支持和Shell腳本支持使得它操作起來不太方便。
總的來說，Cassandra 安裝上比較容易，但是可用性不如HBase。
3) 架構
Cassandra 和HBase 的思想和架構上的基礎性差異引起了很多的爭議，爭議的主題是“誰是更好的”。
立刻，Cassandra 宣稱“寫操作永遠不會失敗”，而對HBase來說，如果目標region歸屬的region server 宕機的話。寫操作將被阻塞，直到該region被重新調配到新的regionserver上。當然這個情況發生概率非常小，但是在足夠大規模情況下，確實會發生。此外,HBase 有一個單點故障點（Hadoop NameNode），但隨之Hadoop的進化，這將不是很大的問題。HBase有行級鎖，但是Cassandra 沒有。
應用程序通常假設獲取數據時，數據是正確性和且不會被改變，所以“最終一致（Eventually Consistent）”的思想是有問題的。Cassandra 有內部的vector clocks 方法解決一致性問題，（一種複雜的，但是可工作的方法，這種方法下，通常是時間戳最新的數據勝利了）。HBase或Bigtable則把解決數據一致性衝突的問題推給了應用程序，因爲他們把所有的數據都用時間戳做多版本控制。
另外一個架構上的批評意見是Cassandra 每次安裝只支持一張表。這意味着你不能故意多拷貝一份數據使得分析變得更容易進行。（新版本已經解決）Cassandra 更像一個鍵值存儲，而不是數據倉庫。此外，Schema發生改變時，需要集羣重啓.
Cassandra JIRA說Schema發生改變時，需要做如下的事情：
Kill Cassandra Start it again and wait for log replay to finish
Kill Cassandra AGAIN Make your edits (now there is no data in the commitlog)
Manually remove the sstable files (-Data.db, -Index.db, and -Filter.db) for the CFs you removed, and rename files for CFs you renamed
Start Cassandra and your edits should take effect
缺乏時間戳控制的多版本功能，缺乏最終一致性、沒有regions（導致MapReduce變得困難），每次安裝只能支持一張表。基於這些問題，很難宣稱Cassandra 實現了BigTable模型。
(原文如此，With the lack of timestamp versioning, eventual consistency, no regions (making things like MapReduce difficult), and only one table per install,
it’s difficult to claim that Cassandra implements the BigTable model.
可能翻譯的不準確)
4)複製
Cassandra 對由高速光纖連接的小型數據中心（幾百個節點左右）是最佳的。這部分來自Amazon的Dynamo的遺產。HBase 基於Google研究的產物，適合處理散佈在全球各地的節點，連接它們的網絡是“緩慢”且不可預料的Internet網。
一個主要的差別是它們在多數據中心見覆制方式的差別。Cassandra 使用P2P共享方式，Hbase（即將到來的版本）更多使用了數據加日誌備份的方式，又被稱爲‘log shipping’.每種方式都有自己的優勢場景。爲了更好的理解，下面畫兩個圖來解釋：
第一幅圖是Cassandra 的複製模型
1）The value is written to the “Coordinator” node
2）A duplicate value is written to another node in the same cluster
3）A third and fourth value are written from the Coordinator to another cluster across the high-speed fiber
4）A fifth and sixth value are written from the Coordinator to a third cluster across the fiber
任何的衝突都在cluster內部解決，通過檢查時間戳來決定誰是最合適的。這種場景最大的問題就是現實世界中需要的可審計性。節點是最終一致的--如果一個數據中心失敗了，無法知道有多少副本需要被更新。這在實際場景中會非常痛苦--當你的一個數據中心失敗了。你通常希望知道準確的，什麼時候可以恢復數據一致性，這樣後續的恢復操作才能平穩進行。
需要着重申明的是Cassandra 依賴數據中心之間的告訴光纖。如果你的寫操作耗費1-2ms的話，沒有什麼問題。但是當數據中心宕機，你不得不迴歸到在中國的第二個數據中心，而不是20公里外的第一個數據中心。無法想象的延遲會導致寫超時和嚴重的數據不一致。
讓我們看看HBase複製模型（注：這將在.21版本發佈）
事情是這樣的：
數據首先被寫到HBase 內存的Write-ahead-log 中，然後數據又被刷到磁盤上。因爲Hadoop 分佈式文件系統的特性，磁盤上的文件自動的被複制。數據進入到“複製日誌”中，“複製日誌”被管道傳送到另外一個數據中心。通過HBase/Hadoop精心設計的事件序列，數據中心間的一致性是非常高的。一般情況下，同一時間段內只有一個數據片。如果不是，HBase的時間戳允許你的代碼來衡量們那個版本的數據是正確的，而不是cluster自己選擇。因爲“日誌複製”的天性，你可以始終知道數據一致性差異情況--一個很有用的工具，當另外一個數據中心宕機的時候。此外，使用這種方式，使得網絡高延遲場景下恢復變得容易了，比如洲際數據傳輸情況。
5）知道選擇誰
Amazon 和 google的商業背景解釋了Cassandra 和HBase各自強調的不同功能
Cassandra 設想的是數據中心間高速的網絡連接，這是Amazon’s Dynamo的產物：Amazon 數據中心從歷史上看就是彼此靠的非常近（幾十公里遠），通過高速網絡連接。Google 擁有橫貫大陸的數據中心，都通過標準的internet連接，這意味着需要更可靠的複製機制。
如果你需要高可靠性的寫操作和最終一致性，那麼Cassandra 是最好的一個。然而很多程序並不希望看到最終一致性，並且它仍然缺乏很多特性。此外儘管寫不會失敗，當變更schema時，Cassandra 的集羣需要宕機重啓。HBase更多的關注在讀，但是可以出來很高的讀寫負載。它更接近數據倉庫的概念，能服務每秒百萬請求。和MapReduce 的結合使HBase 更有價值，更多才多藝。