一個DBA眼中的HBase

Hadoop，HBase，NO-SQL是當今業界比較火的一些名詞。滿互聯網都是對它的他們的贊許，其實光芒的背后還有部分缺點。本文只是我vogts的一些觀點和想法。

    HBase的優點：

    分布式，易擴展，高性價比，運維成本低都是它的優點。HBase可以支持海量數據，單張表的數據量不上T，都不好意思出來打招呼。甚至可以拿很爛的SATA盤來作為存儲，由于依賴底層的HDFS。新裝的機器甚至可以不用做硬RAID。

    HBase可以在任何時候隨時宕掉2，3臺機器，就當什么都沒發生似的(當然master除外，但是hbase，hadoop的master節點負載都很”清閑“)。這是HBase本身分布式的架構，先天性的優勢。

    最近聽說非死book計劃全部放到hbase上，ebay的搜索引擎也計劃使用hbase，hbase甚至可以代替lunce來做搜索引擎。我承認HBase確實可以做到，也確實可以做的更好。關鍵就看你怎么用了。

    很多開發都爭著要上HBase，一窩蜂的熱度。不用hadoop，不用hbase，不用no-sql就要落伍了，云云。

    HBase的一些限制：

    由于HBase是一個NO-SQL的列存儲，很多特性目前是不支持的。比如：

    1：HBase名字像個Database的名字，它不支持SQL。必須依賴開發進行代碼解決。因為HBase實際存儲的是字節流。

     不過，由于沒有SQL，也產生了一些好處，就是沒必要去搞統計信息，擔心執行計劃走錯等問題的發生。

    2：沒辦法建立二級索引。對于mysql，oracle對于一張表建立多個索引是天經地義的時候，而HBase是不支持的。據說新版本會考慮，個人覺得如果HBase將來真的要發展，必須走google f1，這是終局。

    3：沒辦法做類似oracle的dataguard，或者mysql的master-slave。 當然由于數據量實在太大了，每天的IO吞吐量也太大了，就算做一個，估計性能立馬下降30%。單目前新版本的HBase，確實在考慮做master- slave，復制DML到備庫上應用。

    4：當然trigger，procedure什么的，也更不可能有了。

    5：對于性能診斷不夠給力，目前監控的粒度，差不多都是這些指標：

    http://sematext.com/spm/hbase-performance-monitoring/index.html

     Cluster and RegionServer read and write request counts

     Read, Write, and Sync min, max, and average latency

     Number of Stores opened on RegionServers

     StoreFile Index size and counts

     MemStore size

     Block cache: item count, hit cache and hit caching ratio, number of evictions, hits and misses, bytes free

     Compactions: compactionSizeNumOps, compactionTimeNumOps

     Compactions min, max, and average time

     Compactions min, max, and average size

     Compactions queue size

     Flush: flushSizeNumOps, flushTimeNumOps

     Flush min, max, and average size

     Flush min, max, and average time

     Splits: splitSizeNumOps, splitTimeNumOps

     Splits min, max, and average size

     Splits min, max, and average time

     HBase region count

     CPU usage

     RAM used/free

     System load

     Disk reads/writes

     Disk used/free

     Network interface traffic

     Swap IO

     JVM memory usage

     JVM garbage collection times and counts

     JVM thread counts

    單純從指標上來說，這些夠用了。這些指標確實能窺探出一些問題。但一個DBA更希望得到是：什么命令，在干什么，哪個客戶端，等待事件什么，等等，都必要要了解清楚。這個HBase目前還無法提供，希望在未來的新版本能夠加強。

    7：當region在進行compact或者split會出現短暫的讀寫堵塞。

    8：權限，安全上存在隱患。只要知道ZK的IP和端口，你就能輕松訪問HBASE，甚至不需要任何權限校驗。

    9：如果Row-Key的區分度不高，性能也不行。

    先吐槽到這里吧，HBase將來還有很多地方需要提高。