一、100万级,1亿级,100亿级数据存储架构的演进
1.1、100万级数据:初始阶段,大部分的crud项目的数据是初始阶段
用结构化的数据库:mysql,PostgreSQL,单库单表,或者双库主从,单表
就可以了。这个时候数据量很少,吞吐量也很少,并发量很少。
1.2、1亿级数据:中间阶段,一般中等的项目的数据是中间阶段
这个时候做Mysql Sharding:解决单库单表的写和读的性能的瓶颈,容量
的瓶颈:分10个表来搞定,还需要redis做缓存:热点的数据的副本,es做
全文检索的数据的副本:跨库、跨表搜索。
1.3:100亿级数据:高级阶段,少量的项目的海量数据是百亿级数据
假设一个数据是1kb,那么百亿级是10TB的数据,没达到pb级数据,很少量的大厂能达到PB级的数据量。
解决100亿2数据用分库分表的话:理论:单表的机械指标是500万到1千万的数据。百亿级数据横向扩展,是需要1千张表不靠谱的。
解决方案:首先把数据分为结构化数据和非结构化数据
结构化数据:可以用分库分表,mysql sharding:存热数据:比如百亿级
订单,最近1年的订单。支持数据库事务的ACID,存储10亿的热数据。
分片的方式最少有三种方式支持比如:
客户端分片:sharding-jdbc
代理端分片:sharding-proxy
服务端分片:sharding-server.
不使用nosql的话,只使用sharding的话也需要历史订单的备份。
比如滚动式的做年分备份数据。
非结构化数据:nosql,列式存储,文档数据:存冷数据:不支持事务的,
做查询,数据建模,数据挖掘,支持统计,分析。也可以支持在线的访
问,查询。存100亿全量。nosql可以用hbase,hbase也要分多少个节
点。
redis:热点数据的副本
es:全文检索数据的副本,但是也会进行冷热分离,es的索引不止一个。
1.4、100*100亿级数据:高高级阶段:达到了PB级的数据,很恐怖的
需要基于上面的方案做横向扩展。比如1万个节点,1个亿的节点。需要冷热分离,热数据的节点会搞成很大。es的自定义词库刷新,索引刷新(常规的操作)