优势
相比较于面向行存储的Mysql,hbase面向列存储
Mysql做数据聚合操作时,都是读取一行数据,一行中很多值并不需要,就造成了性能浪费。
而面向列存储,只读取需要的那个列的值,就更适合海量数据的读取统计分析
hbase高可靠,高性能,面向列,可伸缩的分布式存储系统
介绍
按照列簇存储,一个列簇包含很多列。并且稀疏存储,只存需要的列,不是每行所有列的值都必须存值
一个列簇一个store,相当于垂直拆分
Region相当于分区,水平拆分
查询方式 scan/get 写入方式 put
这里rowkey 1001的name,sex两列数据因为都属于1001 rowkey,算同一行数据。所以这里scan只有2行数据。
因为稀疏表,所以可以一行没有name的列值。另外当根据rowkey范围查询如1001-1003时左闭右开,不会显示1003
put时以时间戳版本形式加入数据。表象是相同覆盖,没有新增。但当通过版本号查询时,删除的数据依然可以读取
读取的三种方式
Hbase 协处理功能
类似Spring AOP,Hbase支持自定义的增强操作。
比如postPut可以实现执行完hbase插入操作后,自动另一个新表插入该数据的后置功能
Hbase优化
高可用配置
HA配置backup-masters
预分区
rowkey存储是根据字典顺序排序的,建议不要用数字日期来分区。
例如rowkey 1000,1001,1002。当触发分区时,会按照rowkey字典中间值来划分,1000,1001和1002两个分区
以后1002以后的数据都只会进入1002的分区,容易造成数据倾斜
为了避免频繁的自动分区,可以提前规划好分区,提高性能
Rowkey设计
尽量平均划分数据到分区中,避免数据倾斜
原则
唯一性原则,类似mysql主键。rowkey根据字典排序,可以根据这个规则让经常查询的数据放一起
长度原则,不能太长太短 60-80byte,最大值64k
散列原则,随机均分分配
内存优化
Hbase常见问题
热点/数据倾斜问题
合并问题
小合并合并文件,大合并清除数据,提高读写效率
大合并/小合并具体内容看第一篇文章。大合并会阻塞写操作
合并时机:每次flush判断,也有专门checkFlush线程周期判断
宕机问题
Hbase region划分
rowkey根据字典排序的middleKey来划分分区,大小不一定一样