求助！找了好几天了，关于 HBase 的 rowkey 设计，还是没有思路。

This topic created in 2737 days ago, the information mentioned may be changed or developed.

找到的所有文档，不管是 IBM 开发者社区的专业文档，还是复制粘贴党的，甚至英文文档，对 rowkey 一般都会提到一个设计思路和一个设计原则：

设计思路，尽量用 rowkey 查询，所以 rowkey 要尽量包含索引字段
设计原则，为了避免热点，rowkey 不要自增长，最好是散列化，有的文档直接推荐 Md5

问题：除了用 rowkey 查询唯一一条数据外，这两个之间不是自相矛盾吗？ 又或者，有什么散列方式是可以在散列化之后，还能在范围查询的时候使用到 rowkey 的。

假如我有三个索引字段：ID``DATE``TYPE，该怎么设计 rowkey，才能既满足散列话，又能够利用 rowkey 进行“ ID=5，DATE between 2018-12-01 and 2018-12-10 ”这样的范围检索。

rowkey

散列化

文档

DATE

3 replies • 2018-12-10 14:44:43 +08:00

pypy

Dec 10, 2018

1. 试试将 RowKey 用${ID}${type}${TimeStamp}的形式组织。这样，范围条件就是
startRow=${ID}${type}${TimeStamp:2018-12-01}
endRow=${ID}${type}${TimeStamp:2018-12-10}

2. RowKey 散列化的目的，是为了将数据尽可能分散到不同的 RegionServer。如果数据量不多或者节点数不多的话，不一定非要散列。如果你的 ID 本来就是自增，且访问频率平均的话，就不需要散列了。

具体业务需要更具体的细节才能分析，以上仅供参考。

syncnano

Dec 10, 2018

1、一定要散列，我们测试过，散列和非散列，同 region 数下性能相差非常大
2、rowKey 思路要结合实际业务和你预估的数据量（ region 数）来定的，关键词：md5Hash，key words，timestamp，reverse （这个很关键，可以在你的 key words 前面加几位尽可能散列的值，几位呢，就要根据你的 region 数来定了）

passerbytiny

Dec 10, 2018

我刚看了这篇文章 http://blog.chedushi.com/archives/9720 结合 1 楼示例，重新理一下理解：
1，散列化跟查询速度之间是不能二者兼顾的，需要寻找平衡点。
2，不需要将所有索引字段都放到 rowkey 中，rowkey 只放能够 1-3 个能大范围过滤数据的索引，然后结合使用 StartRow、EndRow，和 SingleColumnValueFilter。
3，使用 md5 码这种散列方式，就只能做精确查找和全表扫描了。