出自

中华石杉

HBase使用场景条件, 第一个条件必须是海量的数据场景

用表来形容, 单表在千万以内级别的数据量级别都是属于小数据,千万级别的数据量最多只能说中等数据量,几千万条数据,MySQL搞一下分库分表,搞两三台服务器就可以轻松扛住千万级别数据量的表了.
假如说你单个表3000w条数据,你拆成三个库,每个库也就1000w条数据了.再给表拆开,拆成1024个表,可能每个表就几万条数据了.
基于一些分库分表中间件,比如说Mycat等等直接做一些路由什么的就可以轻松搞定几千万级别的数据了,性能也很高的.

另一方面还要看增量数据,假设几千万条数据是过去历史几年下来积累的.每年积累一千万条数据,拆到每个月也就100w条数据左右,拆到每一天的话基本上每一天也就是几万数据量, 差不多10年才一亿条数据,

MySQL分库分表的技术方案抗下小亿级别的数据量都是OK的,总共一两亿的数据量你做一个分库分表,多搞几个库多拆一些表基本都是OK的.
你10年才一亿数据量,20年才2亿数据量,说实话,你能不能干到那个时候还不一定了, 公司能不能活到那个时候还不一定了.
可能你作为系统的负责人,在可见的范围内基本上单表也就撑死几千万到一两亿级别的.到一两亿级别可能都得10到20年以后了.
所以你根本就不用考虑这么多了.像这种级别的存量和增量的数据量,你用MySQL 分库分表就可以轻松搞定了.

几千万数据可能也就几个G大小文件,几亿数据可能也就几十G. 几十亿数据可能会到TB级别.

你用MySQL分库分表最多也就是做一些跨库跨表的SQL,不太好做,就可以自己查询一些数据放到内存里面来做定时计算也是可以的…
当然分库分表的话,每次扩容的时候会稍微麻烦一些,迁移数据运维会有点小麻烦的.还有就是跨库操作会稍微繁琐一些.

什么是海量数据?

就是历史有几亿条数据,然后每年还1亿1亿的网上涨,几年以后就能轻松过10亿数据量,10年以后可能都会达到几十亿的数据量. 这样的场景才能够叫海量数据场景的初级门槛.

如果你每年都新增好几亿数据量,那么你需要频繁的扩容,你就得使用天然的分布式技术了,比如说HBase,你往表里面不断的灌数据,数据量会越来越多,你每隔一段时间就给HBase集群添加机器就行了. HBase扩容的运维操作会比你MySQL分库分表扩容要简单很多,你对HBase进行增删改查的时候你不用考虑跨库操作(MySQL分库分表方案需要考虑跨库操作表的问题).

总结

1.如果你是海量数据场景,你经常需要扩容,还经常出现跨机器的增删改查,那你用HBase是很合适的,
2. 简单的增删改查,没有复杂的需求 (HBase不支持事务啥的.)