性能优化-hbase建表及优化说明

rowkeys设计：

rowkey按照字典顺序排序，数据按照二进制字节从左至右逐一对比排序。在物理上一个列族的成员在文件系统上都是存储在一起的。存储优化都是针对列族级别的。

rowkeys  只针对从小到大排序， 实现从大到小排序：rowkey=Integer.MAX_VALUE-Rowkey，到应用层再转换。

设计案例1：用户观看的所有观影记录

设计成userid_videoid ，但是分布就很难均匀。

改进： 反转userid存储，散列userid，userid取模后进行md5加密，取前6位作为前缀加入到userid前面。

rowkey设计可以使用当前时间long作为rowkey前缀，建议rowkey都是string，方便使用shell查数据、排查错误；更容易让数据均匀分布；不必考虑存储成本。

rowkey尽量短，（影响存储效率，过长导致内存利用率低，降低索引命中率），使用使用long，尽量使用编码压缩。hbase不能很好的处理2个或三个以上的列族。hbase的flush和compaction操作是针对一个region的，当一个列族操作大量数据的时候会引发一个flush。当很多列族在flush进行flush或compaction 时，会造成很多没用的io负载。

可配置数据块大小

blockSize:64kb,和hdfs的block不同。数据块索引存储每个数据块的起始键，数据块大小的设置影响数据块索引大小，数据块越小，索引越大，占用更大内存空间。同时加载进内存的数据块越小，随机查找性能好。数据块越大，索引越小，可以加载更多hfile，序列扫描性能越好。

官方推荐是8KB~1MB,如果主要用于顺序访问，应该用大一点的block，但是随即访问会变慢，因为有大量的数据需要进行解压。对于随即访问来说，block小一点会好些，但是需要更多内存来保存block index。由于压缩编码器的内部缓存机制的影响，最小block大小大概是20-30KB.

数据块缓存

数据放进读缓存，并不是一定能提升性能。

如果一个表或表的列族只被顺序华扫描访问或很少被访问，则get或scan操作花费时间长一点是可以接受的。如果只是执行很多顺序化扫描，会多次使用缓存，并且可能滥用缓存，从而把应该放进缓存获得性能提升的数据给排挤出去，如果关闭缓存，可以让出更多缓存给其他表和同一表的其他列族使用。

默认缓存blockcache是打开的

in_memory默认是false的，该值表示hbase除了再数据块缓存中保存这个列族相比其他列族更激进之外，并不提供其他额外保证。该参数在实际应用中设置为true，访问性能不会变化太大。

布隆过滤器-bloom filter

如果某行占用100字节存储空间，一个64kb 数据块包含 64*1024/10约 700行，只把起始行放在索引位上，此时查询数据可能在表中，可能放在另一个hfile中，甚至在memstore中。从硬盘读取数据会带来io开销，影响性能，当面对一个巨大的数据集且有很多并发读用户时，就会有问题。

布隆过滤器允许对存储在每个数据块的数据做一个反向测验，当要查询某行时，先检查布隆过滤器，确定改行是否在这个数据块，返回的结果只有不在或是不知道，因此称为反向测验。

布隆过滤器需要额外占用存储空间，占用的大小随着它们的索引对象数据增长而增长。行级布隆过滤器比列标识符级布隆过滤器占用空间要少。当空间不是问题时，它们可以压榨整个系统的性能潜力。

BOOMFILTER 参数 NONE,ROWCOL，ROW

数据压缩

hfile压缩并存放在hdfs上，减少了io开销，但是提高了CPU利用率。除非确定压缩不会提升性能，否则建议打开。

压缩只是表示数据在硬盘上是压缩的，在内存或是网络上不是压缩的。

不能经常改变数据压缩编码，但是如果的确需要改变时，也可以直接更改表定义，设定新压缩编码。后面region合并时，生成的新hfile会采用新编码，这个过程不要创建新表和复制数据。

单元时间版本

生存时间

生存时间：ttl设置单元格生存周期，ttl为18000s,就是将超过5小时的数据将会在下一次大合并时被删除。