hbase最大的不同
1， 没有索引，没有查询语句，所有的访问都是通过id的
id中会有很多查询逻辑，需要重点考虑

2， 用名值对来存放数据(行健，列族，列修饰符，时间，值)
没有列的概念，随性的定义列名，列名甚至能作为数据来存储

3， 反规范化，用冗余的数据来避免join查找，增加读的性能， 但写入时需要更新多个副本
传统数据的是规范化的，方便写，重复的信息会放在独立的表中。

4, 数据存放的不是文本，而是byte数组，需要用UTF-8来转义


-----hbase 特点-----
1， 宽表 高表
当用户关注某些人的时候可以用宽表设计
column qualifier是数字 value是被关注人
[table]
||follows|
|TheFakeMT|1:RealMT|2:MTFanBoy|3:Olivia|4:HRogers|
[/table]
如果要添加一个被关注人，需要当前的qualifier，必须在某个地方维护
[table]
||follows|
|TheFakeMT|1:RealMT|2:MTFanBoy|3:Olivia|4:HRogers|count:4
[/table]
计算的逻辑会让客户端很复杂
将被关注人放在qualifier中, value随便给
[table]
||follows|
|TheFakeMT|RealMT:1|MTFanBoy:1|Olivia:1|HRogers:1|
[/table]
但是无法得到计数

高表
[table]
||f|
|MD5(TheFakeMT)+MD5(RealMT)|from:TheFakeMT|to:RealMT|
|MD5(TheFakeMT)+MD5(MTFanBoy)|from:TheFakeMT|to:MTFanBoy|
|MD5(TheFakeMT)+MD5(Olivia)|from:TheFakeMT|to:Olivia|
|MD5(TheFakeMT)+MD5(HRogers)|from:TheFakeMT|to:HRogers|
[/table]
副作用 如果用户更新了他们的用户名，必须在本表中更新所有的名字，典型的反规范化处理。
所以微信中不允许修改用户名

question 为什么不能在一个qualifier中存放所有的被关注人，用特殊符合分割？
-- 如果增加一个被关注人的话需要将原来的被关注人重新update下。

2, 协处理器
observer 类似于 trigger
endpoint 类似于 存储过程 -- 在聚合中会使用到