CN115576919A

CN115576919A - 一种数据分库分表的方法

Info

Publication number: CN115576919A
Application number: CN202211170500.0A
Authority: CN
Inventors: 刘明伟; 敖知琪; 陈禹旭; 康旖
Original assignee: Southern Power Grid Digital Grid Research Institute Co Ltd
Current assignee: Southern Power Grid Digital Grid Research Institute Co Ltd
Priority date: 2022-09-22
Filing date: 2022-09-22
Publication date: 2023-01-06

Abstract

本发明提供的一种数据分库分表的方法，包括：将数据分散到多个数据库；突破单节点性能限制；划分中间件的切入层次；拆分的基本原则；将数据分片、分布式事务和数据库治理。实现了各省业务相对独立，同一省的数据在同一个库；避免了跨分片查询/连接/事务；使用数据库分区表，屏蔽水平分表复杂性；方便历史数据迁移。中台要存储各个业务域的数据，涉及范围广、数据量大。

Description

一种数据分库分表的方法

技术领域

本发明涉及数据监管领域，尤其涉及一种数据分库分表的方法。

背景技术

中台要存储各个业务域的数据，涉及范围广、数据量大。对于数据存储的性能、扩展性、可靠性要求较高。同时中台是面向各个业务域的业务系统，对于TP并发性能、访问速度要求也是很高的。传统的将数据集中存储至单一数据节点的解决方案，在性能、可用性和运维成本这三方面已经难于满足中台海量数据场景。

从性能方面来说，关系型数据库大多采用B+树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的IO次数增加，进而导致查询性能的下降；同时，高并发访问请求也使得集中式数据库成为系统的最大瓶颈。

从可用性的方面来讲，服务化的无状态型，能够达到较小成本的随意扩容，这必然导致系统的最终压力都落在数据库之上。而单一的数据节点，或者简单的主从架构，已经越来越难以承担。数据库的可用性，已成为整个系统的关键。

发明内容

鉴于上述问题，提出了本发明以便提供克服上述问题或者至少部分地解决上述问题的一种数据分库分表的方法。

根据本发明的一个方面，提供了一种数据分库分表的方法包括：

将数据分散到多个数据库；

突破单节点性能限制；

划分中间件的切入层次；

拆分的基本原则；

将数据分片、分布式事务和数据库治理。

可选的，所述将数据分散到多个数据库具体包括：

数据库分区，将表的数据均衡分摊到不同的硬盘、系统和不同服务器存储介质中，实现将表的数据均衡到不同的地方；

业务层分区，将大数据库分布到多个物理节点上的一个分区方案，每一个分区包括数据库的一部分，包括分表、分库两种方式；所述分表把数据库中数据根据按照分库原则分到多个数据表中。

可选的，所述拆分的基本原则具体为原则零，能不分就不分，具体包括：优先垂直拆分、优先硬件升级和水平分片。

可选的，所述优先垂直拆分包括：垂直分库和垂直分表；

所述垂直分表为按照业务情况、使用评率的维度拆分；

所述垂直分库是根据数据库里面的数据表相关性进行拆分，按照业务拆分的方式分为垂直分片；

在拆分之前，一个所述数据库包括多个数据表，每个所述数据表对应不同的业务；

在拆分之后，按照业务将表进行归类，分布到不同的数据库中，将压力分散到不同的数据库。

可选的，所述水平分片包括：分库和分表两种方式，按照业务需求进行合理设计分片键，避免跨片区的事务和查询。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本发明实施例提供的以Shardingsphere中间件为技术路线，以垂直分库+水平分片为策略的整体结构图；

图2为本发明实施例提供的中间件切入层次示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明的说明书实施例和权利要求书及附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元。

下面结合附图和实施例，对本发明的技术方案做进一步的详细描述。

本发明基本思路是基于关系型数据库，使用分库分表的方法来解决大数据量的存储、扩展、性能方面的需求。

分库分表如何开发实施，后期如何运维管理不同的分库分表策略、分表配置，以及对分片后的库表管理是本文需要考虑和解决的。

同时分库分表后，上层服务代码的开发、调用是否有影响。以及分库分表后导致的事务一致性问题，在开发上面临的诸多问题，是本文需要考虑和解决的。

技术方案主要目的要解决几个问题：

满足6大中心TB级数据量的存储(单表10亿条)，具备扩展能力；满足各个业务系统对数据共享服务、数据库的性能要求，例如：TPS>1000，QPS>2000；分库、分表的统一配置、统一开发、统一维护的管理机制；分库、分表开发所引发的分布式事务、分布式主键、分布式查询的问题；制定了以Shardingsphere中间件为技术路线，以垂直分库+水平分片为策略的整体技术方案。

如图1所示，上图中的数据底座中的6个业务中心数据，采取垂直分库方案让不同业务中心的数据存储到不同的数据库中。

6个业务中心表数据根据表数据大小按照水平分片方案，让大表数据根据分片配置信息分别存储在不同的子表中，满足数据存储扩展性要求，同时提高数据库吞吐量，以满足并发性能要求。

在业务应用上使用Shardingsphere实现分片方案，并可使用由Shardingsphere提供的分布式主键生成方案，同时形成对分库、分表及的统一配置、统一开发、统一维护的管理机制。使用Seata实现分布式事务方案。使用Presto实现跨库查询方案，并对跨库查询配置信息进行统一管理。

在大数据时代，随着业务数量的暴增和应用规模的不断扩大，关系型数据库本身比较容易成为系统性能瓶颈，单机存储容量、连接数、处理能力等都很有限，都会面临服务器CPU、磁盘IO和内存的各种瓶颈问题。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。数据库本身的“有状态性”导致了它并不像Web和应用服务器那么容易扩展。

基于此情况，在互联网行业海量数据和高并发访问的考验下，业界提出了数据分片技术。数据分片就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量突破单节点数据库的性能限制，解决数据库扩展性问题，减少数据库的负担，缩短查询时间，从而达到提升数据库操作性能的目的。数据分片的一般方式包括数据库分区、业务层分区。

数据库分区是一种物理数据库的设计技术，它的目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间。分区并不是生成新的数据表，而是将表的数据均衡分摊到不同的硬盘，系统或是不同服务器存储介子中，实际上还是一张表。另外，分区可以做到将表的数据均衡到不同的地方，提高数据检索的效率，降低数据库的频繁IO压力值，分区的优缺点如下。

优点：

相对于单个文件系统或是硬盘，分区可以存储更多的数据；

数据管理比较方便，比如要清理或废弃某年的数据，就可以直接删除该日期的分区数据即可；

精准定位分区查询数据，不需要全表扫描查询，大大提高数据检索效率；

可跨多个分区磁盘查询，来提高查询的吞吐量；

在涉及聚合函数查询时，可以很容易进行数据的合并；

数据不存在多个副本，不必进行数据复制，性能更高。

缺点：分区策略必须经过充分考虑，避免多个分区之间的数据存在关联关系，每个分区都是单点，如果某个分区宕机，就会影响到系统的使用。

业务层分区是将大数据库分布到多个物理节点上的一个分区方案。每一个分区包含数据库的某一部分，称为一个shard，分区方式可以是任意的，并不局限于传统的水平分区和垂直分区。一个shard可以包含多个表的内容甚至可以包含多个数据库实例中的内容。每个shard被放置在一个数据库服务器上。一个数据库服务器可以处理一个或多个shard的数据。应用系统中需要进行查询路由转发，负责将查询转发到包含该查询所访问数据的shard或shards节点上去执行。

业务层分区包括分表、分库两种方式，分表把数据库当中数据根据按照分库原则分到多个数据表当中，就可以把大表变成多个小表，不同的分表中数据不重复，从而提高处理效率。分表和分区都是基于同一个数据库里的数据分离技巧，对数据库性能有一定提升，但是随着业务数据量的增加，原来所有的数据都是在一个数据库上的，网络IO及文件IO都集中在一个数据库上的，因此CPU、内存、文件IO、网络IO都可能会成为系统瓶颈。当业务系统的数据容量接近或超过单台服务器的容量、QPS/TPS接近或超过单个数据库实例的处理极限等此时，往往是采用垂直和水平结合的数据拆分方法，把数据服务和数据存储分布到多台数据库服务器上。分库只是一个通俗说法，更标准名称是数据分片，采用类似分布式数据库理论指导的方法实现，对应用程序达到数据服务的全透明和数据存储的全透明。

分库分表有两种方案：

同库分表：所有的分表都在一个数据库中，由于数据库中表名不能重复，因此需要把数据表名起成不同的名字。

优点：由于都在一个数据库中，公共表，不必进行复制，处理更简单。

缺点：由于还在一个数据库中，CPU、内存、文件IO、网络IO等瓶颈还是无法解决，只能降低单表中的数据记录数。表名不一致，会导后续的处理复杂。

不同库分表：由于分表在不同的数据库中，这个时候就可以使用同样的表名。

优点：CPU、内存、文件IO、网络IO等瓶颈可以得到有效解决，表名相同，处理起来相对简单。

缺点：公共表由于在所有的分表都要使用，因此要进行复制、同步。

应用层分表虽然解决了数据库性能扩展问题，但也带来了许多之前在单库的的不会存在的问题，如：跨库关联查询、分布式事务、全局主键避重、排序、翻页、函数计算问题。

数据库分区和业务层分区分别从两个层次提升了数据库访问性能，每种情况都有合适的应用场景，需要根据具体业务具体选择，两种方式并不冲突，也可配合使用。一般先进行数据库分区，若性能不满足应用场景，则进行业务层分区。常见的关系型数据库(如oracle、mysql)一般都支持数据库分区。

如图2所示，应用层分区可在不同层次切入。

编码层

在同一个项目中创建多个数据源，采用ifelse的方式，直接根据条件在代码中路由。Spring中有动态切换数据源的抽象类，具体参见AbstractRoutingDataSource。

如果项目不是很庞大，使用这种方式能够快速的进行分库。但缺点也是显而易见的，需要编写大量的代码，照顾到每个分支。当涉及跨库查询、聚合，需要循环计算结果并合并的场景，工作量巨大。

如果项目裂变，此类代码大多不能共用，大多通过拷贝共享。不推荐。

框架层，这种情况适合公司ORM框架统一的情况，但在很多情况下不太现实。主要是修改或增强现有ORM框架的功能，在SQL中增加一些自定义原语或者hint来实现。

通过实现一些拦截器，增加一些自定义解析来控制数据的流向，效果虽然较好，但会改变一些现有的编程经验。

驱动层，基于在编码层和框架层切入的各种缺点，真正的数据库中间件起码要从驱动层开始。其实就是重新编写了一个JDBC的驱动，在内存中维护一个路由列表，然后将请求转发到真正的数据库连接中。

像TDDL、ShardingJDBC等，都是在此层切入。包括Mysql Connector/J的Failover协议，也是直接在驱动上进行修改。

代理层的数据库中间件，将自己伪装成一个数据库，接受业务端的链接。然后负载业务端的请求，解析或者转发到真正的数据库中。像MySQL Router、MyCat等，都是在此层切入。请求流向一般是这样的：

实现层，SQL特殊版本支持，如Mysql cluster本身就支持各种特性，mariadbgalera cluster支持对等双主，Greenplum支持分片。需要换存储。

驱动层和代理层对比，通过以上层次描述，很明显，选择或开发中间件，就集中在驱动层和代理层。能够对数据库连接和路由进行更强的控制和更细致的管理。

有益效果：从性能方面来说，关系型数据库大多采用B+树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的IO次数增加，进而导致查询性能的下降；同时，高并发访问请求也使得集中式数据库成为系统的最大瓶颈。

以上的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种数据分库分表的方法，其特征在于，所述方法包括：

将数据分散到多个数据库；

突破单节点性能限制；

划分中间件的切入层次；

拆分的基本原则；

将数据分片、分布式事务和数据库治理。

2.根据权利要求1所述的一种数据分库分表的方法，其特征在于，所述将数据分散到多个数据库具体包括：

3.根据权利要求1所述的一种数据分库分表的方法，其特征在于，所述拆分的基本原则具体为原则零，能不分就不分，具体包括：优先垂直拆分、优先硬件升级和水平分片。

4.根据权利要求3所述的一种数据分库分表的方法，其特征在于，所述优先垂直拆分包括：垂直分库和垂直分表；

所述垂直分表为按照业务情况、使用评率的维度拆分；

5.根据权利要求3所述的一种数据分库分表的方法，其特征在于，所述水平分片包括：分库和分表两种方式，按照业务需求进行合理设计分片键，避免跨片区的事务和查询。