您好,登录后才能下订单哦!
可以理解为关系型数据库MySQL Oracle的主键,用于标识唯一的行。
完全是由用户指定的一串不重复的字符串。
HBase中的数据永远是根据Rowkey的字典排序来排序的。
读写数据时 通过 RowKey 找到 对应 的 Region,例如需要查找一条数据肯定需要知道他的RowKey ,写数据的时候也要根据RowKey 来写。
MemStore中的数据按Rowkey字典顺序排序,写数据的时候会先将数据放到MemStore也就是内存,内存中的数据是按照Rowkey字典顺序排序的。
HFile中的数据按RowKey字典顺序排序,内存中的数据最后也会持久化到磁盘中,磁盘的数据HFile也是按RowKey字典顺序排序。
例:RowKey由uid+phone+name组成
uid=111 AND phone = 123 AND name = abc
uid=111 AND phone = 123
uid=111 AND phone = 12?
uid=111
这种场景下我们都指定了uid部分,也就是RowKey的第一部分,第一种查询的RowKey是完整的格式,所以查询效率是最好的,后边的三个虽然没有指定完整RowKey,但是查询的支持度也还不错.
phone = 123 AND name = abc
phone = 123
name = abc
这种场景下并没有指定RowKey的第一部分uid,只通过phone跟name去做查询,也就是不指定先导部分,那么这种场景会导致HBase的查询的时候去进行全表扫描,降低了查询效率.
HBase表的数据是按照RowKey来分散到不同的Region,不合理的RowKey设计会导致热点问题,热点问题是大量的Client直接访问集群的一个或极少数个节点,而集群中的其他节点却处于相对空闲的状态,从而影响对HBase表的读写性能.
Salting的原理是将固定长度的随机数放在行键的起始处,具体就是给 rowkey 分配一个随机前缀 以使得它和之前排序不同。分配的前缀种类数量应该和你想使数据分散到不同的 region 的数量一致。 如果你有一些 热点 rowkey 反复出现在其他分布均匀的 rwokey 中,加盐是很有用的。
例:假如你有下列 rowkey,你表中每一个 region 对应字母表中每一个字母。 以 ‘a’ 开头是同一个region, 'b’开头的是同一个region。在表中,所有以 'f’开头的都在同一个 region, 它们的 rowkey 像下面这样:
foo0001 a-foo0001
foo0002 ===> b-foo0002
foo0003 c-foo0003
foo0004 d-foo0004
假如你需要将上面这个 region 分散到 4个 region。你可以用4个不同的盐:‘a’, ‘b’, ‘c’, ‘d’.在这个方案下,每一个字母前缀都会在不同的 region 中。加盐之后,就像上边的例子.
所以,你可以向4个不同的 region 写,理论上说,如果所有人都向同一个region 写的话,你将拥有之前4倍的吞吐量。
优缺点:由于前缀是随机生成的,因此想要按照字典顺序找到这些行,则需要做更多的工作,从这个角度上看,salting增加了写操作的吞吐量,却也增加了读操作的开销.
Hashing 的原理是计算 RowKey 的 hash 值,然后取 hash 的部分字符串和原来的 RowKey 进行拼接。这里说的 hash 包含 MD5、sha1、sha256或sha512等算法,并不是仅限于Java的Hash值计算。
例:比如我们有如下的 RowKey:
foo0001 95f18cfoo0001
foo0002 ===> 6ccc20foo0002
foo0003 b61d00foo0003
foo0004 1a7475foo0004
我们使用 md5 计算这些 RowKey 的 hash 值,然后取前 6 位和原来的 RowKey 拼接得到新的 RowKey,如上
优缺点:可以一定程度打散整个数据集,但是不利于 Scan;比如我们使用 md5 算法,来计算Rowkey的md5值,然后截取前几位的字符串。
常见用法:subString(MD5(设备ID), 0, x) + 设备ID,其中x一般取5或6。
Reversing 的原理是反转一段固定长度或者全部的键。
例:比如我们有以下 URL ,并作为 RowKey:
flink.iteblog.com moc.golbeti.knilf
www.iteblog.com ===> moc.golbeti.www
carbondata.iteblog.com moc.golbeti.atadnobrac
def.iteblog.com moc.golbeti.fed
这些 URL 其实属于同一个域名,但是由于前面不一样,导致数据不在一起存放。我们可以对其进行反转,如上,经过这个之后,前缀就相同了,这些 URL 的数据就可以放一起了。
优缺点:有效的打乱了行键,但是却牺牲了行排序的属性.
RowKey 可以是任意的字符串,最大长度64KB(因为 Rowlength 占2字节)。建议越短越好,原因如下:
查询某个卖家某段时间内的交易记录
sellerId + timestamp + orderId
查询某个买家某段时间内的交易记录
buyerId + timestamp +orderId
如果某个商家卖了很多商品,按第一种方式,就有可能会有大量RowKey前缀相同的数据在相同的Region上,造成热点问题,可以如下设计 Rowkey 实现快速搜索 salt + sellerId + timestamp 其中,salt 是随机数。
我们在原来的结构之前进行了一步加盐salt操作,例如加上一个随机数,这样就可以把这些数据分散到不同的Region上去了.
可以支持的场景:
查询某个用户的用户画像数据
prefix + uid
prefix + idcard
prefix + tele
其中前缀的生成 prefix = substr(md5(uid),0 ,x), x 取 5-6。uid、idcard以及 tele 分别表示用户唯一标识符、×××、手机号码。
查询某辆车在某个时间范围的数据,例如发动机数据
carId + timestamp
其中 prefix = substr(md5(uid),0 ,x)
查询用户最新的操作记录或者查询用户某段时间的操作记录,RowKey 设计如下:
uid + Long.Max_Value - timestamp
支持的场景
查询用户最新的操作记录
Scan [uid] startRow [uid][00000000000] stopRow [uid][uid][Long.Max_Value - timestamp]
这样就能查出比如说最近100条数据
例:有一张HBase表结构及数据如下
问:如何查找phone=13111111111的用户?
遇到这种需求的时候,HBase的设计肯定是满足不了的,这时候就要引入二级索引,将phone当做RowKey,uid/name当做列名构建二级索引.
如果不依赖第三方组建的话,可以自己编码实现二级索引,同时也可以通过Phoenix或者Solr创建二级索引.
SQL+OLTP ==> Phonenix
全文检索+二级索引 ==> Solr/ES
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。