最近，由於專案的需要開始接觸hbase，發現如果想要很好的利用hbase儲存和維護利用自己的海量資料，表的設計至關重要，乙個好的表結構可以從本質上提高操作速度，直接決定了使用者的get、put、delete等各種操作的效率。下面我就先介紹一下hbase的基本表的構成。
hbase的表是key-value的形式，這種結構很好的支援了查詢等操作，表是由乙個row_key和乙個個的列簇組成，列簇中又可以劃分出很多列。其中row_key就相當於每一行資料的主鍵，唯一指定一行的資料，主要形式如下圖所示：
column family:person
photo
row_key
name
***age
***************
二進位制字串
0001
liming
female
24***x@***.com
表的key-value的形式就像json格式的資料一樣，其中王表中儲存的資料任何格式都是可以得，因為他都會以二進位制byte[ ]陣列的形式來儲存。表雖然是這樣乙個結構，但是，不同的業務表的設計模式是千差萬別，下面我會用乙個我看到的**中例子來說明表設計重要性。
場景：我們拿twitter關係來舉例子，也就是使用者和使用者之間的關係，比如，誰關注了誰等等，我們的需求有三個：
1、查詢某位使用者的所有關注的人 2、查詢被某位使用者關注的所有的人 3、新增新關注的使用者
假設我們將表設計成如下的形式：（row_key為使用者id，列簇為他所關注的使用者id）
使用者
column family:關注a
1 : b
2 : c
3 : d
b1 : c
c1：b
2 : f
如果我要做需求1，查詢使用者a所關注的所有人，這個表就可以很好的滿足條件，我只需拿到row_key，即使用者的id就可以查詢到對應的行，就可以取出所有的資料即他所關注的使用者，但是當我要往行中新增新關注使用者的時候，這錶就不能很好的滿足需求了，應為我並不知道關注這個列簇中有多少個列，如果要新增就需要訪問一遍這一行中所有的資料，所以在新增的時候不能確定使用者前面的key值。所以我們可以在關注著個列簇中新加上一列來統計人數，表如下：
使用者
column family:關注a
1:b2:c
3:dcount:3
b1:c
count:1
c1：b
2:fcount:2
這樣，假設使用者e新關注了使用者b，那麼我在插入的時候，就只需先檢視count值，然後將其加1後，作為新的使用者的key插入，即在row_key為b的那一行插入2：e。但是很明顯這樣設計表，並不能滿足需求2，即當我要查詢被使用者a關注的所有的使用者，這樣我就不得不需要就表中所有資訊查詢一遍，才能得到結果，這樣，效率明顯是很低的。所以我們對錶進行如下改進：
row_key (使用者id+被關注的使用者id)
column（被關注使用者的資訊）
a+bb的詳細資訊
a+cc的詳細資訊
a+dd的詳細資訊
b+cc的詳細資訊
我們將row_key設定成使用者id+被關注的使用者id，這樣我們在查詢被使用者a關注的使用者的時候，只需要匹配row_key的前半部分，而查詢關注使用者a的所有使用者的時候，我們就可以匹配row_key的後半部分即可完成我們的需求。
注：hbase還在學習中，如有寫的不對的地方，還請大神糾正，謝謝
Database之HBase表設計
1.表的設計 1.1 pre creating regions 預設情況下，在建立hbase表的時候會自動建立乙個region分割槽，當匯入資料的時候，所有的hbase客戶端都向這乙個region 寫資料，直到這 個region足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先建立一些空的...
HBase表的設計（一）之表模式的設計
模式影響到表結構和如何讀寫表，所以說把這些放到寬泛的模式設計中變得尤為重要。hbase底層物理儲存是基於hdfs，在hdfs上是以hfile的形式進行儲存的 乙個特定的列族的所有資料在hdfs上會有乙個物理儲存，這個物理儲存區可能會有多個hfile組成，理論上可以通過合併來得到乙個hfile，乙個列...
Hbase學習之四 Hbase表設計案例
環境 虛擬機器 vmware 10 linux版本 centos 6.5 x86 64 客戶端 xshell4 ftp xftp4 jdk8 hadoop 2.6.5 hbase 0.98.12.1 hadoop2 hbase中表的設計 主要是將原來的關係解開 問題 例子 表設計一 表設計二 這是乙...