HBase使用场景概述

HBase特点

        HBase作为一款NoSQL数据库，由于CAP原则的存在以及本身实现的特点，并不能解决所有问题。下面先说一下HBase的特点：

高并发高吞吐量

• HBase底层使用LSM tree来作为数据处理模型，所以数据直接写入内存，写吞吐量得到保证。而读数据优先从内存中读取，这样可以覆盖大量的热数据，能满足大部分的热数据查询场景；冷数据在磁盘上是按照字典序排列，如果数据存储以及数据查询设计的合理，则大部分场景下的查询会转化为单rowkey的get以及磁盘上顺序数据的读取，吞吐量同样可以得到保障
• HBase的读写入口是zookeeper，从zookeeper中可以直接拿到数据实际存储的位置，如果数据存储设计的合理，则数据读写会分散到各个服务器上，压力负载均衡，加上数据的顺序存储，可以达到很高的并发量

易扩展

        HBase能很容易的横向扩展节点，HBase的易扩展体现在存储（HDFS）和计算（RegionServer）两个方面。

• HBase底层存储依赖HDFS，HDFS的易扩展特性就解决了HBase在存储上易扩展的特性

• 在集群中添加一个节点启动服务后，会在该服务器上增加一个HRegionServer服务，用来管理该节点上HBase数据读写以及管理相关的任务。master节点会周期的检测集群状态，发现新上线的节点后，会触发balance操作，将数据迁移到新节点上，使整个集群的服务器负载相对均衡；除此之外基本上不需要其他操作，对整个集群的压力和影响很小（相对于类似redis集群的一致性hash等节点数量敏感的算法）

        在易扩展的前提下，HBase能存储海量的数据，经常会作为PB级数据的存储平台

列式存储

        HBase被称为列式数据库，准确来说是面向列的存储，原因就是HBase按照列存储，在HBase中被称为“列族”，这也是HBase建表时需要定义的最小单位，也是HBase弱schema的一个体现，HBase建表只规约到列族，下面的列可以在使用时根据需求定义。列外数据按照列存储，可以使用效率更高的压缩方式，提高硬盘使用效率，在数据查询时也能方便高效的只拿出一个列的所有数据

稀疏存储

       在HBase中，值为null的列不占用存储空间，这就对数据中针对不同类型，null字段较多的场景比较友好

CP

      此CP非彼CP，而是数据库CAP原则中的CP，CAP原则的存在就代表着不同的业务场景下需要使用不同的数据库。而HBase的特点：强一致性（C）与分区错误容忍性（P），而在剩下的A中，HBase对应的是“弱可用性”：

• 强一致性保证HBase的client在任何时间和条件下得到的数据都是一致的，这对某些对一致性要求很高的场景来说是必须的；
• 作为NOSQL来说，分区错误容忍是必须的，即某一台或者几台机器下线后，集群仍然可以快速恢复并正常对外提供服务；
• 对于“弱可用性”，是因为强一致性实现的基础是HBase同一个Region有三份（默认，同HDFS的配置），同一时间只有一个在线并对外提供服务，另外两份只做数据的同步以及备份，当线上的region发现错误下线后，会在剩余的备份中找一个合适的region重新上线，回放hlog中的数据对外提供服务，这个短暂的重新上线的过程就造成了HBase在这段时间内这个region相关的数据无法对外提供服务，也就造成了HBase的“弱可用性”

HBase使用场景

关于我们在实际生产过程中满足哪些条件的时候可以选择HBase作为底层存储，这里给出几点建议：

数据量规模非常庞大

一般而言，单表数据量如果只有百万级或者更少，不是非常建议使用HBase而应该考虑关系型数据库是否能够满足需求；单表数据量超过千万或者十亿百亿的时候，并且伴有较高并发，可以考虑使用HBase。这主要是充分利用分布式存储系统的优势，如果数据量比较小，单个节点就能有效存储的话则其他节点的资源就会存在浪费。

要求是实时的点查询或者连续的范围查询

HBase是一个Key-Value数据库，默认对Rowkey即行键做了大量的优化，如zookeeper的寻址以及bloomFilter的排除，所以即使数据量非常庞大，根据行键的查询效率依然会很高，这使得HBase非常适合根据行键做单条记录的查询。另外因为HBase在硬盘上按字典序排列，所以根据行键的一部分做范围查询的效率也是相当不错的，但这需要根据业务进行良好的Rowkey设计，这里不多说了，后续可能单独说明。

能够容忍NoSQL短板

前面提及了NoSQL并不能解决所有问题，HBase也是一样，如果业务场景是需要严格的事务支持（HBase支持行级的MVCC，但是也仅仅是行级）、复杂的关联查询以及高可用场景等，不建议使用HBase。HBase有它适合的业务场景，我们不能苛求它能够帮我们解决所有问题。

数据分析需求并不多

虽然说HBase是一个面向列的数据库，但它有别于真正的列式存储系统比如Parquet、Kudu等，再加上自身存储架构的设计，使得HBase并不擅长做数据分析，或者说数据分析是HBase的弱项，所以如果主要的业务需求就是为了做数据分析，比如做报表，大量的数据聚合，那么不建议直接使用HBase，可以考虑使用elasticsearch。

如果能够满足上诉的几点，硬件条件也满足的情况下，强烈建议考虑使用HBase作为底层存储解决你的问题。

另外，在现在很多落地的生产环境中，都是使用HBase+elasticsearch（solr）配合的方式来达到存储和索引分离，计算和存储分离，各司其职，发挥各自的特长，从而达到最好的效果；也有很多newsql的数据库，如tidb，在关系型数据库的基础上进行了集群的支持，在某些业务场景下也可以达到很好的效果。

总而言之，没有最好的数据库，只有最合适的数据库，亦如我们的同事，我们的爱人！

 

传送门：HBase完整文档：HBase生产环境从入门到熟练使用，这一篇文章就够了