sharding:谁都能读懂的分库分表分区

Posted f-ck-need-u

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了sharding:谁都能读懂的分库分表分区相关的知识,希望对你有一定的参考价值。

本文通过大量图片来分析和描述分库、分表以及数据库分区是怎样进行的。

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.水平切分

水平切分:将大表按条件切分到不同表中。每个表存储一部分满足条件的行

水平切分通常有几种常用的切分方式:

  1. 直接按字段条件切分
  2. 取模后切分
  3. 按月份、季度、年份切分,或者称之为按范围切分

水平切分对性能提升非常大,不仅可以避开服务器资源争用,还减小了索引大小以及每个库维护的表数据量。

4.1 按字段条件进行切分

例如本文的示例中,按照考生所属地区对考生表进行水平切分,这是按照字段条件进行切分。

如下图,因为有34个省、市、区,所以分成34个考生表,每个考生表都放在地区命名的库中。各库可放在同一数据库服务器,也可以放在不同数据库服务器。例如,某些省市区的考生数量少,可以将多个这样的库放在同一个数据库服务器上,而山东、江西等高考大省,因为考生数量多,可以单独放在同一个数据库服务器上。

技术分享图片

技术分享图片

注意上述按字段条件进行水平切分时,表名不变,创建新的按地区命名的库,将各地区的表放置在对应的库中

通常,按照字段条件进行水平却分时,其它表也很有可能也按这个条件进行切分,使得满足条件的表都放在同一个库中,这样能保证正常的join操作

例如,上面切分了考生表,还可以切分成绩表,让同一个地区的考生表、成绩表放在同一个库中(所以,不能将考生表、成绩表进行业务分库)。

技术分享图片

技术分享图片

这样切分后,整个数据的分布情况如下:

技术分享图片

4.2 按范围进行切分

对于上面的成绩表,如果在此之前已经进行了业务分库,就无法让成绩表、考生表同时按照地区进行水平切分。这时可以进行范围切分,最常见的范围切分是按月份、季度、年份进行切分。

例如,本文示例的成绩表,可以按考生号范围切片,可按考生号取模后切片,也可按学科类别切片。例如,按考生号范围切片,每张表500W考生共3000W条成绩数据,共切成6片。

技术分享图片

技术分享图片

注意按照范围(或者取模、年份、月份、季度等)切片后,数据库的命名。这些库可以放在同一个数据库服务器上,也可以放在不同数据库服务器上。

如果对成绩表按照范围(或者取模、年份、月份、季度等)切片后,最好对考生表也按照同样的切分方式进行切片。举个反例很容易理解,这里的成绩表按照范围切分了,但是考生表按照地区切分,这两类库的名称之间将失去对应关系,对于数据维护来说可能会增加很大的难度。

按照这种模式的水平切分后,整个数据的分布情况如下(假设考生表也按范围切片):

技术分享图片

4.3 取模切分

取模是对数值或能转换为数值的字段进行取模,要切分成几片,就除几。

例如,按照取模切分的方式,将本文的考生表切分成6片。于是:

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.数据库分区

数据库分区:将大表进行分区,不同分区可以放置在不同存储设备上,这些分区在逻辑上组成一个大表,对客户端透明

  1. 分区方式和水平切片是类似的,分区方式也和水平切片方式类似,如范围切片,取模切片等
  2. 数据库分区是数据库自身的特性,切片则是外部强制手段控制完成的
  3. 数据库分区无法将分区跨库,更不能跨数据库服务器,但能保存在不同数据文件从而放置在不同存储设备上
  4. 数据库分区是数据库的特性,数据完整性、一致性等实现起来很方便,这一切都是数据库自身保证的

例如,对考生表按照地区进行分区。

技术分享图片

在数据库切片流行之前,对大表的处理方式就是划分分区表。数据库分区相比于切片,最大的缺点在于无法跨库、跨服务器,所以在某些方面的压力得到不缓解。

以上是关于sharding:谁都能读懂的分库分表分区的主要内容,如果未能解决你的问题,请参考以下文章

人人都能读懂的编译器原理

转载 | 人人都能读懂的编译器原理

人人都能读懂的非对称加密

小学生都能读懂的网络协议之:WebSocket

开发者都能读懂的云原生指南 —— 新程序员003

前任都能看懂的分库分表方案