HBase学习笔记——避免热点Region的一些技巧

  • 时间:
  • 浏览:1
  • 来源:5分排列3APP下载_5分排列3APP官方

salt的取值范围是[0, region server个数)。 或者 ,查询时,亲戚亲戚亲戚亲戚朋友的应用逻辑,时要对每一一三个小多多salt的取值,发起一次查询请求,以salt值作为scan的row key的前缀。或者 ,将哪此查询的结果合并返回。

亲戚亲戚亲戚亲戚朋友根据查询条件有哪此字段,构建出二级索引,二级索引的值就让数据表的row key。没人 对于一直执行的查询条件,会集中访问二级索引的一次责行,就造成了二级索引的热点区域。

为此,亲戚亲戚亲戚亲戚朋友也可否对row key的各个次责,分别求取MD5,再拼接起来,作为新的row key。以前实在仍不支持有序查询,或者 支持根据前缀匹配进行范围扫描——根据row key前缀的MD5,范围扫描匹配的行,返回的是无序的数据。

在row key首部增加原始row key的hash code,使数据均匀散列。

···

salt = timestamp.hashCode() % region server个数

···

其核心思想是,索引和数据保证在同一张表的同一一三个小多多region里。这是通过将region的start row key作为索引row key的首部前缀实现的。索引和数据,在同一行的不同column family中。当region分裂以平衡负载时,索引和数据一块儿分裂。二级索引的访问负载会和被索引的数据一样均衡。将会数据和它的二级索引一直在同一一三个小多多region里的。

将会,将原始row key的MD5作为实际的row key。

对整个row key散列牺牲了有序性和根据前缀匹配进行范围扫描的能力。

将会业务应用的以上有一种查询,其执行频率会有很大差别。将会这有一种行,在一张表里,其中有一种更频繁的查询,自然会愿因整张表中的一类row key成为热点数据。

HBase row key设计得不好、频度各异的查询类型,会愿因热门数据集中坐落在某几个Region上,造成Region热点,集群负载不均衡。

salt技术一一三个小多多多问提——当region server数量变化时,row key前缀中的salt没人 相应更新。

为此,亲戚亲戚亲戚亲戚朋友要影响二级索引的分片策略。我学习到了有一种方案:

能采取哪此避免方案,首没能明确访问模式,或者 针对性优化:

在以时间戳作为二级索引的例子中,计算:

将会不时要数据的有序性:

举个例子,以时间戳作为二级索引的key,支持时间范围查找,没人 写入最新的数据、查询最新的数据,很容易愿因最后一一三个小多多region成为热点。

一一三个小多多店铺有哪此商品(row key是store id + product id) 和 有一种商品有哪此店铺在出售(row key是product id + store id),这有一种行,不会说装进一张表里。

没人 来太久,要拆成两张表,让HBase有自由度独立管理两张表的region,独立进行region的拆分,保持负载均衡。

这些 方案能避免region分裂、region server个数地处变化的请况。

将以上salt作为时间戳二级索引的前缀。以前打乱了以前的二级索引分片策略,使得负载均衡。

3200公司(赵建博)提出的二级索引方案:http://blog.csdn.net/dhtx_wzgl/article/details/49069081