hbase所谓的三维有序存储的三维是指：rowkey（行主键），column key(columnFamily+qualifier)，timestamp(工夫戳)三局部组成的三维有序存储。
rowkey是行的主键，而且hbase只能用个rowkey，或者一个rowkey范畴即scan来查找数据。所以 rowkey的设计是至关重要的，关系到你应用层的查问效率。
rowkey是以字典程序排序的，存储的是字节码。
Rowkey设计准则
1.Rowkey的惟一准则
必须在设计上保障其唯一性。因为在HBase中数据存储是Key-Value模式，若HBase中同一表插入雷同Rowkey，则原先的数据会被笼罩掉(如果表的version设置为1的话)，所以务必保障Rowkey的唯一性.
2.Rowkey的排序准则
HBase的Rowkey是依照ASCII有序设计的，咱们在设计Rowkey时要充分利用这点。比方视频网站上对影片《泰坦尼克号》的弹幕信息，这个弹幕是依照工夫倒排序展现视频里，这个时候咱们设计的Rowkey要和工夫程序相干。能够应用"Long.MAX_VALUE - 弹幕发表工夫"的 long 值作为 Rowkey 的前缀。
3.Rowkey的散列准则
咱们设计的Rowkey应平均的散布在各个HBase节点上。拿常见的工夫戳举例，如果Rowkey是按零碎工夫戳的形式递增，Rowkey的第一局部如果是工夫戳信息的话将造成所有新数据都在一个RegionServer上沉积的热点景象，也就是通常说的Region热点问题， 热点产生在大量的client间接拜访集中在个别RegionServer上（拜访可能是读，写或者其余操作），导致单个RegionServer机器本身负载过高，引起性能降落甚至Region不可用，常见的是产生jvm full gc或者显示region too busy异样情 况，当然这也会影响同一个RegionServer上的其余Region。
Region热点问题
1、Reverse反转 针对固定长度的Rowkey反转后存储，这样能够使Rowkey中常常扭转的局部放在最后面，能够无效的随机Rowkey。
反转Rowkey的例子通常以手机举例，能够将手机号反转后的字符串作为Rowkey，这样的就防止了以手机号那样比拟固定结尾(137x、15x等)导致热点问题，这样做的毛病是就义了Rowkey的有序性。
2、Salt加盐 Salt是将每一个Rowkey加一个前缀，前缀应用一些随机字符，使得数据扩散在多个不同的Region，达到Region负载平衡的指标。
比方在一个有4个Region(注：以 [ ,a)、[a,b)、[b,c)、[c, )为Region起至)的HBase表中，加Salt前的Rowkey：abc001、abc002、abc003 咱们别离加上a、b、c前缀，加Salt后Rowkey为：a-abc001、b-abc002、c-abc003
能够看到，加盐前的Rowkey默认会在第2个region中，加盐后的Rowkey数据会散布在3个region中，实践上解决后的吞吐量应是之前的3倍。因为前缀是随机的，读这些数据时须要消耗更多的工夫，所以Salt减少了写操作的吞吐量，不过毛病是同时减少了读操作的开销。
3、Hash散列或者Mod 用Hash散列来代替随机Salt前缀的益处是能让一个给定的行有雷同的前缀，这在扩散了Region负载的同时，使读操作也可能推断。确定性Hash(比方md5后取前4位做前缀)能让客户端重建残缺RowKey，能够应用get操作间接get想要的行。
4.Rowkey的长度准则
复制代码 Rowkey长度设计准则：Rowkey是一个二进制，Rowkey的长度被很多开发者倡议说设计在10~100个字节，倡议是越短越好。
起因有两点： 其一是HBase的长久化文件HFile是依照KeyValue存储的，如果Rowkey过长比方500个字节，1000万列数据光Rowkey就要占用500*1000万=50亿个字节，将近1G数据，这会极大影响HFile的存储效率；
其二是MemStore缓存局部数据到内存，如果Rowkey字段过长内存的无效利用率会升高，零碎无奈缓存更多的数据，这会升高检索效率；
须要指出的是不仅Rowkey的长度是越短越好，而且列族名、列名等尽量应用短名字，因为HBase属于列式数据库，这些名字都是会写入到HBase的长久化文件HFile中去，过长的Rowkey、列族、列名都会导致整体的存储量成倍增加。
关键词：大数据培训