rowkey行键设计
设计原则
数据按照Row key的字典序(byte order)排序存储。设计key时,要充分排序存储这个特性,将经常一起读取的行存储放到一起
长度原则:hbase的rowkey建议是8的整数倍,另外尽量不要太长,尽量别超过16,太长的话,比如占用100个字节的rowkey,1000w条就是10亿字节,将近1g的数据,影响hfile的存储效率,而且会占用memstore的内存过多,系统会缓存更少的数据
散列原则:例如按时间戳方式递增,不要将事件放在前面,建议将高位字段作为散列字段,程序随机生成低位字段为事件字段,可以提高数据均衡分布在每个regionserver实现负载均衡的几率,如果没有散列字段,首字段是时间戳会发生所有数据在一个regionserver上堆积的热点现象,在数据检索时负载会集中在个别regionserver中,降低查询效率
唯一原则: rowkey必须是唯一的
应用场景
针对事务数据rowkey设计
事务数据是带时间属性的,建议将事件存在rowkey中,会提高查询速度,可以按天建表,rowkey就可以只保留时分秒毫秒,4个字节就可以
针对统计数据
也是带时间,但是知道分钟,按天分表,保留小时分钟,两个字节
针对通用
可以按天分表也可单标模式采用自增序列作为唯一主键
支持多条件查询的rowkey设计
scan扫描查询可以通过setCaching和setBatch方法提高速度(空间换时间)
通过setStartRow和setEndRow限定范围,范围越小,性能越高
通过setFilter添加过滤器,分页多条件查询
column family列簇设计
一个表被分为多个region,一个region包含多个rowkey的数据
region中由多 个HStore组成。每个HStore对应了Table中的一个column family的存储
HStore存储是HBase存储的核心,由两部分组成,一部分是MemStore,一 部分是StoreFile
该regiion下所有的storeFile中最大的storeFile大小超过阀值即进行split
由于不同的列族会共享region,所以有可能出现,一个列族已经有1000万行,而另外一个才100行。当一个要求region分割的时候,会导致100行的列会同样分布到多个region中。
这样就出现了基数问题。(如果表存在多个列族,列族A有100万行,列族B有10亿行,那么列族A可能会被分散到很多个Region上,这会导致扫描列族A的性能低下)
一般列簇设计1-3个,不要太多