HBase多表关联查找资料
4星 · 超过85%的资源 需积分: 50 158 浏览量
2015-06-11
14:33:56
上传
评论 1
收藏 70KB DOCX 举报 
hbase 表结构设计研究
因为一直在做 hbase 的应用层面的开发，所以体会的比较深的一点是 hbase 的表结构
设计会对系统的性能以及开销上造成很大的区别，本篇文章先按照 hbase 表中的
rowkey、columnfamily、column、timestamp 几个方面进行一些分析。最后结合分析如何
设计一种适合应用的高效表结构。
1、表的属性
(1)最大版本数：通常是 3，如果对于更新比较频繁的应用完全可以设置为 1，能够快速
的淘汰无用数据，对于节省存储空间和提高查询速度有效果。不过这类需求在海量数据领
域比较小众。
(2)压缩算法：可以尝试一下最新出炉的 snappy 算法，相对 lzo 来说，压缩率接近，压
缩效率稍高，解压效率高很多。
(3)inmemory：表在内存中存放，一直会被忽略的属性。如果完全将数据存放在内存中，
那么 hbase 和现在流行的内存数据库 memorycached 和 redis 性能差距有多少，尚待实测。
(4)bloomfilter：根据应用来定，看需要精确到 rowkey 还是 column。不过这里需要理解
一下原理，bloomfilter 的作用是对一个 region 下查找记录所在的 hfile 有用。即如果一个
region 下的 hfile 数量很多，bloomfilter 的作用越明显。适合那种 compaction 赶不上 flush
速度的应用。
2、rowkey
rowkey 是 hbase 的 key-value 存储中的 key，通常使用用户要查询的字段作为
rowkey，查询结果作为 value。可以通过设计满足几种不同的查询需求。
(1)数字 rowkey 的从大到小排序：原生 hbase 只支持从小到大的排序，这样就对于排
行榜一类的查询需求很尴尬。那么采用 rowkey = Integer.MAX_VALUE-rowkey 的方式将
rowkey 进行转换，最大的变最小，最小的变最大。在应用层再转回来即可完成排序需求。
(2)rowkey 的散列原则：如果 rowkey 是类似时间戳的方式递增的生成，建议不要使用
正序直接写入 rowkey，而是采用 reverse 的方式反转 rowkey，使得 rowkey 大致均衡分布，
这样设计有个好处是能将 regionserver 的负载均衡，否则容易产生所有新数据都在一个
regionserver 上堆积的现象，这一点还可以结合 table 的预切分一起设计。
3、columnfamily
columnfamily 尽量少，原因是过多的 columnfamily 之间会互相影响。
4、column
剩余10页未读，继续阅读
资源评论
szfbair1132016-06-14还是可以下载，谢谢- shiwoshiwo_12019-06-11写的不错，可以参考
- qq_168941032016-07-21作为了解参考一下，有资源参考比没有强
