不同於傳統關係數據庫圍繞數據先建模再考慮查詢，HBase(Cassandra等NOSQL)強調圍繞查詢進行建模，幹什麼活做什麼設計，海量數據就沒必要多餘的設計了。
具體總結包含如下三大原則：
反範式很重要
傳統關係數據庫中，期間遵循數據設計的三大範式，減小數據冗餘，彼此間通過關係引用，hbase中要反範式，冗餘沒有關係，放棄最小化設計，怎麼方便怎麼來，最簡單直觀就行。
如下,原先通過引用關係設計的地址信息，在hbase中直接把對應地址存儲在以Name爲Rowkey的列信息中。查詢所有地址信息，可以直接指定rowkey查詢，查詢某個地址是否存在直接指定Name和對應的地址列即可，總之直接按照多維數據表操作即可。
不用區分行和列
關係數據庫中，索引用來快速查找數據，對應值保存在記錄中。在hbase中索引(行鍵)和列都可以存儲數據，更加類似關係數據庫中的組合索引。如下，分別爲被關注-關注者對應的寬表和高表
顧名思義，寬表儘量把數據存儲在一行中，看起來寬度比較高，它很簡單，要查誰關注了張三，直接指定行鍵爲張三同時取多鍵值對即可。但是注意，hbase中數據存儲最小單元爲行，之前我們講過每個列族的數據存在一個HFile中，這裏如果張三的關注者遠比別人多，救護造成一個HFile急劇增大，多個Region數據量不一致，導致數據傾斜，可能一臺機器存儲會爆炸，且查詢寫入速度頁急劇下降。
再看高表，是儘量把數據存儲在多行中，有點類似關係數據庫，但是由於hbase的查詢主要依賴索引的定位，所以高表的數據只要是存儲在行鍵中的，考驗的是行鍵組合索引的設計，圖中需要查看誰關注了張三那就需要指定開始行鍵爲md5(張三)結束，指定結束行鍵爲md5(李四)，按照前綴查找的方式獲得對應的關注者列表。可以看到高表完全依賴行鍵定位效率更高，分佈也均勻，但是需要合理設計組合索引，相對來說使用麻煩點。
牢記有序和行鍵設計
可以說，hbase中行鍵設計核心，查的快不快和怎麼查完全依賴rowkey的設計，具體來說包括如下兩方面:
key均勻化
hbase按照字典序將列族數據均勻化分佈到不同的region中，必須保證key均勻才能做到數據不傾斜，存儲和查詢寫入效率最高。
關於key均勻化以監控數據來統計，如果按照天作爲rowkey來統計，默認按照字典序從前往後來看，數據是集中的
20180301
20180302
20180303
20180304
考慮如下均勻化方案
- 加鹽(Salting)
比如按照奇偶添加不同前綴，這樣的好處是數據有序散開，而且範圍查找還可以並行讀寫，缺點就是需要人工去控制對應的範圍併發查找邏輯
020180301
020180303
120180302
120180304
- 隨機鍵
比如直接對數據取md5，數據會無序散開，直接定位效率高，但是範圍查找性能低
hash1
hash2
hash3
hash4
- 提升字段
考慮叫rowkey變化大的部分提前，比如倒序或求差，這樣的好處在於完整的保留有序特性
10308102
20308102
30308102
40308102
總的來說，集中方案各有利弊，有人總結了如下關係圖，順序讀就是範圍查找，寫就是隨機讀寫特性。
組合key(索引)設計
另外,就是之前高表中說的組合key設計，它強調儘量將查詢的維度或信息存儲在行鍵，篩選數據的效率最高。這需要按照查找業務邏輯設計索引，牢記hbase的有序特性。
如下，現有用戶的電子郵件信息表，配合掃描取數據，可指定起始鍵設爲12345（假設ID），終止鍵設爲123456來取數據，不同的業務需求可逐次設計組合key如下，注意不同的行的rowkey對應部分長度必須相同，這樣才能保證rowkey始終按照理想的字典序排列。
原創，轉載請註明來自