`
844604778
  • 浏览: 551230 次
文章分类
社区版块
存档分类
最新评论

HBase模式设计之ID顺序增长(rowkey顺序增长)

 
阅读更多

在设计RowKey的时候,常常有应用的RowKey必须包含ID部分,这样才可以支持查询访问。但ID自增长,会导致写入数据的时候压力集中在某一个或少数几个Region上,这是HBase设计的大忌。

经过多个应用的实践,我创造了ID的二进制反转的方式来避免。

简单说明: 比如ID是Byte型(一般为int或者long,此处为方便解释),RowKey=ID+timestamp,1,2,3,4……这样增长,对应二进制为0000 0001,0000 0010,0000 0011,0000 0100……,因为前面的bit是不会变化的,所以以ID为RowKey(或者ID打头)的数据写入的时候会集中在一个region上,然后又集中在下一个region上。为此将变化的部分放到RowKey的前面,来分散写入的压力。前面的增长在RowKey的ID上就变成1000 0000, 0100 0000, 1100 0000,0010 0000……我们预分区,假如需要16-1个分区,就可以分为[,0x01),[0x01,0x02),[0x02,0x03)……[0xFE,0xFF), [0xFF,),注意算一下,这样,1,2,3,4……就会写到不同的区间上,从而分散到不同的region了。(提醒:为什么只拿ID说事,不考虑timestamp呢,因为HBase的RowKey时字节码比较的,先从高位开始,高位分出胜负,后面就不care了~)

优点:转顺序为分散,均衡集群压力;可以做到预分区;不用hash,不用考虑ID的hash碰撞,从而节约存储空间;

限制:scan只能在同一ID打头的rowkey内进行,连续ID的scan不能直接支持,需要程序逻辑处理。


相信了解HBase的能很快理解,不做赘述。以后不断分享HBase设计和系统运营、代码分析、缺陷修复等。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics