本文转自:https://www.cnblogs.com/f-ck-need-u/p/9388407.html
本文通过大量图片来分析和描述分库、分表以及数据库分区是怎样进行的。
1.sharding前的初始数据分布
在本文中,我打算用高考考生相关信息作为实验数据。请无视表的字段是否符合现实,也请无视表的设计是否符合范式。
3张表:
- 考生表,存放全国所有高考考生信息,假设34个省、(直辖)市、(自治区、特别行政)区共3000W考生
- 学科表,分文理科,共9门课程(语文、数学、英语、历史、地理、政治、物理、化学、生物)
- 成绩表,存过全国所有考生所有学科成绩,每个学生6门成绩,共1.8亿条成绩数据
三张表放在名为"gaokao_db"的库中。所以,它们的结构如下:
这三张表的大致存储方式如下:
这个时候数据存储方式是单库多表。
2.业务分库
业务分库:按业务将不同表放进不同库。每个库可以放在不同数据库服务器上。
例如,在这里将原始数据库gaokao_db中的3个表分开放进两个数据库中,stu_db存放考生表,score_db存放成绩表。
还有一张学科表放在哪呢?对于那些很小、无需进行切片的表,可以将多个这样的表共同放在同一个库中,也可以根据联接特性将其分开放置在常与之进行联接的库中。在此处,学科表很小,没必要单独占用一个库甚至数据库服务器,且由于学科表只会和成绩表进行联接,所以将其放在score_db库中。
业务分库如下图:
stu_db和score_db可以放在同一数据库服务器上,也可以放在不同数据库服务器上,从而在整体上减轻系统的压力。但是,如果这两个库放在不同服务器上,因为跨数据库实例,将没法对stu_db和score_db中的表进行join操作。
一般来说,对于可预见的、不断增长的数据,业务分库可能最先进行的sharding。
3.垂直切分
垂直切分:将一个表按照字段分成多表,每个表存储一部分字段。表可以放在不同存储设备上。
其实,在最初设计数据库的时候,因为是关系型数据库,或多或少都会去遵守一些设计范式。当设计的数据库表满足第一范式、第二范式、第三范式等等范式要求时,其实就已经进行了所谓的垂直切分。
即使按照范式设计了数据库表,但有些表是宽表,有很多可能很少使用的字段,这些字段可能是按照稀疏列进行管理的,也可能是大BLOB后大text字段。此外,表中的字段还可以划分为"热门字段和冷门字段",例如本文示例中,相比考生号、姓名、所属地区使用频繁程度,考生电话号码可能很少使用、身份证号也很少使用,所以这两个字段是冷门字段。
所以,当表数据量很大时,即使满足了范式要求,还是可以强行将表按字段切开,将热门字段、冷门字段分开放置在不同库中,这些库可以放在不同的存储设备上,避免IO争抢。
如下图:
注意,垂直切分后的表,要能进行关联,所以在此处的其它信息表中加上了考生号字段。
垂直切分其实是更深一步的范式设计,或者反范式设计。垂直切分带来的性能提升,主要集中在热门数据的操作效率上,而且磁盘争用情况减少。但如果想要将两个表中的数据再次联合起来,性能将比垂直切分前差的多。
另外,有很多人将业务分库当作垂直切分,其实这都不重要,重要的是知道各种手段是干嘛的。不过在本文以及我后面的文章,将认为业务分库和垂直切分是不同sharding的分类。
4.水平切分
水平切分:将大表按条件切分到不同表中。每个表存储一部分满足条件的行。
水平切分通常有几种常用的切分方式:
- 直接按字段条件切分
- 取模后切分
- 按月份、季度、年份切分,或者称之为按范围切分
水平切分对性能提升非常大,不仅可以避开服务器资源争用,还减小了索引大小以及每个库维护的表数据量。
4.1 按字段条件进行切分
例如本文的示例中,按照考生所属地区对考生表进行水平切分,这是按照字段条件进行切分。
如下图,因为有34个省、市、区,所以分成34个考生表,每个考生表都放在地区命名的库中。各库可放在同一数据库服务器,也可以放在不同数据库服务器。例如,某些省市区的考生数量少,可以将多个这样的库放在同一个数据库服务器上,而山东、江西等高考大省,因为考生数量多,可以单独放在同一个数据库服务器上。
注意上述按字段条件进行水平切分时,表名不变,创建新的按地区命名的库,将各地区的表放置在对应的库中。
通常,按照字段条件进行水平切分时,其它表也很有可能也按这个条件进行切分,使得满足条件的表都放在同一个库中,这样能保证正常的join操作。
例如,上面切分了考生表,还可以切分成绩表,让同一个地区的考生表、成绩表放在同一个库中(所以,不能将考生表、成绩表进行业务分库)。
这样切分后,整个数据的分布情况如下:
4.2 按范围进行切分
对于上面的成绩表,如果在此之前已经进行了业务分库,就无法让成绩表、考生表同时按照地区进行水平切分。这时可以进行范围切分,最常见的范围切分是按月份、季度、年份进行切分。
例如,本文示例的成绩表,可以按考生号范围切片,可按考生号取模后切片,也可按学科类别切片。例如,按考生号范围切片,每张表500W考生共3000W条成绩数据,共切成6片。
注意按照范围(或者取模、年份、月份、季度等)切片后,数据库的命名。这些库可以放在同一个数据库服务器上,也可以放在不同数据库服务器上。
如果对成绩表按照范围(或者取模、年份、月份、季度等)切片后,最好对考生表也按照同样的切分方式进行切片。举个反例很容易理解,这里的成绩表按照范围切分了,但是考生表按照地区切分,这两类库的名称之间将失去对应关系,对于数据维护来说可能会增加很大的难度。
按照这种模式的水平切分后,整个数据的分布情况如下(假设考生表也按范围切片):
4.3 取模切分
取模是对数值或能转换为数值的字段进行取模,要切分成几片,就除几。
例如,按照取模切分的方式,将本文的考生表切分成6片。于是:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
00000001 % 6 = 1 --> 放进stu_1库 00000002 % 6 = 2 --> 放进stu_2库 00000003 % 6 = 3 --> 放进stu_3库 00000004 % 6 = 4 --> 放进stu_4库 00000005 % 6 = 5 --> 放进stu_5库 00000006 % 6 = 0 --> 放进stu_0库 ... 00000101 % 6 = 5 --> 放进stu_5库 00000102 % 6 = 0 --> 放进stu_0库 00000103 % 6 = 1 --> 放进stu_1库 00000104 % 6 = 2 --> 放进stu_2库 00000105 % 6 = 3 --> 放进stu_3库 00000106 % 6 = 4 --> 放进stu_4库 ...
注意,取模切片后的表名仍然为考生表,这些考生表放在对应的库里,这些库可以单独放在一个数据库服务器上,也可以多个库一起放在同一个数据库服务器上。
5.数据库分区
数据库分区:将大表进行分区,不同分区可以放置在不同存储设备上,这些分区在逻辑上组成一个大表,对客户端透明
- 分区方式和水平切片是类似的,分区方式也和水平切片方式类似,如范围切片,取模切片等
- 数据库分区是数据库自身的特性,切片则是外部强制手段控制完成的
- 数据库分区无法将分区跨库,更不能跨数据库服务器,但能保存在不同数据文件从而放置在不同存储设备上
- 数据库分区是数据库的特性,数据完整性、一致性等实现起来很方便,这一切都是数据库自身保证的
例如,对考生表按照地区进行分区。
在数据库切片流行之前,对大表的处理方式就是划分分区表。数据库分区相比于切片,最大的缺点在于无法跨库、跨服务器,所以在某些方面的压力得到不缓解。
6.分库、分表带来的问题
因为分库、分表可以将大表切分成多个片段,每次检索时可以只检索一小个片段,且因为这些片段可以分开存放在不同存储设备、不同数据库服务器上,它的整体性能得到了很大的提高。但是,随之而来不少问题。最主要集中在以下几个方面。
1.分库分表本身的复杂性
分库分表的方式可以在开发端通过代码来实现,也可以在app和数据库中间使用中间件来实现(如mycat),还可以直接使用分布式数据库(如TiDB、OceanBase)替代传统关系型数据库。无论是哪一种方案,学习成本、维护成本都有一段阵痛时期。
2.分库分表让数据库系统架构变得复杂
特别是添加中间件的方式,毕竟在app和数据库中间多了一层,这一层不能出现单点故障。
3.跨节点join问题
当进行了业务分库,或者其它切片方式将库放置在不同数据库实例上时,因为跨了实例,将无法进行join操作。
4.扩容和数据迁移艰难
对于那些以范围、取模方式做水平切分的大表,扩容以及扩容时的数据迁移很艰难。需要解决几个问题:
- 扩容到多少节点比较满足自己的期望。
- 扩容时,哪些数据需要从旧节点清洗掉,哪些数据需要从旧节点迁移到新节点。
- 如何实现在线迁移。
例如原本按照4个节点取模分片,现在出现了瓶颈,想要扩容成6个节点。
第一个问题,从4个节点扩容为6个节点,在整体上大致能提升50%的性能。
第二个问题和第三个问题。看如下数据分布情况
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
扩容前 扩容后 0 % 4 = 0 0 % 6 = 0 1 % 4 = 1 1 % 6 = 1 2 % 4 = 2 2 % 6 = 2 3 % 4 = 3 3 % 6 = 3 4 % 4 = 0 4 % 6 = 4 -> 从0节点迁移到4节点 5 % 4 = 1 5 % 6 = 5 -> 从1节点迁移到5节点 6 % 4 = 2 6 % 6 = 0 -> 从2节点迁移到0节点 7 % 4 = 3 7 % 6 = 1 -> 从3节点迁移到1节点 8 % 4 = 0 8 % 6 = 2 -> 从0节点迁移到2节点 9 % 4 = 1 9 % 6 = 3 -> 从1节点迁移到3节点 10 % 4 = 2 10 % 6 = 4 -> 从2节点迁移到4节点 11 % 4 = 3 11 % 6 = 5 -> 从3节点迁移到5节点 12 % 4 = 0 12 % 6 = 0 13 % 4 = 1 13 % 6 = 1 14 % 4 = 2 14 % 6 = 2 15 % 4 = 3 15 % 6 = 3 16 % 4 = 0 16 % 6 = 4 -> 从0节点迁移到4节点
可见,每12条数据就要从旧节点迁移8条数据,而且这8掉数据还是在各个节点之间交叉迁移。这使得数据迁移非常复杂,不是想加几个节点就加几个节点,让扩容变得不再随心所欲。一种比较好的解决方案是双倍扩容,例如从4节点扩容为8节点。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
扩容前 扩容后 0 % 4 = 0 0 % 8 = 0 1 % 4 = 1 1 % 8 = 1 2 % 4 = 2 2 % 8 = 2 3 % 4 = 3 3 % 8 = 3 4 % 4 = 0 4 % 8 = 4 -> 从0节点迁移到4节点 5 % 4 = 1 5 % 8 = 5 -> 从1节点迁移到5节点 6 % 4 = 2 6 % 8 = 6 -> 从2节点迁移到6节点 7 % 4 = 3 7 % 8 = 7 -> 从3节点迁移到7节点 8 % 4 = 0 8 % 8 = 0 9 % 4 = 1 9 % 8 = 1 10 % 4 = 2 10 % 8 = 2 11 % 4 = 3 11 % 8 = 3 12 % 4 = 0 12 % 8 = 4 -> 从0节点迁移到4节点 13 % 4 = 1 13 % 8 = 5 -> 从1节点迁移到5节点 14 % 4 = 2 14 % 8 = 6 -> 从2节点迁移到6节点 15 % 4 = 3 15 % 8 = 7 -> 从3节点迁移到7节点 16 % 4 = 0 16 % 8 = 0
这样每8条数据迁移4条,且需要迁移的数据不会在各节点之间交叉。这样迁移要方便的的,而且性能提升100%。但是因为要迁移的数据量较大,迁移速度较慢,而且每次扩容都采取双倍扩容,必须要考虑服务器成本。
还有一种比较流行的"业务双写"迁移法。相比于双倍扩容法,它仍然很复杂。它的迁移过程大概是这样的:
- 加入新节点。
- 将业务写入过程按照旧规则和新规则同时写到新旧节点(业务双写)。例如4节点扩容到6节点时,id=2000的数据(假设之前没有该数据)将同时写入到0节点和2节点,id=2003将同时写入3节点和5节点。
- 迁移旧数据。
- 应用新规则,将新节点向外提供服务。
- 清洗旧数据。
双写能保证迁移数据的过程仍然持续在线提供服务。但是,那些已存在的旧数据迁移仍然较为复杂,需要仔细琢磨要迁移哪些数据,以及迁移到哪个节点,这点必须把控好。