HBase
HBase是一個開源的分佈式存儲系統。他可以看作是Google的Bigtable的開源實現。如同Google的Bigtable使用Google
File System一樣，HBase構建於和Google File System類似的Hadoop HDFS之上。
Cassandra
Cassandra可以看作是Amazon
Dynamo的開源實現。和Dynamo不同之處在於，Cassandra結合了Google
Bigtable的ColumnFamily的數據模型。可以簡單地認爲，Cassandra是一個P2P的，高可靠性並具有豐富的數據模型的分佈式文件系統。
架構比較
上面兩個一個是HBase的架構層次圖，一個是Cassandra的結構圖。其實兩者並不對等。但是HBase內部的結構圖更加複雜，Hadoop，HDFS和HBase每個單獨部分都有若干個角色。而Cassandra與之不同，它不依賴任何一個已有的框架，且每個節點都是對等的。從架構上面來看，Cassandra顯然比HBase更加簡單。
造成這種設計層次的區別的原因，其實很顯而易見。HBase是一個Google Bigtable的複製者。Google Bigtable要解決的問題是如何基於Google File System構建一個分佈式數據庫存儲系統。對應的，HDFS是Google File System，因此HBase的任務事實如何基於HDFS構建一個分佈式數據庫存儲系統。
關於GFS和Bigtable，這裏要多囉唆幾句。GFS是google構建的，一個非POSIX的分佈式文件存儲系統。之所以GFS沒有嚴格遵循POSIX的標準，因爲GFS構建的目的是如何在造價低廉的服務器上存儲超大文件這樣一個系統。而POSIX對於小文件的查詢等要求則被GFS給忽略了。因此，GFS適合做的事情是在在計算機集羣裏面有效地存取超大規模的文件。但是真實的世界裏面，基於表結構的存儲系統更加有用。傳統的SQL數據庫無法使用GFS因爲GFS根本不提供POSIX接口，並且基於B+樹的存儲結構也讓做超大規模索引而引發的樹的分裂和重排成爲一個巨大的瓶頸。Bigtable就是爲了解決這個問題，提供一個基於表和列存儲的一個系統，以方便Google爲他們的搜索引擎提供存儲網頁和倒排索引的數據庫。
而Cassandra的被模仿者Dynamo在Amazon被使用的，是一個無單點故障的P2P的Key-Value的數據庫存儲系統。爲了讓Cassandra更方便使用，Cassandra的開發團隊也加入了ColumnFamily, Column, SuperColumn的概念。可以說，Dynamo所使用P2P的概念和相關技術（Bloom Filter，DHT等）不是第一次被軟件開發者使用，但是是嚴肅的大型軟件第一次成功應用。Cassandra的設計者正是Facebook從Amazon挖來的Dynamo的設計者和開發者。我們相信Cassandra和Dynamo的設計實現是非常相似的。
數據模型比較
Cassandra | HBase |
缺少類似於表的概念.所有的文檔都告訴你,有多個Keyspace的情況不常見.這意味着你必須在一個集羣中共享同一個key space.另外,新增keyspace需要重啓集羣才能生效. | 存在表相關的概念.每個表都有它自己的key space. 這一點對我們來說很重要.添加/刪除表都很容易,跟在RDBMS中一樣. |
使用字符串的Key.通常使用uuid作爲Key.如果希望你的數據按照時間排序,可以使用TimeUUID. | 使用二進制Key.通常將三個不同的項目組合在一起來構建一個Key.這意味着你可以搜索一個給定表中的多個鍵. |
即使使用TimeUUID,也不會發生熱點問題,因爲Cassandra會對客戶端請求做負載均衡. | 如果Key的第一部分是時間或者序列數,就會發生熱點問題.所有新的Key都會被插入同一個區域,一直到此區域被塞滿(因而導致出現熱點問題). |
支持列排序 | 不支持列排序 |
超列(Super Column)概念使得你可以設計非常靈活也非常複雜的表結構. | 不支持超列.不過可以設計一個類似與超列的結構,不過列名稱與值都是二進制的. |
沒有便捷的方法來自增長一個列的值.實際上,最終一致性的不同特性使得更新/寫入一條記錄並在更新後立即讀出非常困難.必須確保使用R+W>N來實現強一致性. | 由於設計上就是一致性.提供了一個非常便捷的方法來自增計數器.非常適合做數據彙總. |
剛開始支持Map Reduce接口.還需要有一個hadoop集羣來運行它.需要將數據從Cassandra集羣遷移到Hadoop集羣.不適合對大型數據運行map reduce任務. | 對Map Reduce的支持是原生的.HBase構建在Hadoop集羣上.數據不需要做遷移. |
如果不需要Hadoop的話,維護相對簡單. | 由於包含多個諸如Zookeeperr、Hadoop以及HBase本身的可活動組件，維護相對複雜. |
到目前爲止,還沒有本地化的Java Api支持.沒有Java文檔.雖然是使用Java編寫的,你還是必須用Thrift接口來與集羣進行通訊. | 有友好的本地Java API.比Cassandra更像是Java系統.由於我們的應用是基於Java的,這一點對我們很重要. |
沒有主節點,因此也沒有單點故障. | 雖然在概念上有一個主節點服務,HBase本身對它的依賴並不嚴重.即使在主節點宕機的情況下,HBase集羣仍然可以正常提供數據服務.Hadoop的Namenode是一個單點故障. |
特性比較
由於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的分佈不均勻，而無法做負載均衡，產生訪問熱點機器）。