Hbase建模

什么情况下使用Hbase？
1，成熟的数据分析主题，查询模式已经确定并且不易轻易改变。（主要还是查询模式要确定，否则，还是选用关系型数据库吧）
2，传统关系型数据库已经无法承受负荷，告诉插入，大量读取。
3，适合海量的，但同时也是简单的操作（例如key-value）

例子1：显示我的浏览历史，关系型数据库的困难：
1，简单的事情只要上了量就会变成无比复杂的事情
2，order by耗费很多性能
3，大量发生，担忧无法分布式处理
4，顾客需要实时看到自己的足迹，因此不能使用缓存技术

Hbase迎接挑战
1，天生就是面向时间戳查询
2，基于行健的查询异常快速，特别是最近的数据被放在memstore里，完全没有IO开销
3，分布式化解负荷

模式设计
行健：userid
列族和列：book：bookid
为了充分利用分布式，可以利用reverse key，hash等技巧改造行健

例子2：推荐系统
两个表，一个是u-t，另一个是t-u
u-t表结构：行健为userid，列族和列为thread：threadid
t-u表结构：行健为threadid，列族和列为user：userid
查询：现在t-u表从threadid->userid，再从u-t表中根据userid->threadid，最后在业务逻辑中实现去重、统计等功能。

辅助索引
例子：学生表（学号，身份证号，姓名，性别，系，年龄），有时在学号上查询，有时在身份证上查询
主表：行健为学号，列族为学生，下面的列式身份证号，姓名，性别，系，年龄
辅助（索引）表：行健为身份证号，列族和列为学号

复合行健设计
查询场景1：根据userid查询所有邮件
查询场景2：根据userid+messageid查询具体一封邮件
不同于辅助索引的“或”关系，这里是“且”的关系，解决方法就是设计复合索引：将userid+message作为复合索引
由于Hbase的行健按字典排序，且支持行健的范围查询，所以当需要查询userid的所有邮件时，只需查询行健范围为12345到123456的集合即可。
复合行健设计的优点：
1，行健比较随机，region有利于分散在各个节点，充分利用节点性能
2，便于多条件伸缩查询

Hbase建模
Hbase建模