首先要答复一个问题，为何要应用HBase？
随着业务一直倒退、数据量一直增大，MySQL数据库存在这些问题：

  • MySQL反对的数据量为TB级，不能始终保留历史数据。而HBase反对的数据量为PB级，适宜存储长远的历史冷数据
  • 新增列的代价较高，数据量越大消耗工夫越长。而HBase能够随便减少列，空列不占据空间，业务模型能够灵便变动

要应用HBase，最重要的一点是rowkey行键设计，如果设计不妥，后续要改的代价十分大。

HBase行键设计准则

上面列几个HBase rowkey设计的准则：

  • 组合键：组合键是指拼接多个业务字段，如需查问，则业务字段必须作为rowKey的一部分
  • 字段程序：一对多，则一应该放在后面，以便可能scan失去后果，如用户id:订单id，如果反过来则无奈失去用户下的所有订单
  • 业务字段对齐长度：因为rowKey是按字典序排列的，所以须要对齐长度，比方id取12位，9位id前补齐3个0，否则就会呈现123456789比654321比排在后面的问题。对齐长度后，000000654321排在000123456789之前，合乎预期
  • 打散以防止热点：id与工夫无关，随工夫递增，如果不做解决可能导致局部节点有读写热点，加上前缀能够打散，如取 业务id的后几位 % region个数 作为rowKey的前缀

HBase利用举例

冷热数据拆散

  • HBase适宜作为冷数据存储，存储和查问海量历史数据
  • MySQL适宜作为热存储存储，反对数据读写、事务操作
  • 归档近期未更新的历史数据，新增数据至HBase，再删除MySQL记录

流水记录

  • 流水记录可随时新增字段
  • 适宜存储海量流水记录

简要回顾HBase架构

  • region：所有行按rowkey字典序排列，region是其中一部分，相当于分片，每个region只能在一个region server上
  • region server：能够蕴含一到多个region，调用HDFS的客户端接口对region所有数据进行读写操作
  • WAL：预写日志，WAL是Write-Ahead Log的缩写。事后写入，WAL是一个保险机制，数据在写到Memstore之前，先被写到WAL了。这样当故障复原的时候能够从WAL中复原数据
  • store：一个列族对应一个store，因而为了进步性能，不倡议应用超过2个列族。一个store蕴含一个memstore和多个HFile
  • memstore：数据写入WAL之后就会被放入memstore，次要用于在内存中对行做排序，排序实现后再写入HFile
  • HFile：数据的存储实体，memstore写满后就会写入HFile
  • region主动分片（split）、合并（merge）：region大小达到阈值后，会主动分区，反之会做合并region的操作
  • HFile合并（compaction）：删除数据后会导致HFile变小，须要合并以缩小HFile的数量，即缩小碎片文件数量，进步寻址效率