HBASE顺序行键（YYYYMMDDHHMMSS），确定性非随机Salt

我的行键的初始开始部分看起来像YYYYMMDDhhmmss，其中“ss”总是00。 示例：20170603162100，对应2017年6月6日16:21 别问我为什么，但时间戳必须在钥匙的开头

这显然是每一分钟，每一分钟都是独一无二的数据

这受到区域热点的影响。 区域服务器上的行键如下所示：

我的阅读模式：获取一分钟的数据，而不是一小时、一天、一个月、一年的数据

假设我有10个区域服务器

这是我正在考虑的一个解决方案，它看起来像一种盐，但是确定性的，而不是随机的：

我看到mm部分-分钟，并根据它分配一个盐。 00分钟：为行键添加前缀A 01分钟：行键的前缀B .. 09分钟：将前缀J添加到行键 10分钟：为行键添加前缀A

这样，所有“A”密钥都应该分发到第一个区域服务器，以此类推。 优点可能是：所有单分钟请求都发送到同一个区域服务器，这对我来说是可以忍受的。就在下一分钟，所有请求都会发送到其他区域服务器

另外，在检索时，我不必进行并行读取，因为我实际上知道盐的种类

---

有人能解释一下我是否出了什么问题吗

好吧，你只有27分钟的英语字母表，我可能会建议用两个字母salt，它仍然应该正确分配。你有多少个节点

---

或者，您可以尝试从行键中删除秒数并将其反转。

我有10个区域服务器。这就是为什么建议使用A-J，然后重复A-J。我在什么地方错了吗？而且相反的想法太棒了！使用这种方法，您肯定会避免热点。然而，我可能错了，但我不确定区域服务器和rowkey的第一个字母之间是否存在1:1的映射。可能很少有字母在字典上不接近的情况会在一个区域服务器上结束。