关系型数据库与HBase的数据储存方式差异

       如今Bigtable型(列族)数据库应用愈来愈广，功能也很是强大。

但是很是多人仍是把它当作关系型数据库在使用，用原来关系型数据库的思惟建表、存储、查询。

本文以hbase举例讲述数据模式的变化。

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

图一

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

但是随着业务的发展。查询条件愈来愈复杂，需要不少其它的索引字段，且很是多值都不存在，例如如下图：

图二

       上图是6个索引字段。实际状况多是上百个甚至不少其它，并且还需要依据多个索引字段刷选。

查询性能愈来愈低，甚至没法知足查询要求。关系型数据里的局限也開始显现。因而很是多人開始接触NoSQL。

       列族数据库很是强大。很是多人就想把数据从mysql迁到hbase，存储的方式仍是跟图一或者图二同样，主键为rowkey。其它各个字段的数据。存储一个列族下的不一样列。

但是想对索引字段查询就没有办法，眼下尚未比較好的基于bigtable的二级索引方案，因此没法对索引字段作查询。

      这时候事实上可以转换下思惟。可以把数据倒过来，例如如下图：

图三

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

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

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

图四

为何是不一样列族，而不是一个列族下的两个列？

        列族数据库数据文件是依照列族分的。

在取数据时，都会把一个列族的所有列数据都取出来。其实咱们并不需要把记录明细取出来。因此把这部分数据放到了还有一个列族下。

       接下来是对列族2扩展。列族2储存不少其它的列，用来作各类刷选、计算处理。例如如下图：

图五

       后来我感受这玩样愈来愈像搜索了。。。