就像上篇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为粉丝的用户名。这样就可以很容易的检索、增加数据了。
未经允许，请勿转载！
——完——
