衆所周知，對比傳統的關系型資料庫，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領域。