【IT168 评论】Hadoop，HBase，NoSQL是当今业界比较火的一些名词。满互联网都是对它的他们的赞许，其实光芒的背后还有部分缺点。本文只是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，不用NoSQL就要落伍了，云云。
HBase的一些限制：
由于HBase是一个NoSQL的列存储，很多特性目前是不支持的。比如：
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
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。
