一个DBA眼中的HBase

一个DBA眼中的HBase

Hadoop，HBase，NO-SQL是当今业界比较火的一些名词。满互联网都是对它的他们的赞许，其实光芒的背后还有部分缺点。本文只是我vogts的一些观点和想法。

HBase的优点：

分布式，易扩展，高性价比，运维成本低都是它的优点。HBase可以支持海量数据，单张表的数据量不上T，都不好意思出来打招呼。甚至可以拿很烂的SATA盘来作为存储，由于依赖底层的HDFS。新装的机器甚至可以不用做硬RAID。

HBase可以在任何时候随时宕掉2，3台机器，就当什么都没发生似的（当然master除外，但是hbase，hadoop的master节点负载都很”清闲“）。这是HBase本身分布式的架构，先天性的优势。

最近听说facebook计划全部放到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将来还有很多地方需要提高。

毕竟传统的RDBMS数据库已经历经几十年，而HBase从06年出道到现在，更像一个刚刚上幼儿园的小孩。我相信它应该会慢慢走向完善，终局应该是Google的F1。