企业中数据存储方案泛讲

对企业中常见的存储方案做一下简要介绍

毕业之后就没有更新博客了，后面要陆续捡起来了，hhhhhhhhhhhhh…

存储DB

1. TiDB相比mysql大数据量下避免分库分表降低业务复杂度，支持分布式事务，高度兼容Mysql5.7，高并发能力一般达不到nosql那种，qps也不如mysql。
2. Hive 高可用，mapreduce计算引擎，查询慢，数据不能修改，只能追加。
3. Impala 基于Hive抛弃MR自己做内存引擎，查询快（秒级），缺点内存要求高并行有限。
4. Hbase 分布式，易扩展，高可用，高并发写入，高并发查询稍慢需要缓存系统支撑，不支持sql，Rowkey设计巧妙。
5. Kudu （Hive+Hbase），可结合impala进行sql查询（OLAP）， 实时读写功能，实时能力比hbase弱，写入性能高，批量模式写入可达百万级QPS，缺点：单记录模式写入，稳定性，高并发读取。
6. Kylin Cube预计算（亚秒级） 支持RestApi，方便与BI整合（superset），缺点：维度不能太多防止cube爆炸。
7. mongo 结构随意调整，性能优越，海量数据， 缺点不支持连表，不支持事务（最终一致），自身mapreduce慢，复杂计算依靠spark，不适合数据分析场景。
8. redis 读写性能高，数据持久化，结构丰富，主从复制， 缺点：容量有限，扩容困难需要提前预估好容量，无法连表查询，复杂OLAP需要Spark，redis cluster比单机性能要差一些（分布式hash计算等消耗）。
9. couchbase 高可用，自带console运维方便，读写非常快，文档存储水平伸缩，缺点：value类型单一，资料少排查难。
10. ES 日志分析经常用，全文检索，插件化，成熟的ELK日志分析平台 缺点：磁盘和内存消耗大，修改字段需要重新建立索引。

没有十全十美的数据存储，一定会有所倾重，就像不会同时兼得olap和oltp特性，因为本身就是背道而驰的，所以db方案选取合适自己的业务最重要了。

待详细补充各数据库细节。。。