hbase表格設計

(問題) 
對於hbase的架構而言, 怎樣的表格是好的表格呢?

(方法)
在hbase中,表格由row-key和column-family組成,
對於一個好的row-key設計, 最重要的就是:
對於表格的存取, 必須是平均分配, 而不集中於部分區塊.

考慮到hbase對於row-key的排序方式是字典排序法(Lexicographical Order),
在hbase指南中, 提出了兩種建議的設計方法:
Salting以及Hashing.

SALT(Second Level Address Translation), 或是第二層位址轉譯,
是指在原本的row-key前面加上位址轉譯(Slat)做為新的row-key,
舉例來說,我們現在有四個row-key:

foo0001, foo0002, foo0003, foo0004

我們設計4個slats(a, b, c, d), 用來分配個這些row-key:
不同的slat將對應到不同的Region,

a-foo0003, b-foo0001, c-foo0004, d-foo0002

當一個新的row-key加入時,將隨機產生對應的slat:

a-foo0003, b-foo0001, c-foo0003, c-foo0004, d-foo0002

在上面的例子中, c-foo0003和a-foo0003資料重複了,
所以使用slating當讀取資料時, 需要額外的判斷.

使用hash則是把原本slat的前綴(prefix)文字改成以hash產生,
這樣一來, 相同的row-key,將產生相同的hash值, 因此, 不會發生資料重複的狀況.

對於以hash作為row-key前綴的表格設計,
hbase也設計了兩個pre-splitting的方法, 分別是: HexStringSplit 以及 UniformSplit.

除了row-key的設計外, 在hbase中, 也希望column-family的數量不要太多,
同時, 在cell的架構下, 一筆hbase的資料是由row-key, column-family以及timestamp所決定,
因此, row-key和column-family的長度越短越好,
可以同時節省資料儲存的空間以及資料查詢的時間.

參考資料:
http://hbase.apache.org/book.html#rowkey.design
http://stackoverflow.com/questions/17792328/hbase-row-key-design-for-monotonically-increasing-keys
http://ikaisays.com/2011/01/25/app-engine-datastore-tip-monotonically-increasing-values-are-bad/
http://www.cnblogs.com/niurougan/articles/3975463.html