手机网站用什么空间,网站 验证,做网站为什么要备案照相,app和网站开发1.为什么 Rowkey 这么重要 1.1 RowKey 到底是什么 我们常说看一张 HBase 表设计的好不好#xff0c;就看它的 RowKey 设计的好不好。可见 RowKey 在 HBase 中的地位。那么 RowKey 到底是什么?RowKey 的特点 如下: 类似于 MySQL、Oracle 中的主键#xff0c;用于标示唯一的行… 1.为什么 Rowkey 这么重要 1.1 RowKey 到底是什么 我们常说看一张 HBase 表设计的好不好就看它的 RowKey 设计的好不好。可见 RowKey 在 HBase 中的地位。那么 RowKey 到底是什么?RowKey 的特点 如下: 类似于 MySQL、Oracle 中的主键用于标示唯一的行;完全是由用户指定的一串不重复的字符串;HBase 中的数据永远是根据 Rowkey 的字典排序来排序的。1.2 RowKey 的作用 读写数据时通过 RowKey 找到对应的 Region;MemStore 中的数据按 RowKey 字典顺序排序;HFile 中的数据按 RowKey 字典顺序排序。1.3 Rowkey 对查询的影响 如果我们的 RowKey 设计为 uidphonename那么这种设计可以很好的支持以下的场景:uid 111 AND phone 123 AND name iteblog uid 111 AND phone 123uid 111 AND phone 12?uid 111难以支持的场景:phone 123 AND name iteblog phone 123name iteblog 1.4 Rowkey 对 Region 划分影响 HBase表的数据是按照 Rowkey 来分散到不同 Region不合理的 Rowkey 设计会导致热点问题。热点问题是大量的 Client 直接访问集群的一个或极少数个节点而集群中的其他节点却处于相对空闲状态。 如上图Region1 上的数据是 Region 2 的 5 倍这样会导致 Region1 的访问 频率比较高进而影响这个 Region 所在机器的其他 Region。 2.RowKey 设计技巧 我们如何避免上面说到的热点问题呢?这就是这章节谈到的三种方法。 2.1 避免热点的方法 – Salting 这里的加盐不是密码学中的加盐而是在 rowkey 的前面增加随机数。具体就是给 rowkey 分配一个随机前缀以使得它和之前排序不同。分配的前缀种类数量应该和你想使数据分散到不同的 region 的数量一致。 如果你有一些 热点 rowkey 反复出现在其他分布均匀的 rwokey 中加盐是很有用的。考虑下面的例子:它将写请求分散到多个RegionServers但是对读造成了一些负面影响。假如你有下列 rowkey你表中每一个 region 对应字母表中每一个字母。以 a 开头是同一个 region, b开头的是同一个 region。在表中所有以 f开头的都在 同一个 region 它们的 rowkey 像下面这样: 现在假如你需要将上面这个 region 分散到 4 个 region。你可以用 4 个不同 的盐:a, b, c, d.在这个方案下每一个字母前缀都会在不同的 region 中。 加盐之后你有了下面的 rowkey: 所以你可以向 4 个不同的 region 写理论上说如果所有人都向同一个 region 写的话你将拥有之前 4 倍的吞吐量。现在如果再增加一行它将随机分配 a,b,c,d 中的一个作为前缀并以一个现有行作为尾部结束: 因为分配是随机的所以如果你想要以字典序取回数据你需要做更多工作。加盐这种方式增加了写时的吞吐量但是当读时有了额外代价。 2.2 避免热点的方法 - Hashing Hashing 的原理是计算 RowKey 的 hash 值然后取 hash 的部分字符串和原来的 RowKey 进行拼接。这里说的 hash 包含 MD5、sha1、sha256 或 sha512 等算法。比如我们有如下的 RowKey: 我们使用 md5 计算这些 RowKey 的 hash 值然后取前 6 位和原来的 RowKey 拼接得到新的 RowKey: 优缺点:可以一定程度打散整个数据集但是不利于 Scan;比如我们使用 md5 算法来计算 Rowkey 的 md5 值然后截取前几位的字符串。subString(MD5(设备ID),0,x) 设备ID其中x一般取5或6。 2.3 避免热点的方法 - Reversing Reversing 的原理是反转一段固定长度或者全部的键。比如我们有以下 URL 并作为 RowKey: 这些 URL 其实属于同一个域名但是由于前面不一样导致数据不在一起存放。 我们可以对其进行反转如下: 经过这个之后这些 URL 的数据就可以放一起了。 2.4 RowKey 的长度 RowKey 可以是任意的字符串最大长度 64KB(因为 Rowlength 占 2 字节)。 建议越短越好原因如下: 数据的持久化文件 HFile 中是按照 KeyValue 存储的如果 rowkey 过长比 如超过 100 字节1000w 行数据光 rowkey 就要占用 100*1000w10 亿个字 节将近 1G 数据这样会极大影响 HFile 的存储效率;MemStore 将缓存部分数据到内存如果 rowkey 字段过长内存的有效利用率就会降低系统不能缓存更多的数据这样会降低检索效率;目前操作系统都是 64 位系统内存 8 字节对齐控制在 16 个字节8 字节的整数倍利用了操作系统的最佳特性。3.RowKey 设计案例剖析 3.1 交易类表 Rowkey 设计 查询某个卖家某段时间内的交易记录 sellerId timestamp orderId 查询某个买家某段时间内的交易记录buyerId timestamp orderId 根据订单号查询 orderNo如果某个商家卖了很多商品可以如下设计 Rowkey 实现快速搜索saltsellerId timestamp 其中salt 是随机数。可以支持的场景: 全表 Scan按照 sellerId 查询按照 sellerId timestamp 查询3.2 金融风控 Rowkey 设计 查询某个用户的用户画像数据 prefix uidprefix idcardprefix tele其中 prefix substr(md5(uid),0 ,x) x 取 5-6。uid、idcard 以及 tele 分别表示 用户唯一标识符、身份证、手机号码。3.3 车联网 Rowkey 设计 查询某辆车在某个时间范围的交易记录carId timestamp某批次的车太多造成热点prefix carId timestamp 其中 prefix substr(md5(uid),0 ,x) 3.4 查询最近的数据查询用户最新的操作记录或者查询用户某段时间的操作记录RowKey 设计如下: uid Long.Max_Value - timestamp支持的场景 查询用户最新的操作记录Scan [uid] startRow uid stopRow uid 查询用户某段时间的操作记录Scan [uid] startRow uid stopRow uid 如果 RowKey 无法满足我们的需求可以尝试二级索引。Phoenix、Solr 以及 ElasticSearch 都可以用于构建二级索引。
