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将来还有很多地方需要提高。

建议继续学习：

1. HBase集群出现NotServingRegionException问题的排查及解决方法    (阅读：16278)
2. HFile存储格式    (阅读：14597)
3. hbase运维    (阅读：13697)
4. hbase介绍    (阅读：11097)
5. HBase技术介绍    (阅读：6824)
6. HBase随机写以及随机读性能测试    (阅读：6505)
7. HBase二级索引与Join    (阅读：5846)
8. HBase性能优化方法总结    (阅读：5844)
9. HBase Thrift 接口使用注意事项    (阅读：5459)
10. Cassandra和HBase主要设计思路对比    (阅读：4151)