ShardingSphere应用专题--常见数据库架构的演进（二）

开始阶段：阶段1

这个时候项目伊始，怎么简单怎么来自然是使用单一的数据库架构。

阶段2

随着时间的推移，数据库存储的数据没有超过1TB，存储压力不是很大。但是数据访问量上来了，数据库的链接数及IO吞吐量成为系统瓶颈。这个时候，主从上场：

由于主从分离，单一数据库的访问量降低，磁盘IO也随之降低。且随着访问量继续升级，增加从库可以很好的降低系统压力。

又没过多久，随着数据量的激增，此时数据库数据量太大。这个时候要分两种情况：

阶段3-1

整个库的存储早已超过了1TB，且数据量基本平均分布在多个表中，单表最大没有超过1千万数据。此时，主库压力过大，增加从库已经无法解决该问题。

这个时候，性能瓶颈点在于单库存储过大，磁盘内容太多导致整体数据库性能低下.分库策略可以解决这个问题：

将表按照一定的规律，拆分到多个数据库中。单库存储压力骤降。问题解决。

阶段3-2

整个库的存储没有远超过1TB，且数据量基本都分布在几个表中，且单表已经达到千万级数据。此时，单库查询效率将受到极大影响，增加从库已经无法直接解决问题。此时增加分表策略：

单表被拆成了N个子表，单表查询效率获得极大提升，虽然多表数据联合在服务层会影响性能，但是核心问题解决后，性能提升依旧可观。

阶段4

单库远超1TB，多个单表达到千万甚至上亿级别。此时上最终大招：

整个阶段演进图：