成熟的数据分析主题，查询模式已经确立并且不轻易改变
传统的关系型数据库已经无法承受负荷，高速插入，大量读取
适合海量的，但同时也是简单的操作（例如value-key）
场景一：浏览历史
关系数据库的困难：
简单的事情只要上了量就会变得无比复杂的事情
Orderby耗费很多性能
大量发生，但又无法分布式处理
顾客需要实时看到自己的足迹，因此不能使用缓存技术
HBase迎接挑战
天生就是面向时间戳的查询
行键的设计非常关键（因为HBase里面没有去重，关联等操作）。基于行键的查询异常迅速，特别是最近的数据被存放在内存的memstore里，完全没有IO开销。
分布式化解负荷
模式设计：
行键：user_id
列族和列：book:bookid
为了充分利用分布式，可以用reverse key，hash等技巧改造行键
场景二：商品推荐
使用关系型数据库实现：
设计一个log表，包含用户名，时间戳和书id三列
selecta.threadid,count(distinct a.userid) from testtj a,testtj b
where a.userid = b.userid
and b.threadid = 1479820
groupby a.threadid order by 2 desc limit 10;
使用HBase：
表设计与查询实现（后面还有一种方法，复合行键）
两个表，一个是u-t，另一个是t-u
u-t表的结构：行键为userid，列族和列为thread:threaded
t-u表结构：行键为threadid，列族和列为user:userid
查询：先从t-u表从threadid -> userid，再在u-t表从
userid -> threaded，在计算程序中实现去重(mapreduce)和统计功能。
关系型数据库辅助索引：
例子：学生表（学号，身份证号，姓名，性别），有时在学号上查询，有时在身份证号上查询
主表：行键为学号，列族为学生，下面的列是身份证号，姓名，性别等
辅助（索引）表：行键为身份证号，列族和列为学号
复合行键设计：
原表：
<userid>:<colfamily>:<messageid>:<timestamp>:<email-message>
12345:data:232f22f2-f22f2f-f2-f2f2f2f:1307097848:”HiLars,…”
……………..
复合行键索引表：
<userid>-<messageid>:<colfamily>:<timestamp>:<email-message>
12345-232f22f2-f22f2f-f2-f2f2f2f:data: 1307097848:”Hi Lars,…”
好处：
便于分布
便于多条件伸缩查询
版权声明：本文为博主原创文章，未经博主允许不得转载。