Hbase schema&table 设计实践

   1、rowkey设计不要连续，最好是hash后的结果,避免连续写单个region server压力过大。

   2、columnfamily尽量少，原因是过多的columnfamily之间会互相影响

  3、VERSIONS 最大版本数：通常是3，如果对于更新比较频繁的应用完全可以设置为1，能够快速的淘汰无用数据，对于节省存储空间和提高查询速度有效果。不过这类需求在海量数据领域比较小众。

    4、COMPRESSION压缩算法：可以尝试snappy算法，相对lzo来说，压缩率接近，压缩效率稍高，解压效率高很多。

    5、bloomfilter：根据应用来定，看需要精确到rowkey还是column,通常精确rowkey就可以。不过这里需要理解一下原理，bloomfilter的作用是对一个region下查找记录所在的hfile有用。即如果一个region下的hfile数量很多，bloomfilter的作用越明显。适合那种compaction赶不上flush速度的应用

   6、inmemory：表在内存中存放，一直会被忽略的属性(false)。如果完全将数据存放在内存中，那么hbase和现在流行的内存数据库memcached和redis性能差距有多少，尚待实测。

 下面以视频个性化推荐系统为例，介绍常见的两种常用的schema设计模式：

  第一种推荐模型存储方式【固定列】：

     对于column需要扩展的应用，column可以按普通的方式设计如下面第二种设计。但是对于列相对固定的应用，最好采用将一行记录封装到一个column中的方式，并采用Row /Family/Qualifier前缀树形式进行压缩，这样能够节省存储空间并且可以提高查询效率，其效率至少在二分查找以上。   设置表的列属性 DATA_BLOCK_ENCODING 值为PREFIX_TREE ,PREFIX_TREE在压缩空间的基础上又可以减少CPU。

     从作者【HBASE-4676】提供的DataBlock查找性能对比：

  

说明：

1.作者没有指出单条KV的平均大小

2.NONE 指的是不启用DataBlock Encode；PREFIX【HBASE-4218】指的是PREFIX Encode算法；TRIE才是前缀树block压缩算法。

3. 前缀树压缩算法在不同的block size下查找性能都很稳定，而NONE和PREFIX由于是用遍历的方式查找数据，所以查找性能随着blocksize直线下降。对于我们默认的64K的block大小，性能相差40+倍

4.NONE比PREFIX算法性能好，是由于PREFIX算法需要解压

        其中 三种为 PREFIX、DIFF或FAST_DIFF目的是以cpu换空间在不计较空间的情形下，即命中率都为100%，那么开启DIFF/FAST_DIFF,相比于NONE，对数据查询效率没有提升，甚至会带来压缩/解压缩对CPU资源占用的情况。

     Set ENCODE_ON_DISK to true on column descriptor to have the encoding in place out in the hfile

 设计的表结构如下所示：

       

第二种用户实时播放记录记录存放方式【不定列】：

          这种设计有利于scan(startkey,endkey)的扫描方法，而这种方法和get的效率相当，而且还很稳定。

 这种情况主要防止客户端查询OOM，某一个key下面包含的column过多。通常来说，hbase的column数目不要超过百万这个数量级。这种情况主要考虑column设计到rowkey的方法解决。下面是我们实践中的设计table结构。

       

 转载请附原文链接:http://blog.csdn.net/map_lixiupeng/article/details/40894023