HBase RowKey设计原则

本文引自淘宝技术部文章：http://rdc.taobao.org/?p=457

1. 建议使用String如果不是特殊要求，RowKey最好都是String。
   • 方便线上使用Shell查数据、排查错误
   • 更容易让数据均匀分布
   • 不必考虑存储成本
2. RowKey的长度尽量短如果RowKey太长话，第一是，存储开销会增加，影响存储效率；第二是，内存中Rowkey字段过长，内存的利用率会降低，这会降低索引命中率。

   一般的做法是：

   • 时间使用Long来表示
   • 尽量使用编码压缩
3. RowKey尽量散列RowKey的设计，最重要的是要保证散列，这样就会保证所有的数据都不都是在一个region上，避免做读写的时候负载将会集中在个别region上面。

   假设我们需要存储一个用户的所有微博（暂时不需要考虑时间倒排），这时候的RowKey的设计是UserId_WeiboId ，但是这样设计的话，UserId 的分布就很可能不均匀，因为RowKey是字符串排序的。（默认字典顺序排序）

   有两种办法来解决这个问题

   • ReversesUserId字符串反转后存储
   • Hash或者ModUserIdMD5 后作取前6位为前缀加入到 UserId 前面
4. RowKey排序假设我们有个很多微博用户发微博，但是这个时候，我们要开辟一个“广场”，所有的微博都是按照时间倒排序展示在这个“广场”里。这个时候我们就得为原来的UserId_WeiboId建立一张索引表，并且这个表的Rowkey要和时间相关
   • Rowkey的设计可以使用当前时间 - 微博发表时间的 long 值作为 RowKey 的前缀
   • RowKey散列
   • 如果数据可以定期清理如果数据不是需要一直保存的话，就算所有数据落在一个region，因为按时间搜索会指定startRow，存储时候Rowkey也是连续的，所以速度也非常块，当然数据容量最好和DBA商量一下
   • 如果数据都需要保存把DayOfMonth作为前缀

     那么RowKey会是 DayOfMonth_(当前时间 - 微博发表时间)

     不过这样在代码实现上面的时候会有一些麻烦。

5. 关于事务目前HBase的Put，Delete操作都是事务的，但是如果您希望能够对好几个Table发起一连串操作并且希望是事务的话，目前还没有好的办法。所以HBase使用的时候，要有解决数据出错的觉悟。