大数据 | 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取消关注

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

第一种设计案例，如图一所示：

图一

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

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

第二种设计案例：

图二

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

未经允许，请勿转载！

——完——