一）、什么情況下使用Hbase
1）傳統數據庫無法承載高速插入、大量讀取。
2）Hbase適合海量，但同時也是簡單的操作。
3）成熟的數據分析主題，查詢模式確立不輕易改變。
二）、現實場景
1、電商瀏覽歷史
問題：
傳統數據庫
數據量很大，事情會變得復雜。
Order by 消耗很多性能。
大量發生又無法分布式處理，顧客需要事實看到自己足跡，傳統數據庫無法使用緩存。
Hbase
面向時間查詢。
基於行健查詢速度快，新產生數據存於內存中的memstore，完全沒有IO開銷。
分布式化解負荷。
思路:
RoeKey：userid
列族和列：book：bookid
/如果用userid作為RowKey進行存儲，會發生因Rowkey范圍制動進行分配存儲節點時會發生因范圍過小而之分配到一個或幾個節點上發揮不出分布式系統的性能，
****為了充分利用分布式可以進行reverse key，Hash技巧進行行健設計。
reverse key 將userid進行導置如 userid為 11，12，13，14，15，16，17，18，19，20，11，12。
進行reverse key后會變成 21，11，02，91，81，71，61，51，41，31，21，11.這樣會隨機畫的分配到多個節點上。
Hash
將userid進行hash生成hash值進行userid映射。
2、瀏覽XXXX貼子的人還瀏覽了XXX貼
Hbase實現
兩張表，u-t，t-u
U-t結構：RowKey為userid，列族和列thread：threadid
T-u結構：RowKey為userid，列族和列user：userid
查詢：t-u threadid->userid 再從u-t userid->threadid, 獲得笛卡爾積（會存在大量無用數據）在程序中去重和統計。
2、多條件查詢
例子：Student（sno,cardid,sname,sex,age）有時以sno進行查詢，有事以cardid進行查詢。
問題：傳統型數據庫中，一張中可以有多個字段為查詢條件，但Hbase中只可以對Rowkey進行條件查詢，
解決方案：主表 RowKey：sno。列族為學生 列為 cardid，name,sex,age.
輔助表：RowKey：cardid 列族和列為 sno。
復合行鍵設計
例子;
Userid (用戶id)、 Messageid（郵件id）、<email-message>(郵件內容)
有時需要查詢某人的所有郵件（Rowkey為userid即可），有事又需要查詢某人具體的郵件（userid和 Messageid為查詢條件，如果郵件又1000+利用輔助表進行查詢不是十分適合）利用復合行鍵 RowKey：userid-Messageid 對userid查詢時，對RowKey進行分詞，
好處：便於分布式，便於多條件伸縮查詢。