hbase所谓的三维有序存储是指由(行主键)、key(+)、(时间戳)三部分组成的三维有序存储。
它是行的主键，hbase只能使用一个或一个范围，即扫描，来查找数据。 所以设计很关键，关系到你应用层的查询效率。
它按字典顺序排序并存储字节码。
1、唯一原则
它的独特性必须通过设计来保证。 由于HBase中的数据存储是Key-Value的形式，如果将同一张表插入到HBase中的同一张表中，原来的数据会被覆盖（如果表设置为1），所以必须保证唯一性。
2. 排序原则
HBase是按照ASCII有序设计的。 我们在设计的时候一定要充分利用这一点。 例如，视频网站上的电影《泰坦尼克号》的弹幕信息按照时间倒序显示在视频中。 这时候我们的设计就必须和时间顺序相关。 可以使用“Long.-弹幕发布时间”的long值作为前缀。
3. 哈希原理
我们的设计应该是均匀分布在每个HBase节点上。以公共时间戳为例。 如果按照系统时间戳递增，如果第一部分是时间戳信息，就会造成所有新数据都累加在一个上的热点现象，也就是通常所说的热点问题。 出现热点。 当大量直接访问集中在单台机器上时（访问可能是读、写或者其他操作），单机负载过高，导致性能下降甚至不可用。 常见情况为jvm full gc或出现too busy异常。
情况，当然这也会影响到同一个人的其他人。
热点问题
1.逆转
倒排固定长度后存储，使经常变化的部分可以放在前面，可以有效地随机化。
逆转的例子通常以手机为例。 可以使用手机号码反转的字符串作为字符串。 这样可以避免像手机号码这样相对固定的号码（137x、15x等）开头引起的热点。 这样做的缺点是牺牲了秩序性。
2. 盐
Salt为每一个都添加一个前缀，前缀使用一些随机字符将数据分散在多个不同的位置，以达到负载均衡的目的。
例如，在具有 4 的 HBase 表中（注意：从 [,a), [a,b), [b,c), [c, )] 开始，在 Salt 之前添加以下内容：,,
我们分别添加a、b、c前缀。 加盐后分别是：a-、b-、c-
可以看到，加盐前的默认值会分布在第二个，加盐后的数据会分布在第三个。 理论上，处理后的吞吐量应该是前处理的3倍。 由于前缀是随机的，读取这些数据需要花费更多的时间，因此Salt增加了写操作的吞吐量，但缺点是也增加了读操作的开销。
3. 哈希或 Mod
使用哈希而不是随机 Salt 前缀的优点是给定行具有相同的前缀，这可以分散负载并能够推断读取操作。 确定性哈希（如 md5 后跟前 4 位数字作为前缀）允许客户端完全重构数据，并可以使用 get 操作直接获取所需的行。
4.复制代码长度原则
长度设计原则：是二进制。 很多开发者建议长度应该设计在10到100字节之间。 建议越短越好。
原因有二：
首先，HBase的持久化文件HFile是按照格式存储的。 如果太长，比如500字节，光是1000万列数据就占用了500*1000万=50亿字节，也就是近1G的数据，这将是巨大的。 影响HFile的存储效率；
第二种是将部分数据缓存到内存中。 如果字段太长，内存的有效利用率就会降低，系统无法缓存更多的数据，从而降低检索效率；
需要指出的是，不仅长度越短越好，而且列族名、列名等尽量使用短名称，因为HBase是列式数据库，这些名称都会写入到HBase中持久化文件 HFile. 过长的列族和列名会使整体存储容量增加一倍。
