hbase存储优化

 

 

 

 

 

 

1、上面的2张图主要说明hbase的存储特点

(1)、每个值（每条记录的每一个列的值）的存储，都完整的存储了rowkey、column family、column、版本(时间戳)，以及该列的值。

     这样其实很浪费存储空间。对应的最直接的存储优化方案就是缩短rowkey、column family、column、版本(时间戳)的长度。在建表的时候就把这几项设置的极其短。

(2)、hbase是列式存储，天生就适合进行压缩等优化。

(3)、也可以通过（合并多个记录为一条记录）减少rowkey来减少表的记录数，达到减少key查找的效果，从而提升查询性能。代价就是每次查询的结果需要解析拆开，并且读取的对象比原来的单个记录要大。

 

 

 

 

2、hbase的存储优化的方案选择：压缩还是编码

 

(1)、参照这篇文章，对比了hbase编码和压缩2种优化方案的优缺点

A、REFIX_TREE编码方式不仅能起到压缩的效果

B、而且比较省CPU和内存。

http://blog.csdn.net/javastart/article/details/51820212

 

(2)、下面这篇文章，列出了PREFIX_TREE编码方式的优点：

A、REFIX_TREE提升从DataBlock中查找数据的效率。

B、省内存和cpu。

http://zjushch.iteye.com/blog/1843793

 

 

3、具体的优化命令

==========hbase命令================================================

 

disable 'logs:radwa'

alter 'logs:radwa', NAME => 'info', DATA_BLOCK_ENCODING => 'PREFIX_TREE' #修改编码（此编码效果最好）

#alter 'logs:radwa', NAME => 'info', COMPRESSION => 'snappy'     #修改压缩

enable 'logs:radwa'                                            #enable表后压缩还不会生效, 需要立即生效

major_compact 'logs:radwa'                                     #这个命令执行的时间会相当长, 会对整个集群的CPU, IO有大量的占用

 

 

==========hbase命令================================================

 

 

4、优化效果

   线上实测500G的表，编码后变为140G，效果还是不错的。

   至于查询效率的提升，我并没有测试。理论上是应该有提升的，当然您需要根据自己的业务实际选择自己的优化方式。

   这里任然有巨大的优化空间，比如把rowkey等设置的比较短，也可以省下很多存储空间。