最近在 oschina 看到有朋友用 golang 寫了一套 based on HBase 的即時通訊軟體(原設計是 MySQL)，而 Qmi 也是基於 HBase 的即時通訊軟體。雖然小編不會寫 golang，但看 code 總還可以的，所以小編當然要來研究一下這個 tim 是如何設計 schema 的。
看起來 rowkey 就是用 HBase 的 increment 指令完成，然後再將 int 轉成 hex 後做為 rowkey。而 family 則有 n 個 (感覺就是欄位名的樣子)，然後 family 為 idx 開頭的就是 foreign key。
除了 rowkey 以外，family, qualifier, value 的設計邏輯，更讓小編有點不解 Orz
* 如果 family 是 # 開頭的話 (一般是 # id)，則 qualifier 為空，value 為 rowkey 的值
* 如果 family 是 idx_ 開頭，則 family 為 index，qualifier 為欄位的內容 (像是 IndexDomainUsername 的值)，value 為空
* 一般欄位則 family 為欄位名稱，qualifier 為空，value 為欄位的內容 (像是 fromuser 的值)
對 HBase 設計比較了解的朋友會知道，rowkey 會影響讀寫的效能，依照 ascii 碼排序，愈分散就愈不會遇到 hotspot，但愈集中一次能取回的資料就愈多，這都是要看 scenario 決定。而 family 與 HFile 成正比，family 愈多，開的檔案愈多，一般建議不超過三個，而這裡一筆 record 就開了十幾個。另外除了 value 以外，naming 要儘量簡短。
看完之後，覺得跟這幾年小編在 HBase 上設計 schema 的原則完全不同啊。不過相信有一部分或許是為了要相容於 RDBMS 的關係，而不得不做的取捨吧 Orz
* https://www.oschina.net/news/78341/tim-1-1-0
* https://github.com/donnie4w/tim/blob/master/tim.hbase/hbaseService.go
* https://github.com/donnie4w/tim/blob/master/tim.hbase/hbasedao.go
* https://github.com/donnie4w/tim/blob/master/doc/hbaseTable.txt
#qmi #tim #hbase #golang
foreign key效能 在 主表和關聯表要不要全刪和外來鍵一些整理 的推薦與評價
有看到幾篇，說外來鍵很吃DB 效能正常可以用程式邏輯去解決掉不過當然設定外來 ... MySQL 建立Foreign Key ( InnoDB ) 時要注意的一件事@ Amin's Note ... ... <看更多>