摘取了一部分，全文請查看
http://blog.sina.com.cn/s/blog_633f4ab20100r9nm.html
背景
“這是最好的時代，也是最壞的時代。”
每個時代的人都在這么形容自己所處的時代。在一次次IT浪潮下面，有人覺得當下乏味無聊，有人卻能銳意進取，找到突破。數據存儲這個話題自從有了計算機之后，就一直是一個有趣或者無聊的主題。上世紀七十年代，關系數據庫理論的出現，造就了一批又一批傳奇，并推動整個世界信息化到了一個新的高度。而進入新千年以來，隨著SNS等應用的出現，傳統的SQL數據庫已經越來越不適應海量數據的處理了。于是，這幾年NoSQL數據庫的呼聲也越來越高。
在NoSQL數據庫當中，呼聲最高的是HBase和Cassandra兩個。雖然嚴格意義上來說，兩者服務的目的有所不同，側重點也不盡相同，但是作為當前開源NoSQL數據庫的佼佼者，兩者經常被用來做各種比較。
去年十月，Facebook推出了他的新的Message系統。Facebook宣布他們采用HBase作為后臺存儲系統。這引起了一片喧嘩聲。因為Cassandra恰恰是Facebook開發，并且于2008年開源。這讓很多人驚呼，是否是Cassandra已經被Facebook放棄了？HBase在這場NoSQL數據庫的角力當中取得了決定性的勝利？本文打算主要從技術角度分析，HBase和Cassandra的異同，并非要給出任何結論，只是共享自己研究的一些結果。
選手簡介
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的，高可靠性并具有豐富的數據模型的分布式文件系統。
分布式文件系統的指標
根據UC Berkeley的教授Eric Brewer于2000年提出猜測- CAP定理，一個分布式計算機系統，不可能同時滿足以下三個指標：
Consistency 所有節點在同一時刻保持同一狀態Availability 某個節點失敗，不會影響系統的正常運行Partition tolerance 系統可以因為網絡故障等原因被分裂成小的子系統，而不影響系統的運行
Brewer教授推測，任何一個系統，同時只能滿足以上兩個指標。
在2002年，MIT的Seth Gilbert和Nancy Lynch發表正式論文論證了CAP定理。
而HBase和Cassandra兩者都屬于分布式計算機系統。但是其設計的側重點則有所不同。HBase繼承于Bigtable的設計，側重于CA。而Cassandra則繼承于Dynamo的設計，側重于AP。
。。。。。。。。。。。。。。。。。。。
特性比較
由于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是你的首選。
就讓這個看起來永遠正確的結論結尾吧，上帝的歸上帝，凱撒的歸凱撒。大家都有自己的地盤，野百合也會有春天的！