大数据 | Hbase笔记二(基础设计与案例)

就像上篇Hbase文中所说,Hbase数据模型和关系型数据库有很大不同。因此Hbase数据库的设计与关系型数据库也有很大不同。

设计Hbase表其实就是解决如下问题的答案:

1.row key的结构应该是什么样子的,row key应该包含什么内容?

2.一个表应该有多少column family?

3.column family里面应该写入什么样的数据?

4.每个column family应该包含多少个column?

5.column的名字应该是什么样子的?尽管column的名字不需要在表定义的时候就指定,但是当你读写数据的时候需要知道它。

6.Cell里应该写入什么信息?

7.每个cell里应该存储几个版本的数据?

Hbase表定义中最重要的事情就是row-key结构。而如果想定义一个有效的row key结构,最重要的事情就是定义读写模式。为了定义schema,Hbase表的几个重要特点必须被考虑进去。这是一个大概的总结

1.只有Key有索引

2.Hbase表是以row key排序并存储的。每个分区负责一部分row key空间,分区由起始和结束的row key决定。

3.Hbase中所有的内容都是以byte[]存储的,所以这里面没有数据类型。

4.原子性只能在row界别保证。跨row不能保证原子性,也就是说不支持多row的事务。

5.column family必须在表创建的时候就定义好。

6.column是动态的,能够在写的时候再定义。column是以byte[]存储的,所以你甚至能向里面放数据。

为了理解上面说的概念,举个栗子。以微博关系举例(用户会关注其他用户),我们想讲用户关系存入Hbase表中。很明显,“关注者—被关注者”是一个图的关系,我们其实有更直接的图数据库(Neo4J等)来保存,那如何用Hbase保存呢?接下来我将演示这个思考过程。

首先,要保存数据到数据库,我们需要思考读写的需要解决的问题:

读数据需要解决的问题:

1.一个user关注了谁?

2.A用户是否关注了B?

3.谁关注了A用户?

写数据需要解决的问题:

1.用户A关注另一个用户B

2.A对一个用户B取消关注

我们多思考几种设计方案并比较它们的优缺点。

第一种设计案例,如图一所示:

《大数据 | Hbase笔记二(基础设计与案例)》

图一

如图一所示,Column Family是“follows”,column qualifier是粉丝的序号,cell value是粉丝的ID。

这个设计很好的解决了读数据库时候的问题1和问题2,但是如果粉丝队列很长的话,比较花费时间。写操作的话就比较麻烦了,因为没有计数来表示粉丝的位置,所以增加粉丝很难计算他的序号。

第二种设计案例:

《大数据 | Hbase笔记二(基础设计与案例)》

图二

如图二所示,被“关注者+粉丝”的名字为row key,column family被置为“f”,这是为了节省空间。而CQ为粉丝的用户名。这样就可以很容易的检索、增加数据了。

未经允许,请勿转载!

——完——

    原文作者:petemper
    原文地址: https://www.jianshu.com/p/d59336ce24b4
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞