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

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

HBase及NoSQL現(xiàn)狀

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

從最新的排行榜我們可以發(fā)現(xiàn)前10中只有一個NoSQL數(shù)據(jù)庫——MongoDB，而HBase排名第16，NoSQL領(lǐng)域第6，在列存儲數(shù)據(jù)庫中排名也只是第2，第1被Cassandra搶走。

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

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

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

HBase制霸將是個必然的結(jié)果，但是……

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

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

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

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

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

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

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

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

最后，鑒于HBase與Hadoop生態(tài)系統(tǒng)的整合力度，它可以更好的與Hive、Pig等組件協(xié)作。

匯總，HBase必然制霸小規(guī)模寫入及大規(guī)模查詢的使用場景，而最近的一些創(chuàng)新提供的架構(gòu)優(yōu)勢也可以用于擺脫壓縮的困擾。

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

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

工程問題

1. 運營的復雜并且容易發(fā)生故障

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

2. RegionServer故障轉(zhuǎn)移需要10到15分鐘

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

3. 使用HBase開發(fā)是非常痛苦的。

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

4. HBase社區(qū)就是盤散沙

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

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

架構(gòu)缺陷

1. Master-oriented的設(shè)計讓HBase失去了靈性

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

2. 故障轉(zhuǎn)移意味著宕機

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

3. HDFS是主要為大體積文件設(shè)計的流訪問系統(tǒng)

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

在同一個集群中混合機械和固態(tài)硬盤，并為負載分配適當?shù)挠脖P類型

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

壓縮流量以避免應(yīng)用程序的峰值響應(yīng)時間

動態(tài)的將請求路由到性能最高的副本上

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