关于HBASE的rowkey设计

之前用过hbase，当时因为没有设计好表，后来数据量上来了之后，花费了很大时间才把表重新分区了。
当时的rowkey设计是:uid+date+xxxxxx，好像是这么设计的来着，这样查询uid的时候是很快了。
但是这样会导致大量相同uid在同一个region里。并发支持不好。但是如果把rowkey做了md5的话，倒是能分到各个region了，那么那种uid scan查询就不快了。
问题: hbase的rowkey应该怎么设计，才能既能避免写热点，不让同类数据都集中在同一个region里面，又能提供良好的scan查询呢。大家都是怎么设计呢

nextuser · 发表于 2018-4-27 11:01:51

ld512870 发表于 2018-4-27 09:14
现在的生产环境没怎么用了。现在用mongodb比较多。就假设一种情况:uid和date 20170101这种。然后其他信息 ...

这个倒是想出一些办法
倒置时间_userid
或则为了更好解决热点
倒置时间_倒置userid
这个方案更合适你。
首先这里去掉了salt，效率肯定会提升，根据如下

如果RowKey过长，第一存储开销会增加，影响存储效率；第二内存中Rowkey字段过长，会导致内存的利用率过低，进而降低索引命中率。一般做法：时间使用Long表示；尽量使用编码压缩。

倒置时间_倒置userid，这样热点相信能够解决，而且查询不会慢。rowkey明显变短。
而且这个也符合你的查询。

查询某个uid的数据，或者某个uid的某天的数据，某个时间段内的数据

比如某个uid的数据，只要查询的时候，将这个uid倒置下，就可以查询到了
某个uid的某天的数据，只要查询的时候，将这个uid倒置+时间倒置，就可以查询到了
20180401
20180427
查询这个时间段，这个你可以创建二级索引，将倒置时间和正确时间做个映射。这样利用二级索引来查询。

ld512870 · 发表于 2018-4-26 18:32:59

hello?

desehawk · 发表于 2018-4-26 19:44:52

ld512870 发表于 2018-4-26 18:32
hello?

这个问题困扰很多人，设计的规则，容易热点，设计不规则，容易查询慢。

sstutu · 发表于 2018-4-26 20:23:55

这个需要具体的业务，具体情况具体分析，而且最好描述的在详细些。有图。这样才能找到具体的方案。如果不详细，这样肯定解决不了，只是泛泛而谈，没有深度。

ld512870 · 发表于 2018-4-27 09:14:07

sstutu 发表于 2018-4-26 20:23
这个需要具体的业务，具体情况具体分析，而且最好描述的在详细些。有图。这样才能找到具体的方案。如果不详 ...

现在的生产环境没怎么用了。现在用mongodb比较多。就假设一种情况:uid和date 20170101这种。然后其他信息。
如果现在的查询条件是查询某个uid的数据，或者某个uid的某天的数据，某个时间段内的数据。这种应该怎么设计呢。
我以前就是直接uid_20170101这样设计，然后可以用scan进行查询。但坏处就是一个用户的都放在一个region，如果某个user的
数据量过大，会导致写热点。这种应该怎么设计呢。

灰太狼_V0 · 发表于 2018-4-27 11:48:37

opentsdb、phoenix都有相似的rowkey salt处理，可以了解下。
简单的说，可以为rowkey加一个简单前缀，比如000~255内取随机值，这样数据可以按照前缀拆分region，数据均匀的分布于256个region中。
scan时，每个region scan一次，结果做归并即可，这样rs侧的scan的过程还可以并行处理。