关系型数据库到HBase的数据储存方式变迁

 

我是标题党，其实本文与hbase关系不大，只是把它作为列族数据库的代表来讲。从目前字眼上看，HBase比Bigtable无疑更具吸引力。题目改成：RDBMS到列族的数据储存方式变迁 更恰当。

如今Bigtable型(列族)数据库应用越来越广，功能也很强大。但是很多人还是把它当做关系型数据库在使用，用原来关系型数据库的思维建表、存储、查询。本文以hbase举例讲述数据模式的变化。

传统关系型数据库(mysql，oracle)数据存储方式主要如下：

图一

上图是个很典型的数据储存方式，我把每条记录分成3部分:主键、记录属性、索引字段。我们会对索引字段建立索引，达到二级索引的效果。

但是随着业务的发展，查询条件越来越复杂，需要更多的索引字段，且很多值都不存在，如下图：图二

上图是6个索引字段，实际情况可能是上百个甚至更多，并且还需要根据多个索引字段刷选。查询性能越来越低，甚至无法满足查询要求。关系型数据里的局限也开始显现，于是很多人开始接触NoSQL。

列族数据库很强大，很多人就想把数据从mysql迁到hbase，存储的方式还是跟图一或者图二一样，主键为rowkey。其他各个字段的数据，存储一个列族下的不同列。但是想对索引字段查询就没有办法，目前还没有比较好的基于bigtable的二级索引方案，所以无法对索引字段做查询。

这时候其实可以转换下思维，可以把数据倒过来，如下图：

图三

把各个索引字段的值作为rowkey，然后把记录的主键和属性值按照一定顺序存在对应rowkey的value里。上图只有一个列族，是最简单的方式。 Value里的记录可以设置成定长的byte[]，多个记录集合通过移位快速查询到。

但是上面只适合单个索引字段的查询。如果要同时对多个索引字段查询，图三的方式需要求取出所有value值，比如查询“浙江”and“手机”，需要取出两个value，再解析出各自的主键求交。如果每条记录的属性有上百个，对性能影响很大。

接下来的变化是解决多索引字段查询的问题。我们将主键字段和属性字段分开存储，储存在不同的列族下，多索引查询只需要取出列族1下的数据求交，再去最小集合的列族2里取得想要的值。储存如图四：

图四

以上图数据举例：查询“浙江”AND“手机”：

1、取出“浙江”、“手机”列族1下的数据，即{1,2,5}、{2,6}

2、对数据求交后得到{2}满足条件，{2}在”手机”(最小集合)下的index为{1}

3、取出“手机”列族二的数据，根据步骤2的index，取出结果{108,2,22234,12}

为什么是不同列族，而不是一个列族下的两个列？

列族数据库数据文件是按照列族分的。在取数据时，都会把一个列族的所有列数据都取出来，事实上我们并不需要把记录明细取出来，所以把这部分数据放到了另一个列族下。

接下来是对列族2扩展，列族2储存更多的列，用来做各种刷选、计算处理。如下图：图五

后来我感觉这玩样越来越像搜索了。。。

这是一个很典型的通过空间换时间的方案，通过大量数据冗余来提高查询性能。同时也带来了问题，就是数据一致性的问题。所以这种方案的应用场景是对海量历史数据做实时计算上。关于应用场景可以看我之前写的一篇文章：实时计算应用场景

而处理实时更新的数据或者经常修改的数据还是难点问题，也欢迎讨论或者加入我们团队一起解决这些难题

http://www.yiihsia.com/2011/08/%E5%85%B3%E7%B3%BB%E5%9E%8B%E6%95%B0%E6%8D%AE%E5%BA%93%E5%88%B0hbase%E7%9A%84%E6%95%B0%E6%8D%AE%E5%82%A8%E5%AD%98%E6%96%B9%E5%BC%8F%E5%8F%98%E8%BF%81/