（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之类的