眾所周知，對比傳統的關系型數據庫，NoSQL有著更為復雜的分類——鍵值、面向文檔、列存儲、搜索引擎等等。繁多的分類讓NoSQL有著更強的業務針對性，因此在性能上對比傳統關系型數據庫有著顛覆性的提升。然而這種針對性同樣給企業帶來了一定程度的困擾，比如專業工程師的培養/聘請、架構的變遷等，同時這種群雄割據的局面也不利于NoSQL的整體發展。通用、統一才能有更好的發展;隨著NoSQL的發展，我們似乎也越來越需要一種技術去打開當下這個局面。

近日，MapR Technologies的首席數據工程師Michael Hausenblas與DataStax的聯合創始人兼CTO Jonathan Ellis針對這個問題展開了討論，并就“HBase是否能成為NoSQL領域的領導者”發表了不同的觀點。在看他們觀點之前，我們首先看一下為什么會是HBase。

HBase及NoSQL現狀

HBase是Google BigTable的仿制品，當下最流行大數據處理平臺Apache Hadoop的一部分。高貴的血統無疑讓HBase備受關注，也給它帶來了更廣闊的發展空間。然則HBase的人氣究竟如何，我們不妨看一下 DB-Engines的數據庫人氣排行榜 ：

從最新的排行榜我們可以發現前10中只有一個NoSQL數據庫——MongoDB，而HBase排名第16，NoSQL領域第6，在列存儲數據庫中排名也只是第2，第1被Cassandra搶走。

上表是2013年1月份的部分排行，對比MongoDB、Cassandra這些人氣增長很快的數據庫，HBase的增長也并不突出。

如此看來即使HBase最后可以成為NoSQL領域的領軍者，這條成功路上也是遍地荊棘。長話短說，下面就看一下兩位數據領域佼佼者的不同看法，以下為譯文：

正方：Michael Hausenblas是MapR Technologies的首席數據工程師兼EMEA。在大規模數據集成研究和開發上有著豐富的經驗。他認為，基本上所有NoSQL解決方案都有著技術限制，而與Hadoop的整合將大幅度提高HBase的采用率。

HBase制霸將是個必然的結果，但是……

為了理解這個問題，我們必須和現狀集合起來。Martin Fowler及Mike Stonebraker都認為“混合持久化”才是王道，“同一個標準不可能適合所有人”。

因此這里我說的制霸不是傳統數據庫過去10年內一直使用的市場份額的標準，而是“Apache HBase是不是擁有更廣泛的使用場景，以及是否比其它數據庫擁有一個更大的社區”。

我們可以大膽斷言的是：當下可供選擇的NoSQL技術已經超過100種(DB-Engines排行榜已收錄114個NoSQL數據庫)，包括MongoDB、Riak、Couchbase、Cassandra等等。但是在這個大數據的時代，趨勢不再是專業的信息持久化，而是大規模的多樣數據處理，因此即使是MongoDB如此流行的NoSQL也必將會被HBase超越。

為什么?因為MongoDB有明顯的擴展性缺陷，而隨著Hadoop采用的快速增長，類似HBase這種內置的NoSQL解決方案在規模和人氣上都有著天生的市場優勢。HBase擁有不同方面巨大而多元化的社區，它連接著多個方面：用戶、開發者、多個商業供應商以及云端的可用性——來自AWS最新的功能。

從兩個數據庫的歷史上看，HBase和Cassandra擁有很多相同之處。HBase于2007年在Powerset建立(后被微軟收購)，開始是作為Hadoop的一部分，后來成為一個Top-Level-Project。Cassandra則是2007年起源于Facebook，開始是開源項目，后由Apache孵化，當下同樣是個Top-level-Project。不管是HBase還是Cassandra都是列存儲鍵值類型數據庫，都擁有良好的橫向可擴展性、健壯性和彈性，擅長處理巨大體積的數據。

但是他們在設計理念上卻有著天壤之別：Cassandra借鑒了許多Amazon DynamoDB系統的元素，使用最終一致模型，并且進行了寫入優化;而HBase克隆的是Google的BigTable，進行了讀取優化，并擁有強一致性。這里HBase存在一個很有意思的強項就是——Facebook，Cassandra的制造者，使用HBase代替了Cassandra在他們內部使用。

從開發者角度上來看，HBase提供的強一致性會讓開發過程變得輕松。而這里對于最終一致性存在的誤區就是：它改善的是寫入的速度——持續的寫操作可能會造成延遲，為了保持最終一致性付出了代價，卻沒有達到應有的效果。

基本上所有NoSQL解決方案都存在技術限制，比如會導致高延時的壓縮、無法自動分片、可靠性隱患以及節點故障轉移時間太長。而在MapR建立的企業版HBase中，我們提供了立即恢復、無縫分片以及高可用性，同時還剔除了壓縮。

最后，鑒于HBase與Hadoop生態系統的整合力度，它可以更好的與Hive、Pig等組件協作。

匯總，HBase必然制霸小規模寫入及大規模查詢的使用場景，而最近的一些創新提供的架構優勢也可以用于擺脫壓縮的困擾。

反方：Jonathan Ellis是初創公司DataStax的聯合創始人兼首席技術官，而DataStax是一家著名開源軟件公司。他認為HBase受眾多的缺陷困擾，比如：部署難、操作復雜、社區零散以及致命的架構缺陷。種種因素之下，HBase根本不具備成為領導者的資質。

NoSQL有著不同的專長，比如：某些領域HBase就無法與圖數據庫和文檔數據庫匹敵;但是即使是列存儲數據庫中，HBase也不能獨占鰲頭。導致HBase采用率一般的問題在于：可以通過投入巨量物理和人力解決的工程問題和無法彌補的天生架構缺陷。

工程問題

1. 運營的復雜并且容易發生故障

HBase的配置非常麻煩，最低的限度都需要包括Zookeeper ensemble、primary HMaster、secondary HMaster、RegionServers、active NameNode、standby NameNode、HDFS quorum journal manager及DataNodes。雖然配置可以自動化，但是如果無幫助下安裝難度太大，在故障發生時，你如何去尋找故障，比如：RegionServer失效或者一個 lower-level NameNode故障。使用HBase需求大量的專業知識——甚至是最簡單的監視;如果你需要定期的備份，那么你可以去尋求上帝的幫助了!

2. RegionServer故障轉移需要10到15分鐘

HBase將行分割到不同的region中，通過 RegionServer來管理。RegionServer存在單點故障，當它發生故障時，一個新的RegionServer必須被選舉出，而在可以投入之前，必須重新完成write-ahead日志里的內容。

3. 使用HBase開發是非常痛苦的。

HBase的API非常笨拙并且具有太強的Java特色，非Java客戶端只能委托給Thrit或者REST。對比起來，Cassandra Query Language則提供了多語言開發者都熟悉的體驗。

4. HBase社區就是盤散沙

以Apache為主的社區是眾所周知的不穩定，Cloudera、Hortonworks以及其他高端用戶都是在閉門造車。相反開源的Cassandra社區各個機構間毫無派系，比如DataStax、Netflix, Spotify、Blue Mountain Capital等。

總的來說，HBase和其它NoSQL平臺間的差距越來越大。在我第一次評估的時候，HBase的工程進展可能會差Cassandra 6個月，而如今至少差2年。

架構缺陷

1. Master-oriented的設計讓HBase失去了靈性

通過RegionServer master來路由所有讀寫操作意味著HBase喪失了數據中心的active/active異步復制，你也不能在一個集群的不同副本集中單獨的執行工作負載。想比之下，Cassandra的peer-to-peer復制卻允許與Hadoop的無縫集成，當你需求線性一致性，沒有ETL的Solr和Cassandra卻允許你少量使用輕量級事務。

2. 故障轉移意味著宕機

許多應用甚至不能容忍1分鐘的宕機，而這恰恰是HBase設計的固有問題，每個RegionServer都是個單點故障。然而一個分布式系統應該是在某個副本發生故障，我們不需要做特殊的恢復處理，系統仍然能正常運作。

3. HDFS是主要為大體積文件設計的流訪問系統

HBase建立于一個專為批處理優化的文件系統，這直接導致了HBase的低性能。特別是讀取，尤其是使用SSD的情況。就像是30年前為準大數據負載設計、未優化B樹的傳統關系型數據庫引擎，HDFS并未做好主要設計目的與關鍵功能彌補上的平衡：

在同一個集群中混合機械和固態硬盤，并為負載分配適當的硬盤類型

快照、增量備份和及時的恢復

壓縮流量以避免應用程序的峰值響應時間

動態的將請求路由到性能最高的副本上

HBase基于批處理的設計決定了它低下的性能，使其無法適應高速、隨機訪問負載，然而NoSQL運動的特性恰恰是這些，因此HBase永遠不可能制霸NoSQL領域。