架构

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:最常用的方式

属性

hbase的高表和宽表 hbase的表设计原则_服务器


解释:

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’:不重要的列簇不要开启