大規模數據處理Hbase vs Cassandra

Question

在我對大規模數據存儲解決方案進行研究後，我幾乎登陸Cassandra。但是它一般說Hbase是更好的大規模數據處理和分析解決方案。

雖然兩者都是相同的鍵/值存儲和均爲/可運行（卡桑德拉最近）的Hadoop層然後是什麼使Hadoop的更好的候選時，需要對大量的數據處理/分析。

我還發現約在兩 http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

良好的細節，但我仍然在尋找HBase的具體優勢。

雖然我更加堅信有關卡桑德拉，因爲它添加節點和無縫複製和沒有一點破壞特徵簡單。它還保留了二級索引功能，所以它是一個很好的補充。

Answer 1

試圖確定哪個最適合你，這取決於你將要使用它的原因，他們每個人都有自己的優勢，沒有更多的細節，它變得更像是一場宗教戰爭。你引用的這篇文章也超過了一年，從那以後都經歷了許多變化。請記住，我不熟悉最近的Cassandra開發。

話雖如此，我會轉述HBase的提交者安德魯Purtell，並添加了一些我自己的經驗：

• HBase的是更大的生產環境中（1000個節點），雖然仍處於Cassandra的的球場〜400節點安裝，所以它真的是一個邊際差異。

• HBase和Cassandra都支持羣集/數據中心之間的複製。我相信HBase更多地向用戶公開，所以它看起來更復雜，但是你也獲得了更多的靈活性。

• 如果強大的一致性是您的應用程序需要的，那麼HBase可能更適合。它從根本上設計爲一致。例如，它允許更簡單地實現原子計數器（我認爲Cassandra剛剛得到它們）以及Check和Put操作。

• 從我的理解來看，寫入性能非常好，這是Facebook使用HBase爲其使者的原因之一。

• 我不確定Cassandra的有序分區程序的當前狀態，但過去需要手動重新平衡。如果你願意，HBase會爲你處理。有序分區對於Hadoop風格處理非常重要。

• Cassandra和HBase都很複雜，Cassandra只是把它隱藏得更好。如果你看看代碼庫Cassandra就像分層一樣，HBase通過使用HDFS來存儲更多的信息。如果你比較Dynamo和Bigtable的論文，你會發現Cassandra的操作理論實際上更復雜。

• HBase有更多的單元測試FWIW。

• 所有Cassandra RPC都是Thrift，HBase擁有Thrift，REST和本地Java。 Thrift和REST只提供全部客戶端API的一部分，但如果您希望純粹的速度，那麼本地Java客戶端就在那裏。

• 對等和主從同時具有優勢。主 - 從設置通常使調試變得更容易，並降低了一些複雜性。

• HBase並不僅限於傳統的HDFS，您可以根據自己的需要更換底層存儲。MapR看起來很有趣，我聽說過好東西，雖然我沒有用過它自己。

Answer 2

作爲卡桑德拉開發者，我在回答這個問題的另一面更好：

• 卡桑德拉更好地伸縮。已知Cassandra的規模爲over 400 nodes in a cluster;當Facebook在HBase之上部署消息傳遞時，他們不得不在100-node HBase sub-clusters之間進行分割。
• Cassandra支持數百甚至數千個ColumnFamilies。 「HBase currently does not do well with anything above two or three column families」。
• 由於沒有"special" nodes or processes一個完全分佈式系統，Cassandra是simpler to set up and operate，比較容易解決，而且更加堅固。
• Cassandra的多主複製的支持，意味着你不僅獲得多個數據中心的明顯的權力 - 地理冗餘，當地的延遲 - 但你也可以實時和分析工作負載分成不同的組，與realtime, bidirectional replication between them。如果你不將這些工作量分開，他們將會非常激烈地競爭。
• 因爲每個Cassandra節點都管理自己的本地存儲，所以Cassandra具有顯着的性能優勢，不太可能顯着縮小範圍。 （例如，它是標準的做法，把卡桑德拉commitlog一個單獨的設備上，因此它可以做它的隨機I /讀取請求暢通Ø順序寫。）
• 卡桑德拉允許你選擇你想有多強，它要求一致性以每個操作爲基礎。有時候這會被誤解爲「Cassandra不會給你強大的一致性」，但這是不正確的。
• Cassandra提供RandomPartitioner以及更類似Bigtable的OrderedPartitioner。 RandomPartitioner不太容易出現熱點。
• 卡桑德拉提供與性能堪比memcached的現場或非堆緩存，但沒有高速緩存一致性問題或需要額外的移動部件
• 非Java客戶端的複雜性不是二等公民

據我所知，HBase現在的主要優勢（HBase 0.90.4和Cassandra 0.8.4）是Cassandra尚不支持透明數據壓縮。 （這已經是added for Cassandra 1.0，將在10月初發布，但今天這對HBase來說是一個真正的優勢。）對於Hadoop批處理完成的各種範圍掃描，HBase也可能會得到更好的優化。

也有一些事情，不一定是好，還是壞，只是不同。 HBase更嚴格地遵守Bigtable數據模型，其中每列都是隱式版本化的。Cassandra刪除版本，並添加SuperColumns。

希望有幫助！

Answer 3

使用100個節點hBase集羣的原因並不是因爲HBase不能擴展到更大的大小。這是因爲以滾動方式進行hbase/HDFS軟件升級更容易，而不會降低您的整個服務。另一個原因是阻止單個NameNode成爲整個服務的SPOF。此外，HBase正在用於各種服務（不僅僅是FB消息），並且在基於100節點pod方法的基礎上設置大量HBase集羣的方法是謹慎的。數字100是adhoc，我們沒有專注於100是否是最優的。