Cassandra VS. HBase

文章目錄

• Cassandra優缺點

轉載：http://hi.baidu.com/qnuth/blog/item/8720811ff79bca11314e15da.html

由於HBase和Cassandra的資料模型比較接近，所以這裡就不再比較兩者之間資料模型的異同了。接下來主要比較雙方在資料一致性、多拷貝複製的特性。

HBase

HBase保證寫入的一致性。當一份資料被要求複製N份的時候，只有N份資料都被真正複製到N台伺服器上之後，用戶端才會成功返回。如果在複製過程中出現失敗，所有的複製都將失敗。串連上任何一台伺服器的用戶端都無法看到被複製的資料。HBase提供行鎖，但是不提供多行鎖和事務。HBase基於HDFS，因此資料的多份複製功能和可靠性將由HDFS提供。HBase和MapReduce天然整合。

Cassandra

寫入的時候，有多種模式可以選擇。當一份資料模式被要求複製N份的時候，可以立即返回，可以成功複製到一個伺服器之後返回，可以等到全部複製到N份伺服器之後返回，還可以設定一個複製到quorum份伺服器之後返回。Quorum後面會有具體解釋。複製不會失敗。最終所有節點資料都將被寫入。而在未被完全寫入的時間間隙，串連到不同伺服器的用戶端有可能讀到不同的資料。在叢集裡面，所有的伺服器都是等價的。不存在任何一個單點故障。節點和節點之間通過Gossip協議互相通訊。寫入順序按照timestamp排序，不提供行鎖。新版本的Cassandra已經整合了MapReduce了。

相對於配置Cassandra，配置HBase是一個艱辛、複雜充滿陷阱的工作。Facebook關於為何採取HBase，裡面有一句，大意是，Facebook長期以來一直關注HBase的開發並且有一隻專門的經驗豐富的HBase維護的team來負責HBase的安裝和維護。可以想象，Facebook內部關於使用HBase和Cassandra有過激烈的鬥爭，最終人數更多的HBase team佔據了上風。對於大公司來說，養一隻相對龐大的類似DBA的team來維護HBase不算什麼大的開銷，但是對於小公司，這實在不是一個可以負擔的起的開銷。

另外HBase在高可靠性上有一個很大的缺陷，就是HBase依賴HDFS。HDFS是Google File System的複製品，NameNode是HDFS的單點故障點。而到目前為止，HDFS還沒有加入NameNode的自我恢複功能。不過我相信，Facebook在內部一定有恢複NameNode的手段，只是沒有開源出來而已。

相反，Cassandra的P2P和去中心化設計，沒有可能出現單點故障。從設計上來看，Cassandra比HBase更加可靠。

關於資料一致性，實際上，Cassandra也可以以犧牲回應時間的代價來獲得和HBase一樣的一致性。而且，通過對Quorum的合適的設定，可以在回應時間和資料一致性得到一個很好的折衷值。

Cassandra優缺點

主要表現在：

配置簡單，不需要多模組協同操作。功能靈活性強，資料一致性和效能之間，可以根據應用不同而做不同的設定。 可靠性更強，沒有單點故障。

儘管如此，Cassandra就沒有弱點嗎？當然不是，Cassandra有一個致命的弱點。

這就是儲存大檔案。雖然說，Cassandra的設計初衷就不是儲存大檔案，但是Amazon的S3實際上就是基於Dynamo構建的，總是會讓人想入非非地讓Cassandra去儲存超大檔案。而和Cassandra不同，HBase基於HDFS，HDFS的設計初衷就是儲存超大規模檔案並且提供最大輸送量和最可靠的可訪問性。因此，從這一點來說，Cassandra由於背後不是一個類似HDFS的超大檔案儲存體的檔案系統，對於儲存那種巨大的（幾百T甚至P）的超大檔案目前是無能為力的。而且就算由Client手工去分割，這實際上是非常不明智和消耗Client
CPU的工作的。

因此，如果我們要構建一個類似Google的搜尋引擎，最少，HDFS是我們所必不可少的。雖然目前HDFS的NameNode還是一個單點故障點，但是相應的Hack可以讓NameNode變得更皮實。基於HDFS的HBase相應地，也更適合做搜尋引擎的背後倒排索引資料庫。事實上，Lucene和HBase的結合，遠比Lucene結合Cassandra的項目Lucandra要順暢和高效的多。（Lucandra要求Cassandra使用OrderPreservingPartitioner,這將可能導致Key的分布不均勻，而無法做負載平衡，產生訪問熱點機器）。

 

所以我的結論是，在這個需求多樣化的年代，沒有贏者通吃的事情。而且我也越來越不相信在工程界存在一勞永逸和一成不變的解決方案。當你僅僅是儲存海量增長的訊息資料，儲存海量增長的圖片，小視頻的時候，你要求資料不能丟失，你要求人工維護儘可能少，你要求能迅速通過添加機器擴充儲存，那麼毫無疑問，Cassandra現在是佔據上風的。

但是如果你希望構建一個超大規模的搜尋引擎，產生超大規模的倒排索引檔案（當然是邏輯上的檔案，真實檔案實際上被切分儲存於不同的節點上），那麼目前HDFS+HBase是你的首選。