00:01
这节课呢,我们来讲一下水平分片,那水平分片呢,其实就是将表进行水平拆分,这种方案呢,比较适合表的数据行特别大的表,比如上面我们举的这个例子,如果单表的用户记录特别多的话,那么我们呢,可以这样对表进行拆分,那么相对于咱们上堂课讲的垂直拆分的话呢,这种拆分的方式呢,就叫水平拆分。那有的公司呢,是要求超过500万条记录就进行分表了,比如说阿里巴巴。还有一些公司呢,它的要求呢,是单表行数超过5000万条记录才进行分表的,无论是500万条记录还是5000万条记录,这些呢都不是绝对的标准,关键呢还是要看表的访问性能,那么相对于一些比较复杂的表,可能超过500万条记录就要分表了,而相对于一些简单的表,即使我们存储的数据超过1亿行。有可能也不用分表,但是不管怎样呢,当我们看到表的数据这个容量啊达到千万级别的时候,那么作为架构师你其实呢,就要警觉起来了,因为这个很有可能呢,就是架构性能的瓶颈或者是隐患所发生的位置了。那分表的策略呢有很多,一般情况下呢,我们会根据某个字段或者是某几个字段进行拆分,例如通常情况下呢,我们最常用的手段呢,就是按照主键进行分片。
01:28
在这个例子当中,比如说在分表之前有一个数据库,这个数据库当中呢,我们存储了一个叫做T的表啊,那无论我们是查询UCIID等于一的数据,还是查询UCID等于二的数据,我们都从这个单一的数据库当中进行查询,那么如果对我们的这个数据进行分表操作,并且呢,我们把这个表分别啊切分到了两个不同的数据库当中,那么就是下面这种解决方案了。那这个时候呢,我们就有两个数据库了,那么我们呢,会对这个ID呢,进行一个对二取模的操作,如果对二取完之后,它的余数等于一的话,我们呢,就把这个记录呢路由到。
02:13
这数据库当中,如果对二取模之后呢,它的这个值呢等于零的话,那么呢,我们就把这个数据呢路由到。第二台数据库服务器当中,所以呢,呃,插入数据的时候,我们会这样去路由,当然查询数据的时候呢,我们依然会采用同样的方式去路由,那这样的话我们就完成了数据分片的操作。那么单表进行切分之后呢,是否要将切分后的多个表分散在不同的数据库服务器当中,可以根据实际的切分的效果来定,比如刚才我们举的这个例子呢,就是将切分后的多个表呢,拆分到了不同的数据库当中,但是呢,这种拆分到不同的数据库当中呢,并不是强制要求的,原因在于呢,单表进行拆分之后,新的表即使在同一个数据库服务器当中,其实绝大部分情况下也会带来很可观的一个性能的提升,那么如果我们说这个性能的提升完全能够满足我们的业务的要求的话,那么是不建议大家把多个表拆分到多台数据库服务器的啊,毕竟呢,你把这个多个表拆分到多台数据库服务器,会引入很多业务的复杂性。
03:26
比如事物的问题,比如说查询出来之后,这个表的数据的连接的问题,那么如果单表拆分为多表之后,单台服务器还是没有办法满足数据库性能的要求的话,那么就不得不再次进行分库的设计了啊。所以说其实刚才我们提到的是两种具体的设计方案,第一种是水平分表,详细来说呢,就是把一个表拆分到多个表当中,但是呢,这多个表呢,还是在一台数据库服务器当中。第二个呢,我们可以把它理解为水平分库,就是呢把一个表拆分到多个表当中,但是呢,这个表呢,是分散在不同的数据库服务器当中,在实际的业务当中,我们也可以这两种方式呢去结合使用,比如说我们有两台数据库,然后这台数据库当中呢放两张表啊,这台数据库当中呢放另外两张表,那么我们一共把一个表呢,拆分成四张表,把它分散在两个不同的数据库当中,那具体在实际的生产环境当中如何去选择呢?还是要根据具体的我们实际的拆分效果确定的好。
04:32
那实际上在阿里巴巴的这个Java开发手册当中呢,他除了要求我们500万条记录,或者是2GB可以进行分库分表之外呢,实际上他在这个里面强调的呢,就是不要去滥用分库分表,那后面呢,他有一个进一步的说明,就是如果预计三年之后我们的数据量达不到这个级别,那你就不要在创建数据库的时候立即进行分库和分表的操作。因为这样呢,实际上在数据量比较少的情况下,我们强行进行分库和分表呢,这种方案呢,反而会让我们的系统性能的下降啊,因为在这个过程当中,我们要解决分布式事务的问题,要解决跨库关联的问题,当然了还要有一些数据库成本的问题,好,那这个是我们所说的水平分。
我来说两句