ShadringSphere-01数据库架构演变

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《ShadringSphere-01数据库架构演变》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下MySQL、springboot、shardingsphere，希望所有认真读完的童鞋们，都有实质性的提高。

1、如今随着互联网的发展，数据的量级也是成指数的增长，从GB到TB到PB。对数据的各种操作也是愈加的困难，传统单体的关系性数据库已经无法满足快速查询与插入数据的需求。然后在事务安全性,NOSQL数据库对事务的支持也不完善. MySQL不可替代。
2、所以我们现在的需求：在海量数据的情况下，我们如何做到既要使用关系型数据库，又要满足快速的插入和查询？
面临问题：
● 用户请求量大
● 单库的数据量过大
● 单表的数据量过大
3、解决方案：单机数据库 --> 主从架构 ---> 分库分表

1. 单机数据库

在单台服务器上运行我们所有的程序和软件，适用于用户量比较少、访问量也比较少的情况。

但是随着访问量的增加，单台应用服务器已经无法满足我们的需求。所以我们通过增加应用服务器的方式来将服务器集群化。

采用了应用服务器高可用集群的架构之后,应用层的性能被我们拉上来了,但是数据库的负载也在增加,随着访问量的提高,所有的压力都将集中在数据库这一层.

2.主从架构

为了解决数据库层负载压力过大的问题，因为读操作和写操作消耗的资源是不一样的，并且在实际生产中，读操作比写操作多的多，所以可以进行读写分离。

使用主从复制+读写分离一定程度上可以解决问题，但是随着用户量的增加、访问量的增加、数据量的增加依然会带来大量的问题。
随着访问量的持续不断增加，慢慢的我们的系统项目会出现许多用户访问同一内容的情况，比如秒杀活动，抢购活动等，那么对于这些热点数据的访问，没必要每次都从数据库重读取，这时我们可以使用到缓存技术，比如 redis、memcache 来作为我们应用层的缓存。

存在的问题：
● 缓存只能缓解读取压力，数据库的写入压力还是很大，该架构还是没有解决单表数据量过大的问题

1、我们的系统架构从单机演变到这个阶段，所有的数据都还在同一个数据库中，尽管采取了增加缓存，主从、读写分离的方式，但是随着数据库的压力持续增加，数据库的瓶颈仍然是个最大的问题。因此我们可以考虑对数据的垂直拆分和水平拆分。
2、垂直拆分：结构上的拆分，和数据没有关系
3、水平拆分：根据数据进行拆分

3. 分库分表

1、什么是分库分表
分库分表简单来说，就是指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载的效果。
2、解决的问题
要解决的就是数据量过大而导致数据库性能降低的问题
3、什么情况下要使用分库分表
● 单机存储容量达到瓶颈
● 连接数，处理能力达到上限
4、方式
进一步按照垂直和水平进行划分，分库分表可以有如下方式：
● 垂直分库
● 垂直分表
● 水平分库
● 水平分表

在实际生产中，垂直拆分我们一般在数据库的设计阶段就完成，因为垂直拆分和数据没有关系，只是在结构上进行拆分，随着数据和访问的增加，后续的优化，优先选择SQL优化，表字段优化、索引优化、参数优化、引入缓存等，到最后是在不行了再进行分表操作（水平拆分）

3.1 垂直分库/分表

垂直分库：数据库中不同的表对应着不同的业务，垂直切分是指按照业务的不同将表进行分类,分布到不同的数据库上面，将数据库部署在不同服务器上，从而达到多个服务器共同分摊压力的效果
垂直分表：表中字段太多且包含大字段的时候，在查询时对数据库的IO、内存会受到影响，同时更新数据时，产生的binlog文件会很大，MySQL在主从同步时也会有延迟的风险，所以我们可以根据字段的访问频率把一张表拆分成多张表，每个表存储一部分字段。

好处：
1、解决了业务上的耦合、业务更加清晰、能够对不同的业务数据进行管理
2、在高并发场景先，在一定程度上提高访问性能
问题：但是我们可以看到垂直拆分并没有根本解决单表数据量过大的问题

3.2 水平分库/分表

水平分库：将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表结构，只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈

水平分表：针对数据量巨大的单张表（比如订单表），按照规则把一张表的数据切分到多张表里面去。 但是这些表还是在同一个库中。

今天关于《ShadringSphere-01数据库架构演变》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！