(1)海量数据场景
表来形容,单表在千万以内级别的数据量,基本都是小数据,千万级别的数据量,最多只能说是中等数据量,MySQL搞一下分库分表,搞个两三台服务器,就可以轻松抗住千万级别的数据量的表了,每个表可能也就几万条数据了
基于分库分表的中间件,mycat、sharding-sphere,都可以的,直接做一些路由什么的,就可以轻松搞定几千万级别的数据了,性能也是很高的
假设几千万条数据是过去历史几年下来积累的,每年积累一千万数据,每个月也就100万数据左右,每一天几万数据量,10年才1亿数据,MySQL分库分表的技术方案,抗下小亿级别的数据量都是ok的,一两亿数据
可能你作为这个系统的负责人,在可见的范围内,基本上单表撑死也就几千万到一两亿级别,10年、20年以后了,不用考虑这么多了,其实像这种级别的存量和增量的数据量,用MySQL分库分表就可以轻松搞定了
要做一些跨库跨表的SQL,不太好做,可以自己查询一些数据放到内存来做定制计算也是可以的
什么叫做海量数据?说不好听的,假设你就几百万数据,用MySQL就可以轻松高兴了,要是你有几千万数据呢?基本到MySQL的瓶颈和极限了。要是你有几亿条数据呢?而且每天数据量还在不停的增长呢?
这个时候你就可以使用hbase了,他天生就是分布式的,可以扩容很方便,数据分布式存储,自动数据分片,完善的运维管理,底层集成hdfs做分布式文件系统,增删改查的nosql功能都支持,你几亿到几十亿的数据放里面很适合,而且数据还一直在增长
绝对比mysql分库分表要来的方便的多
(2)只需要简单的增删改查的支持
你对海量的数据仅仅就是简单的增删改查的支持,绝对没有MySQL那种关系型数据库支持的列类型、索引、事务、SQL语法,那么多高阶的特性,你要是不需要索引、SQL和事务,那妥妥的用hbase就可以了
虽然hbase之上有很多开源组件,可以搞二级索引、phoniex可以支持SQL,但是说实话,真的没必要,人家hbase就不是干这个的,麻烦大家别折腾他好吗
你要海量数据下支持事务,可以用分布式数据库,比如TiDB;你要海量数据下支持复杂SQL实时分析,可以用clickhouse,或者是druid之类的