Rowkey设计原理

Rowkey本身相当于一级索引。
三大原则：
唯一性原则：Rowkey在设计时必须保证其唯一性，这是由于Hbase的核心存储结构是KeyValue形式，在同个版本表格的情况下，如果后添加的Rowkey与已有的相同，则会覆盖原先的数据（思：versions）。
补充：排序原则：在Hbase中，Rowkey是按照Ascll的顺序排序存储的，因此在Rowkey的设计时，要充分利用这个特点，将经常读取的数据存储到一块，将最近可能会被访问的数据存储到一起（思：最大值-时间戳）。

长度原则：Rowkey是一个二进制码流，可以是任意字符串，最大长度为64k，实际应用中一般为10-100byte，以byte[]形式保存，一般设计为定长，建议越短越好，不超过16个字节。这是由于Hbase的数据持久化文件HFiile是按照KeyValue形式存储，Rowkey设计过长的话，在大量数据存储的情况下，Rowkey会占用大量存储空间，极大影响HFile的存储效率；MemStore将缓存部分数据到内存中，Rowkey过长，内存的有效利用率就会降低，从而导致系统不能缓存再多的数据，降低检索的效率。

散列原则：即让Rowkey没有任何规律，从而实现设计的Rowkey均匀的分布在每个Hbase节点上。就以常见的时间戳为例，如果Rowkey按照时间戳的方式递增，那么不要将时间戳设计到第一部分，以避免所有的数据集中在一个RegionServer上，造成热点堆积导致的单个RegionServer负载过高的问题，从而提高查询效率。
解决：
加盐：如果Rowkey按照时间戳的方式递增，则可以在Rowkey前增加随机数，以避免热点堆积。
哈希散列：哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的Rowkey，可以使用get *** 作准确获取某一个行数据。
反转：反转固定长度或者数字格式的Rowkey。这样可以有效的随机Rowkey，但是会牺牲Rowkey的有序性。
时间戳反转：快速获取数据的最近版本，使用反转的时间戳作为Rowkey的一部分。

Rowkey设计直接关系到region划分（与划分策略有关），非常关键。不同的Rowkey决定了，row写入哪个分区当中。
需求调研的关键维度：
负载特点：读写的系统吞吐量，读写比重。重读轻写Rowkey更侧重高效读取，重写轻读更侧重整体的吞吐量。
查询场景：最高频的查询场景，最有价值的数据排序场景，各个字段的匹配类型（equal，prefix match，wildcard，text-search），组合字段场景。
数据特点：查询条件字段的数据分布特点，数据的生命周期。