单调递增键的 HBase 行键设计答案

【问题标题】：HBase row key design for monotonically increasing keys单调递增键的 HBase 行键设计
【发布时间】：2013-07-21 11:14:41
【问题描述】：

我有一个 HBase 表，我在其中编写行键，例如：

<prefix>~1
<prefix>~2
<prefix>~3
...
<prefix>~9
<prefix>~10

在 HBase shell 上的扫描给出了一个输出：

<prefix>~1
<prefix>~10
<prefix>~2
<prefix>~3
...
<prefix>~9

应该如何设计行键，以使带有键<prefix>~10 的行排在最后？我正在寻找一些推荐的方式或更流行的方式来设计 HBase 行键。

【问题讨论】：

标签： nosql row hbase

【解决方案1】：

应该如何设计行键，以使键为 ~10 的行排在最后？

您以这种方式看到扫描输出，因为 HBase 中的行键保持排序 lexicographically 而与插入顺序无关。这意味着它们是根据它们的字符串表示进行排序的。请记住，HBase 中的行键被视为具有字符串表示形式的字节数组。最低顺序的行键首先出现在表中。这就是为什么 10 出现在 2 之前，依此类推。请参阅此page 上的行部分了解更多信息。

当您用零填充整数时，它们的自然顺序在按字典顺序排序时保持不变，这就是为什么您看到扫描顺序与您插入数据的顺序相同的原因。为此，您可以按照@shutty 的建议设计您的行键。

我正在寻找一些推荐的方式或更流行的方式来设计 HBase 行键。

为了设计一个好的设计，需要遵循一些一般性的指导方针：

使行键尽可能小。
避免使用单调递增的行键，例如时间戳等。这是一个糟糕的 shecma 设计，会导致 RegionServer 热点。如果您无法以某种方式避免这种使用，例如散列或加盐以避免热点。
尽可能避免使用字符串作为行键。与整数或长表示形式相比，数字的字符串表示形式占用更多字节。 例如： long 是 8 个字节。您可以在这八个字节中存储最多 18,446,744,073,709,551,615 的无符号数。如果将此数字存储为字符串（假设每个字符一个字节），则需要将近 3 倍的字节。
使用某种机制，如散列，以便在您的区域未均匀加载的情况下获得行的均匀分布。您还可以创建预拆分表来实现此目的。

有关行键设计的更多信息，请参阅link。

HTH

【讨论】：

【解决方案2】：

HBase 按字典顺序存储 rowkey，因此您可以尝试将此模式与固定长度的 rowrey 一起使用：

<prefix>~0001
<prefix>~0002
<prefix>~0003
...
<prefix>~0009
<prefix>~0010

请记住，您还应该使用随机前缀来避免区域热点（当单个区域接受大部分写入，而其他区域处于空闲状态时）。

【讨论】：

【解决方案3】：

单调递增的键对于 hbase 来说不是一个好的模式。你可以在这里阅读更多： http://hbase.apache.org/book/rowkey.design.html

那里还有一个指向OpenTSDB 的链接可以解决这个问题。

【讨论】：

【解决方案4】：

如果可能的话，确实推荐使用固定长度的键。 Bytes.toBytes(Long value) 可用于从计数器获取字节数组。对于小于 Long.MAX_VALUE 的正多头，它将很好地排序。

【讨论】：