最近，由于项目的需要开始接触Hbase，发现如果想要很好的利用Hbase存储和维护利用自己的海量数据，表的设计至关重要，一个好的表结构可以从本质上提高操作速度，直接决定了用户的get、put、delete等各种操作的效率。下面我就先介绍一下Hbase的基本表的构成。
       Hbase的表是Key-Value的形式，这种结构很好的支持了查找等操作，表是由一个Row_key和一个个的列簇组成，列簇中又可以划分出很多列。其中Row_key就相当于每一行数据的主键，唯一指定一行的数据，主要形式如下图所示：




Column Family:Person

Photo

Row_key

name

sex

age

mail

xxxxxxxxxxxxxxx

二进制字符串

0001

LiMing

female

24

xxxx@xxx.com


       表的key-value的形式就像Json格式的数据一样，其中王表中存储的数据任何格式都是可以得，因为他都会以二进制byte[ ]数组的形式来存储。表虽然是这样一个结构，但是，不同的业务表的设计模式是千差万别，下面我会用一个我看到的论文中例子来说明表设计重要性。

       场景：我们拿Twitter关系来举例子，也就是用户和用户之间的关系，比如，谁关注了谁等等，我们的需求有三个：

                 1、查询某位用户的所有关注的人    2、查询被某位用户关注的所有的人   3、添加新关注的用户

       假设我们将表设计成如下的形式：（row_key为用户id，列簇为他所关注的用户id）

      


用户

Column Family:关注

a

1 : b

2 : c

3 : d

 

b

1 : c

 

 

 

c

1：b

2 : f

 

 

       如果我要做需求1，查询用户a所关注的所有人，这个表就可以很好的满足条件，我只需拿到row_key，即用户的id就可以查询到对应的行，就可以取出所有的数据即他所关注的用户，但是当我要往行中添加新关注用户的时候，这表就不能很好的满足需求了，应为我并不知道关注这个列簇中有多少个列，如果要添加就需要访问一遍这一行中所有的数据，所以在添加的时候不能确定用户前面的key值。所以我们可以在关注着个列簇中新加上一列来统计人数，表如下：


用户

Column Family:关注

a

1:b

2:c

3:d

Count:3

b

1:c

 

 

Count:1

c

1：b

2:f

 

Count:2



这样，假设用户e新关注了用户b，那么我在插入的时候，就只需先查看count值，然后将其加1后，作为新的用户的key插入，即在row_key为b的那一行插入2：e。但是很明显这样设计表，并不能满足需求2，即当我要查询被用户a关注的所有的用户，这样我就不得不需要就表中所有信息查询一遍，才能得到结果，这样，效率明显是很低的。所以我们对表进行如下改进：


Row_key (用户id+被关注的用户id)

Column（被关注用户的信息）

a+b

b的详细信息

a+c

c的详细信息

a+d

d的详细信息

b+c

c的详细信息


我们将row_key设置成用户id+被关注的用户id，这样我们在查找被用户a关注的用户的时候，只需要匹配row_key的前半部分，而查找关注用户a的所有用户的时候，我们就可以匹配row_key的后半部分即可完成我们的需求。


注：Hbase还在学习中，如有写的不对的地方，还请大神纠正，谢谢