制作钓鱼网站属于什么罪,自创网站,自动生成logo的软件,网站建设维护保密协议书Hbase中Rowkey的设计方法
过去对于Rowkey设计方法缺乏理解#xff0c;最近结合多篇博主的文章#xff0c;进行了学习。有不少心得体会。总结下来供后续学习和回顾。
一、设计Rowkey的三个原则
1.长度原则#xff1a;长度不能太长#xff0c;小于100个字节。可以偏端一些…Hbase中Rowkey的设计方法
过去对于Rowkey设计方法缺乏理解最近结合多篇博主的文章进行了学习。有不少心得体会。总结下来供后续学习和回顾。
一、设计Rowkey的三个原则
1.长度原则长度不能太长小于100个字节。可以偏端一些短一些可以方便存储。最好是8的倍数。因而建议16字节为好。
太长的话有两点影响1.降低HFile的存储效率需要话更多的空间存储不包含实际数据的Rowkey。2.会使MemStore的缓存效率下降缓存大小固定Rowkey越长能缓存的数据个数越少。
2.唯一原则
一个Rowkey只唯一标识一组数据若出现两条数据的数据部分一样但Rowkey不一样那么就不是同一条数据。
3.散列原则
设计的Rowkey应该是分布于各个Hbase节点上的这样主要是为了防止出现热点造成单个RegionServer服务器压力过大。
二、写优化与读优化
Rowkey在数据进行读写时及其重要。在写入时当Rowkey足够分散能均匀的写入不同的HRegionServer时写入效率就会提升。在读取时当Rowkey设计的足够好就可以避免对所有数据进行扫描。甚至于仅需要扫描某个Region中的一部分数据即可。为了使写入和查询的效率进一步提高可以对Rowkey进行一些设计。
1.写优化
写优化主要有三种技术层面的操作hash值加盐和反转
hash值
优点一般使用MD5生成的hash值足够散列能均匀分布。且hash值能讲部分变长字符串转化为定长字符串。
缺点单纯的使用hash值容易使数据散乱的分布当查找的时候会进行全表扫描遍历所有region
加盐
所谓加盐就是指在一部分有实际含义的数据中添加一部分无实际含义的数据。
例如将Rowkey直接设置为时间戳的话有可能造成大量的数据堆积在同一个region中。此时在时间戳之前添加一个随机的hash值就会使数据均匀分布且查找数据时可以按时间戳进行查找。 有如下三个时间戳timestamp1、timestamp2、timestamp3若将时间戳作为Rowkey可能三条数据都被存储在一个Region上。若对其分别进行加盐操作在时间戳之前加上一个分区号此时三个时间戳变为字符串 0timestamp1、1timestamp2、2timestamp3。此时首位变成了不同的数也更容易分散到不同的Region中 优点确保Rowkey在包含实际意义的情况下也能够均匀分布在Region中。
缺点读取时依然需要遍历所有region
反转
反转操作一般可以用于时间戳此时反转后的时间戳作为Rowkey的一部分时既能使Rowkey分散于各个Region又方便捕获数据的最新版本。
2.读优化
相比于写优化读优化是一个复杂的议题。原因在于写优化通常只需要确保Rowkey不会影响数据在Region中的分布。而读优化则依据场景的不同设计不同的Rowkey去缩小扫表范围。
在上一小节对写优化方法的总结中反转操作是读优化中常用的主要是为了方便获取最新数据。
下面举两个应用场景下的读优化
1.目标在Hbase中存储用户订单状态
Rowkey反转订单id反转时间戳
通过反转订单id能避免所有数据存储在同一个Region中的情况通过反转时间可以便于获取最新订单。
rowkey可以表示为reverse(userId) (Long.MAX_VALUE - timestamp)
注意此处时间戳反转使用(Long.MAX_VALUE - timestamp)。主要是为了方便查询。如果要查询某段时间的操作记录则使用如下方法
startRow是[userId反转] [Long.MAX_VALUE - 结束时间]
stopRow是[userId反转] [Long.MAX_VALUE - 起始时间]
2.目标存储最近10分钟的热点数据
Rowkey两位随机数Salt eventId Date kafka的offset
其中两位随机数用于使数据写入时均匀分布在不同的Region中后两个eventId和Date则由查询语句的查询条件所决定。如果查询之前总是能获取到eventId和某一个数据字段则将两个字段放入Rowkey中。
kafka的offset则是为了确保获取最新的数据。
