一）、什么情况下使用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进行分词，
好处：便于分布式，便于多条件伸缩查询。
此随笔非原创