随着业务的不断增长,数据库中的数据也会越来越多,数据库的压力也会越来越大,我们会发现,在业务繁忙的
时候,数据库的性能会直线下降,这时为了保证良好的性能,不得不想办法来分担数据库的压力,前面在介绍数据库
架构高可用时,我们提到过,如果是为了分担数据库的读负载,我们可以采用主从复制的方式,给原来的数据库,增加几台
具有相同数据的从服务器,这样呢通过读写分离的方式,我们就可以把数据库的读负载,分担到不同的从数据库服务器中了,
这时在一段时间内呢,可能已经可以解决,我们的数据库性能问题了,但是随着业务的进一步发展,我们会发现,这时单一的主
数据库呢,已经负担不了写的负载了,那么这时我们要怎么办呢,当然我们可以升级主数据库的硬件,但是硬件的扩充,也只能解决
一时的问题,更何况MYSQL对于CPU的支持呢,也是有一个限度的,所以升级服务器的硬件,并不能完美的解决我们所遇到的问题,
那么我们只能对原有的主数据库服务器进行拆分了,通常来说,对主数据库服务器的拆分,有下面几种方式,第一种方式呢,
是把原来单一的主数据库服务器,多个数据库,拆分到不同的物理服务器中,数据库实例中去,我们知道,在一个MYSQL实例中,
可能包含多个逻辑数据库,比如下图中的MYSQL节点,就包含了订单库,用户库,促销库,有一点我们要注意,这里所说的MYSQL
节点,并不是代表一台MYSQL数据库,这里的节点代表的是MYSQL集群,也就是一组多从的数据库环境,只不过在这个集群中呢,
所有数据库的数据全都是一致的,所以为了方便,我们就称之为一个节点,那么单一节点的第一种方式呢,也就是把这个节点中
的不同数据库,拆分到不同的节点上去,以上面的MYSQL节点为例呢,我们可以把这个节点数据库,拆分到不同的三个节点上,
如果MYSQL节点一中,只包含订单库,增加MYSQL节点二,存储用户库,节点三来存储促销库,这样我们就把单一节点的写案列,
分摊到了三个节点上,这种做法的好处呢,是相对来说,实现数据库的拆分比较简单,特别是如果我们的业务应用,本身不允许
跨库查询的情况下,那么实现这种拆分呢,实际上只要对不同的数据库,连接进行一下配置就可以了,缺点呢就是如果我们
本身的写压力,就是集中在一个数据库中的话,比如我们原来的写压力呢,集中在订单数据库中,那么这样拆分后呢,实际上并不能
减少多少MYSQL节点一的写负载,那么接下来呢,我们再来看看分库分表的第二种方式,就像前面所说的,如果把一个数据库迁移到
一个独立节点中后,还是发现这个节点的主数据库呢,仍然不能负担这个数据库的写负载,我们要怎样处理呢,这个时候我们就可以
使用分库分表的第二种方式了
我们就可以使用分库分表的第二种方式了,就是把原来一个逻辑数据库中的表,分离到不同节点的不同数据库中,
一个数据库中呢,会有很多的表,这些表会记录不同主题的数据,比如我们前面介绍的订单数据库中,既可以存放
订单的相关信息,也可以存放商品的相关信息表,和购物车的相关信息表,不过通过分析,我们发现,这个数据库的
主要写压力呢,来源于购物车,和订单的相关表,那么这个时候我们就可以单独的把这两组表拆分到不同的数据库节点
中去,这样拆分后呢,每一个数据库实际上承担的,实际上是原来数据库表的一部分压力,这样就可以减轻原有数据库,
写负载的目的,使用这种方法呢,可以在一定的时间内,来解决我们的问题,但是随着我们业务的进一步发展,这时候
我们又发现,订单的相关信息表,所在的数据库节点呢,又出现写压力的问题,那么这个时候呢,又要如何处理呢,如果再想
按照主体进行拆分表的话,显然是不可能的了,所以这时我们就要使用分库分表的大招了,也就是传说中的表的水平拆分