架构
hbase存储原理
底层的存储是字节存储,按照字典排序,key-value格式存储:
key=ts+rowkey+cf+col,value=真正的值
物理模型
一个regionserver中管理多个region,region是负载均衡的最小单位
一个region里边有很多store,一个store对应一个列簇,但一般情况下只有一个store
一个store里边有一个memstore和多个storefile(对HFile(hadoop的二进制文件)的封装)
HFile和Hlog是HBase中两大文件存在格式,HFile用于存储数据,Hlog用于保证数据写入 HFile中。
表设计
rowkey的设计
1、业务原则
2、长度原则(开发人员建议是10-100bytes,但是最好不超过16bytes,最长为64k)
3、散列原则(避免热点问题)
补充:
对于单调递增的时间类型数据,很容易被散列到同一个Region中,这样它们会被存储在同一个服务器上,从而所有的访问和更新操作都会集中到这一台服务器上,从而在集群中形成一个hot spot,从而不能将集群的整体性能发挥出来。
4、唯一原则
场景:
hash_deviceId_createTime_type
根据deviceId获取gps所有的信息,和type信息
根据type,获取deviceId的全部信息
rowkey按照字典顺序排列
原始 实际 预想
0 0 00
1 1 01
2 2 02
03 22 03
22 23 22
23 3 23
33 33 33
预分区
-》共有5个region
create ‘t1’, ‘f1’, SPLITS => [‘10’, ‘20’, ‘30’, ‘40’]
-》通过splits.txt进行预分区
create ‘t1’, ‘f1’, SPLITS_FILE => ‘splits.txt’
-》系统默认进行分区
create ‘t2’, ‘f1’, {NUMREGIONS => 15, SPLITALGO => ‘HexStringSplit’}
-》通过API进行进行分区
hbaseadmin.createTable(tablename,split[][])
读取数据三种方式
-》get:必须指明rowkey,查询最快的方式
-》scan:全局扫描,一般不用
只要不进行compact操作,对版本数进行整合的,之前的操作就不会丢失
-》scan+filter:最常用的方式
属性
解释:
BLOOMFILTER:布隆过滤器
VERSIONS:版本数
COMPRESSION:压缩
MIN_VERSIONS:最小版本数
TTL:存活时间
BLOCKSIZE:存储数据的block的大小,64K
IN_MEMORY:是否开启,作用是:有选择的column families放到RegionServer内存中,例如Meta元数据信息
BLOCKCACHE:是否开启缓存
BLOOMFILTER:布隆过滤器
row:行级,当查询数据时,检索storefile之前,判断这个storefile中是否有需要的 rowkey,如果没有,就查看另外一个storefile,查看所需要的rowkey
rowcol:行列级,是否有需要的rowkey+column
开启了以后,storefile中会存储一部分元数据,消耗一定的内存
blockcache块缓存
->IN_MEMORY (hbase的meta就在这里边存储的)
->BLOCKCACHE => ‘true’:不重要的列簇不要开启