Best Practices for Designing HBase RowKey to Avoid Hotspots

In HBase, locating a single cell requires four dimensions: RowKey, Column Family, Column Qualifier, and Timestamp, and the RowKey is the most error‑prone component, requiring careful design in three aspects.

1. Disperse the RowKey – HBase stores rows in lexicographic order of the RowKey, which benefits sequential scans but can create region hotspots if many reads/writes target a narrow key range. Techniques such as adding a salt prefix combined with hashing (using a hash of the original RowKey or part of it) spread keys across regions. Reversing fixed‑format numbers (e.g., phone numbers) or timestamps can also reduce hotspots, though reversing loses natural ordering; for timestamps, subtracting the value from a large constant (e.g., Long.MAX_VALUE - timestamp) places newer data first.

2. Control RowKey length – RowKey, column families, and column names are transmitted as byte arrays. Although the theoretical limit is 64 KB, practical implementations keep RowKeys under 100 bytes. Shorter keys reduce HFile storage overhead (e.g., a 100‑byte RowKey for ten million rows consumes ~1 GB) and improve cache density. Aligning keys to 8‑byte multiples (e.g., 16 B or 24 B) further enhances addressing efficiency.

3. Ensure RowKey uniqueness – This is self‑evident but essential.

Example

A calendar‑recording service stores data with three dimensions: user ID (uid), date (yyyyMMdd), and type (0‑99). The designed RowKey is 9~79809782~05~0008839540 (24 B) using ‘~’ as a delimiter because its ASCII code is the highest, simplifying lexical ordering. The components are:

uid.toString().hashCode() % 10

99999999 - date

StringUtils.leftPad(type, 2, "0")

StringUtils.leftPad(uid, 10, "0")

With this design, the table can be pre‑split during creation to distribute data evenly across regions. The DDL example is:

create 'user_calendar_record', {</code>
<code>  NAME => 'f',</code>
<code>  VERSIONS => '1',</code>
<code>  BLOCKCACHE => 'true',</code>
<code>  BLOCKSIZE => '65536',</code>
<code>  BLOOMFILTER => 'row',</code>
<code>  COMPRESSION => 'SNAPPY'</code>
<code>}, {</code>
<code>  SPLITS => ['1','2','3','4','5','6','7','8','9']</code>
<code>}

If the table is not pre‑split, it starts with a single region, and as data grows, frequent region splits degrade performance; this topic is left for a future article.

The article concludes with a friendly request for readers to like, collect, and share the post.