CN115114374B - 事务执行方法、装置、计算设备及存储介质 - Google Patents

Abstract

本申请公开了一种事务执行方法、装置、计算设备及存储介质，属于数据库技术领域。本申请通过在分布式数据库系统中预先定义将符合相似数据条件的数据记录尽可能存储在同一存储设备上，这样在涉及批量SQL操作的目标事务符合相似数据条件时能够确定一个目标存储设备，目标存储设备存储了目标事务涉及的所有数据记录，从而计算设备无需以2PC算法来协调目标事务，只需要将目标事务下推到目标存储设备，使得目标存储设备能够以单机事务的方式来执行目标事务，极大减少分布式数据库系统中需要以2PC算法协调的、涉及批量SQL操作的事务数量，简化了针对涉及批量SQL操作的事务的处理流程，提升了针对涉及批量SQL操作的事务的执行效率。

Description

事务执行方法、装置、计算设备及存储介质

技术领域

本申请涉及数据库技术领域，特别涉及一种事务执行方法、装置、计算设备及存储介质。

背景技术

随着互联网技术的发展，用户侧对数据库系统的要求越来越高，新的应用不仅要求数据库系统具有良好的ACID(原子性Atomicity、一致性Consistency、隔离性Isolation和持久性Durability)属性，还要求数据库系统具有良好的扩展性，因此，新一代的数据库系统NewSQL(Structured Query Language，结构化查询语言)应运而生。

比如，基于访问中间件的分库分表架构是一种典型的NewSQL数据库系统，通过分库分表的方式能够满足扩展性要求，数据库中间件会按照预设规则，将数据分散到多个数据库或数据表中进行存储，在查询阶段，中间件会将请求解析到多个数据库或数据表各自所在的节点设备上分别进行查询，再将多个数据库或数据表返回的查询结果聚合在一起返回至应用侧。

上述基于访问中间件的分库分表架构，在涉及到较为复杂的业务请求，特别是一些跨分区的操作时，由于要保证跨分区之间的数据强一致性，会导致整个业务请求的处理流程繁琐、事务执行效率低。

发明内容

本申请实施例提供了一种事务执行方法、装置、计算设备及存储介质，能够简化涉及批量SQL操作的事务的处理流程、提升分布式数据库系统的事务执行效率。该技术方案如下：

一方面，提供了一种事务执行方法，该方法包括：

针对涉及批量SQL操作的目标事务，确定所述批量SQL操作关联的多条数据记录；

在所述多条数据记录符合相似数据条件的情况下，确定所述多条数据记录所在的目标存储设备，所述目标存储设备用于存储符合所述相似数据条件的数据记录；

向所述目标存储设备下发所述目标事务，以使所述目标存储设备以单机事务的方式执行所述目标事务。

一方面，提供了一种事务执行装置，该装置包括：

第一确定模块，用于针对涉及批量SQL操作的目标事务，确定所述批量SQL操作关联的多条数据记录；

第二确定模块，用于在所述多条数据记录符合相似数据条件的情况下，确定所述多条数据记录所在的目标存储设备，所述目标存储设备用于存储符合所述相似数据条件的数据记录；

下发模块，用于向所述目标存储设备下发所述目标事务，以使所述目标存储设备以单机事务的方式执行所述目标事务。

在一种可能实施方式中，所述相似数据条件包括所述多条数据记录均属于热点数据，所述热点数据用于表征在历史时间段中被频繁访问的数据记录；

所述第二确定模块包括：

第一确定单元，用于在所述多条数据记录均属于所述热点数据的情况下，将用于存储所述热点数据的存储设备确定为所述目标存储设备。

在一种可能实施方式中，所述热点数据包括在所述历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的第一热点数据；

所述第一确定单元用于：

在所述多条数据记录均在所述历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的情况下，将所述多条数据记录均确定为所述第一热点数据，将用于存储所述第一热点数据的存储设备确定为所述目标存储设备。

在一种可能实施方式中，所述热点数据包括通过特征提取模型筛选得到的第二热点数据，所述特征提取模型用于针对在所述历史时间段内涉及批量SQL操作的历史事务所操作的数据记录提取数据特征，所述第二热点数据的数据特征与第一热点数据的数据特征符合相似条件，所述第一热点数据在所述历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值；

所述第一确定单元用于：

在通过所述特征提取模型对所述多条数据记录各自提取到的数据特征与所述第一热点数据的数据特征符合相似条件的情况下，将所述多条数据记录均确定为所述第二热点数据，将用于存储所述第二热点数据的存储设备确定为所述目标存储设备。

在一种可能实施方式中，所述相似数据条件包括所述多条数据记录各自的SQL操作语义符合语义关联条件；

所述第二确定模块包括：

第二确定单元，用于在所述多条数据记录各自的SQL操作语义符合所述语义关联条件的情况下，将用于存储符合所述语义关联条件的数据记录的存储设备确定为所述目标存储设备。

在一种可能实施方式中，所述第二确定单元还用于：

在所述多条数据记录仅包括同一数据表的主键记录和二级索引记录的情况下，确定所述多条数据记录各自的SQL操作语义符合所述语义关联条件；或，

在所述多条数据记录在历史时间段中被同一SQL查询事务进行批量SQL操作的频次大于频次阈值的情况下，确定所述多条数据记录各自的SQL操作语义符合所述语义关联条件；或，

在将所述多条数据记录转换到图数据库后，所述多条数据记录各自对应的多个节点中任意两个节点之间存在连接边且所述连接边的边长不超过边长阈值的情况下，确定所述多条数据记录各自的SQL操作语义符合所述语义关联条件。

在一种可能实施方式中，所述相似数据条件包括所述多条数据记录各自的主键均处于同一主键范围内；

所述第二确定模块还用于：

在所述多条数据记录各自的主键均处于同一主键范围内的情况下，将用于存储所述主键范围内的数据记录的存储设备确定为所述目标存储设备。

在一种可能实施方式中，所述装置还包括：

重新确定模块，用于每间隔目标时长，重新确定在所述目标时长内符合所述相似数据条件的数据记录；

第一迁移模块，用于将所述目标时长内符合所述相似数据条件的数据记录迁移至分布式数据库系统中计算负载小于负载阈值的存储设备中。

在一种可能实施方式中，所述第一迁移模块用于：

将所述目标时长内被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的第一热点数据，均迁移至计算负载小于负载阈值的第一存储设备；

将所述目标时长内通过特征提取模型筛选得到的第二热点数据，均迁移至计算负载小于负载阈值的第二存储设备，所述特征提取模型用于针对在所述目标时长内涉及批量SQL操作的历史事务所操作的数据记录提取数据特征，所述第二热点数据的数据特征与所述第一热点数据的数据特征符合相似条件；

将所述目标时长内SQL操作语义符合所述语义关联条件的至少一条数据记录，均迁移至计算负载小于负载阈值的第三存储设备。

在一种可能实施方式中，所述下发模块还用于：

基于所述目标事务所关联的业务类型，向所述目标存储设备发送与所述业务类型相匹配的主从切换指令，所述主从切换指令用于指示所述目标存储设备将所述多条数据记录中与所述业务类型适配度最高的副本切换为主副本，以在所述切换完毕的主副本上执行所述目标事务。

在一种可能实施方式中，在所述业务类型为OLAP业务的情况下，与所述OLAP业务适配度最高的副本为列存副本；或，在所述业务类型为OLTP业务的情况下，与所述OLTP业务适配度最高的副本为行存副本；或，在所述业务类型为OLTP业务且存在二进制日志订阅需求的情况下，与所述OLTP业务适配度最高的副本为携带二进制日志生成功能的副本。

在一种可能实施方式中，所述装置还包括：

筛选模块，用于从多个历史事务中筛选得到至少一个待优化事务，所述待优化事务指未以单机事务的方式执行的历史事务；

生成模块，用于基于所述至少一个待优化事务，生成多个迁移策略信息，所述迁移策略信息用于指示如何对所述待优化事务涉及操作的数据记录进行重分布；

第三确定模块，用于从所述多个迁移策略信息中，确定执行代价最小的目标策略信息；

第二迁移模块，用于基于所述目标策略信息，在分布式数据库系统中，对所述至少一个待优化事务涉及操作的数据记录进行数据迁移。

在一种可能实施方式中，所述迁移策略信息为数据分布图，所述数据分布图用于指示将所述待优化事务涉及操作的数据记录从原存储设备迁移至新存储设备的数据流向；

所述生成模块用于：

基于所述至少一个待优化事务，生成多个不存在冲突的数据分布图，所述不存在冲突的数据分布图是指不存在将同一数据记录从原存储设备迁移至多个新存储设备。

在一种可能实施方式中，对任一迁移策略信息，所述迁移策略信息的执行代价基于所述迁移策略信息的存储代价、通信代价或者负载代价中的至少一项确定得到，所述存储代价表征将所述待优化事务涉及操作的数据记录以当前存储格式存储时带来的存储开销，所述通信代价表征将所述待优化事务涉及操作的数据记录从原存储设备迁移至新存储设备的过程中造成的通信开销，所述负载代价表征将所述待优化事务涉及操作的数据记录迁移至新存储设备后对新存储设备所带来的负载情况。

一方面，提供了一种计算设备，该计算设备包括一个或多个处理器和一个或多个存储器，该一个或多个存储器中存储有至少一条计算机程序，该至少一条计算机程序由该一个或多个处理器加载并执行以实现如上述事务执行方法。

一方面，提供了一种存储介质，该存储介质中存储有至少一条计算机程序，该至少一条计算机程序由处理器加载并执行以实现如上述事务执行方法。

一方面，提供一种计算机程序产品或计算机程序，所述计算机程序产品或所述计算机程序包括一条或多条程序代码，所述一条或多条程序代码存储在计算机可读存储介质中。计算设备的一个或多个处理器能够从计算机可读存储介质中读取所述一条或多条程序代码，所述一个或多个处理器执行所述一条或多条程序代码，使得计算设备能够执行上述事务执行方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

通过在分布式数据库系统中预先定义将符合相似数据条件的数据记录尽可能存储在同一存储设备上，这样针对涉及批量SQL操作的目标事务，先判断涉及的多条数据记录是否符合相似数据条件，在符合相似数据条件时能够确定得到一个目标存储设备，这一目标存储设备存储了目标事务涉及的所有数据记录，从而计算设备无需以2PC算法来协调目标事务，只需要将目标事务下推到目标存储设备，使得目标存储设备能够以单机事务的方式来执行目标事务，由于涉及批量SQL操作的事务通常都会涉及多个数据分区或跨越多个存储设备，通过将符合相似数据条件的数据记录整合在同一存储设备，能够极大减少分布式数据库系统中需要以2PC算法协调的、涉及批量SQL操作的事务数量，从而极大降低了分布式数据库系统中处理涉及批量SQL操作的事务时的通信开销，简化了针对涉及批量SQL操作的事务的处理流程，提升了针对涉及批量SQL操作的事务的执行效率。

附图说明

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

图1是本申请实施例提供的一种事务执行方法的实施环境示意图；

图2是本申请实施例提供的基于智能感知存储体系的分布式数据库的逻辑架构图；

图3是本申请实施例提供的一种事务执行方法的流程图；

图4是本申请实施例涉及的一种分布式系统中涉及批量SQL操作的事务的处理流程示意图；

图5是本申请实施例提供的一种存储设备存放策略的对比示意图；

图6是本申请实施例提供的一种基于数据亲和性的批量SQL操作的事务的处理流程的原理性示意图；

图7是本申请实施例提供的一种两阶段提交和一阶段提交的对比示意图；

图8是本申请实施例提供的一种事务执行方法的流程图；

图9是本申请实施例提供的一种数据亲和性在分布式事务中应用方式的示意图；

图10是本申请实施例提供的一种全局负载自动优化策略的原理性流程图；

图11是本申请实施例提供的一种事务执行装置的结构示意图；

图12是本申请实施例提供的一种计算设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”、“第n”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。

本申请中术语“至少一个”是指一个或多个，“多个”的含义是指两个或两个以上，例如，多个存储设备是指两个或两个以上的存储设备。

本申请中术语“包括A或B中至少一项”涉及如下几种情况：仅包括A，仅包括B，以及包括A和B两者。

本申请中涉及到的用户相关的信息(包括但不限于用户的设备信息、个人信息、行为信息等)、数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)以及信号，当以本申请实施例的方法运用到具体产品或技术中时，均为经过用户许可、同意、授权或者经过各方充分授权的，且相关信息、数据以及信号的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。例如，本申请中涉及到的任一业务相关的数据记录都是在充分授权的情况下获取的。

在介绍本申请实施例之前，需要引入一些云技术领域内的基本概念：

云技术(Cloud Technology)：是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术，也即是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成云技术领域的重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，均能通过云计算来实现。

云计算(Cloud Computing)：云计算是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。

作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS，即Infrastructure as a Service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。

按照逻辑功能划分，在IaaS层上可以部署PaaS(Platform as a Service，平台即服务)层，PaaS层之上再部署SaaS(Software as a Service，软件即服务)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、Web(网页)容器等。SaaS为各式各样的业务软件，如Web门户网站、短信群发器等。一般来说，SaaS和PaaS相对于IaaS是上层。

云存储(Cloud Storage)：是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

云原生：云原生是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps(Development和Operations的组合词，过程、方法与系统的统称)等技术为基础建立的一套云技术产品体系。在使用云原生技术后，开发者无需考虑底层的技术实现，可以充分发挥云平台的弹性和分布式优势，实现快速部署、按需伸缩、不停机交付等。云原生技术为存算分离提供了可靠的底层技术保障。

数据库(Database)：简而言之可视为一种电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

以下，对本申请实施例的术语进行解释说明。

分布式数据库：分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都可能有数据库管理系统的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。

事务(Transaction)：事务是数据库管理系统在执行操作的过程中的一个逻辑单位，由一个有限的数据库操作序列构成，是数据库系统操作的最小执行单位。在一个系统的内部，每个操作系列的单位，称为一个事务，单个操作也可以称为一个事务。

数据库操作：一个数据库操作由操作类型、事务、变量版本三部分构成，即是指事务对哪个版本的变量执行何种类型的数据库操作，在本申请实施例中也被简称为“操作”，其中，操作类型包括读(Read)和写(Write)两种，而变量是数据库操作的作用者(或者说操作对象)。在MVCC(Multi-Version Concurrency Control，多版本并发控制)数据库中，一个变量可以包含若干变量版本(也称为版本)，每当事务对变量进行更新时，则会添加新的变量版本，变量的各个变量版本通常以自然数作为版本号标识，版本号越大，则表示变量版本越新。

两阶段提交(Two-Phase Commit，2PC)：也称为二阶段提交，指分布式系统中，为了保证所有的节点在进行事务提交时保持一致性的一种算法，通常也被称为2PC协议。在分布式系统中，涉及到一类跨节点操作的分布式事务，每个节点虽然可以知晓自己的数据库操作是成功还是失败，却无法知道其他节点的数据库操作是成功还是失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者(Coordinator)的组件来统一掌控所有参与者(Participant)的操作结果，并最终指示这些参与者是否要把操作结果进行真正的提交(Commit)或回滚(Rollback)。其中，ACID是指数据库管理系统在写入或更新资料的过程中，为保证事务是正确可靠的所必须具备的四个特性：原子性(Atomicity，或称不可分割性)、一致性(Consistency)、隔离性(Isolation，又称独立性)、持久性(Durability)。

Raft算法：也称为Raft协议，是由斯坦福大学的Diego Ongaro等提出的一种用于替代Paxos的共识算法，也是一种基于主从模型、保证强一致性的一致性算法，目前逐渐在分布式系统领域中成为主流的一致性算法之一。Raft算法基于主从模式来管理复制日志(Replicated Log)，在每一轮任期中会选举一个节点作为领导者(Leader，主副本)，其余节点则作为跟随者(Follower，从副本)，只有主副本能够响应外部的请求，并执行相应的事务，从副本仅做数据同步或备份工作。相较于Paxos算法来说，Raft算法的目标是提供更加清晰的逻辑分工，使得Raft算法具有非常易于理解和开发实现的特点，同时，Raft算法的安全性还非常高，并且能够提供一些额外的保障，能够为在计算机集群之间部署的有限状态机提供一种通用的方法，并确保集群内的任意节点在某种状态转换上保持一致。

随着互联网技术的发展，用户侧对数据库系统的要求越来越高，新的应用不仅要求数据库系统具有良好的ACID属性，还要求数据库系统具有良好的扩展性，因此，新一代的数据库系统NewSQL应运而生，业界的NewSQL数据库系统包括基于访问中间件的分库分表架构，以及基于云原生的数据库系统，下面将分别进行说明。

(1)基于访问中间件的分库分表架构

传统的关系型数据库天然具备良好的ACID属性，而基于访问中间件的分库分表架构，则通过对数据库分库分表的方式，来满足扩展性的要求，通常，数据库中间件会按照预设规则，将数据分散到多个数据库或数据表中进行存储。应用侧在查询阶段要访问数据库系统时，先访问数据库中间件，再将多个数据库或数据表中查询到的数据聚合在一起，返回给应用侧。分库分表架构下的数据库系统本质上采用的是传统关系型数据库，常用有存储结构化数据，适用于OLTP(Online Transaction Processing，事务联机处理)应用场景。

目前，数据库中间件包括：MyCat、Mango、Cobar和Altas等。以Cobar数据库中间件为例进行说明，Cobar是一种关系型数据的分布式处理系统，Cobar系统成功替代了原先基于Oracle的数据存储方案。Cobar系统的分布式方案是分库和分表，例如，可以按照业务需求将数据库中耦合度较低的数据表分到不同的分库中，又例如，也可以按照具体数据表的增长速度和数据量水平切分到不同的分库中。Cobar系统能够实现应用层与物理分库的双向透明，从而实现应用访问分布式数据库与访问单库无差别。Cobar系统还可以配合MySQL数据库的心跳机制和binlog(二进制日志)实现备机的自动切换，保证数据节点的可靠性，从而实现高可用性。

针对上述基于访问中间件的分库分表架构，突出优点是简单，在所欲执行的任务涉及的SQL操作比较简单的情况下，比如说写入或者读取基本上都能退化成在一个数据分区上完成的任务，在应用层进行充分适配之后，系统延迟是比较低的，并且在整体而言，如果负载是随机的，那么业务的TPS(Transaction Per Second，每秒处理的事务数，也称为吞吐量)也能够做线性扩展。但分库分表架构的缺点也十分明显，对于一些比较复杂的业务，例如涉及到跨分区的SQL操作(查询或写入)，为了保证数据分片之间的数据强一致性，需要使用2PC算法来进行全局提交，2PC算法必然要经过多轮通信，会导致整个业务请求的处理流程繁琐、事务执行效率低。此外，分库分表架构对于大集群的运维也是比较困难的，在做一些类似表结构变更的DDL(Data Definition Language，数据定义语言)操作时，整体的事务执行效率也很低。

(2)基于云原生的数据库系统

基于云原生的数据库系统无需进行分库分表，而是在云原生技术上重新构建数据库系统，采用了分布式部署和分布式存储引擎，如Aurora、PolarDB、CynosDB都是OLTP场景下的云原生数据库。由于数据库内部支持分布式事务处理与数据切分，因此事务处理性能高于分库分表架构，且对应用完全透明，使用者无需感知底层数据分布。此外，数据库内部原生具备数据的高可用性和容灾能力。基于云原生的分布式数据库系统适用于OLTP和OLAP(Online Analytical Processing，联机分析处理)的应用场景。

目前，分布式数据库系统主要基于三种结构：Shared-Nothing(无共享结构)，Shared-Disk(磁盘共享结构)和Shared-Everything(全共享结构)。无共享结构指的是数据库系统内的各个节点设备都有自己私有的CPU(Central Processing Unit，中央处理器)/内存/硬盘等，不存在共享资源，各个节点设备之间通过协议通信，其并行处理以及扩展能力较好，换言之，各个节点设备之间相互独立，各自处理各自的数据，再将处理后的数据向上层汇报或者是节点间流转，因此，无共享结构中每一个节点设备都是自给的，整个数据库系统中不存在单点竞争。磁盘共享结构指的是数据库系统内的各个节点设备使用自己的私有CPU和内存，但不同节点设备之间共享磁盘系统。全共享结构指的是数据库系统内的各个节点设备之间完全透明共享CPU、内存以及IO(Input/Output，输入/输出)，整个数据库系统的并行能力较差。

例如，AWS(Amazon Web Services，亚马逊云科技)提出的Aurora是一种典型的磁盘共享结构的云原生数据库，由于在存储层实现了磁盘共享，从而解决了一致性问题，且上层的MySQL集群实例本身无状态，能够实现一写多读，底层存储架构在共享存储上。每个Aurora配备六个存储设备，其中两个存储设备使用Amazon Simple Storage Service(亚马逊简单存储设备，S3)存储技术进行备份，而剩余四个存储设备则直接存储在本地的SSD(Solid State Disk，固态硬盘)上。Aurora的数据模型跟MySQL一样是基于Page(数据页)的模型，总的来讲，Aurora是一个基于共享存储的优化的RDS(Relational DatabaseService，关系型数据库服务)。Aurora的优点是完全兼容MySQL，保留了MySQL事务语义，可以通过机器一定程度上进行扩容(scaleup)。但是Aurora的扩展性比较差，一方面由于一写多读机制，即只有读节点能够扩展，但写节点的内存和CPU只能是一台机器(写节点不可扩展)，因此受限于写节点的CPU以及内存大小，扩展性比较差，另一方面，只有写节点才能够写入重做日志(Redo Log)，而重做日志的写入又必须是顺序的(串行的)，因此串行写入的最大速度限制了Aurora的写入速度，也会导致扩展性比较差。

又例如，Google公司提出的Spanner是一种典型的基于无共享结构的云原生数据库，Spanner的优点为整个数据库系统几乎无限水平扩展，整个数据库系统没有性能瓶颈，业务层不需要担心扩展能力。其次，Spanner的系统架构设计的目标就是提供强SQL支持，需要指定分片规则、分片策略，系统会自动扩展。最后，Spanner支持事务的强一致性，因此可用于支持金融级别的业务。

又例如，TiDB是另一种典型的基于无共享结构的云原生数据库，TIDB是PingCAP公司自主设计、研发的开源分布式关系型数据库，适用于高可用、强一致性要求、数据规模较大的各种应用场景。TiDB主要涉及三个模块，包括TiDB服务器、PD(Placement Driver，位置驱动)服务器以及存储集群，其中存储集群包括TiKV节点设备以及TiFLash节点设备。TiDB服务器负责接收用户侧客户端的链接，相当于一个网关或代理模块，能够针对客户端发起的业务请求，执行SQL的解析并在生成执行结果之后，向客户端返回最后的执行结果。PD服务器为整个分布式集群的元信息管理模块，负责存储每个TiKV节点实时的数据分布情况以及整体的拓扑结构。TiKV节点设备负责数据存储，TiKV节点设备采取基于Key-Value(键-值)的数据管理模式，为了提升读写效率，通常会以block(数据块)模式来组织一定数量的Key-Value对(键值对)，在TiDB中，为了做到存储能够水平扩展，引入了region(域)的定义，region可以认为是一种一个或多个物理block的逻辑映射，通过增加逻辑映射能够屏蔽掉region对应的数据真实存储的位置。region或者block是有一定数据范围的，每个region或block都负责存储某个主键范围(KeyRange)内的所有数据记录。TiFLash节点设备的主要功能为分析型的场景加速，TiDB采用Raft算法来保持副本间的数据一致性，也提供了容灾能力。Raft算法涉及的每个副本都以region作为基本单元来进行数据管理，在不同TiKV节点设备上的多个region构成了一个RaftGroup(基于Raft算法的副本组，包括一个主副本和至少一个从副本，主从副本之间可以通过选举的方式来自主切换)。此外，数据记录在多个TiKV节点设备上的负载均衡，也是以region为单位来进行的，负载均衡由PD服务器来进行调度。

上述以Spanner和TiDB为代表产品的基于无共享结构的云原生数据库，由于当前架构是分布式架构，使得很多行为无法与单机数据库一样，例如单机数据库在做事务交易时很快就提交完成了，但在分布式数据库上为实现相同的语义，这个事务需要操作的数据记录可能分布在不同的机器上，需要以2PC算法来进行全局提交，这样会涉及多次网络通信以及交互，速度和性能都比单机数据库会有降低，因此会存在较高延迟。

有鉴于此，本申请实施例涉及一种基于无共享结构搭建的分布式数据库系统，一方面提出数据亲和性，通过将经常访问的热点数据尽可能存放在存储引擎的相同位置，使得计算引擎在发现SQL操作的数据记录都在同一个存储设备的情况下，能够根据数据记录存放的位置，将对应事务下推到存储设备来以单机事务的方式来执行并提交，不仅能够适用于不同的业务场景，而且能够尽可能地减少分布式系统中的RPC(Remote ProcedureCall，远程过程调用)调用和跨网络数据的访问，从而提升其分布式数据库的整体性能；另一方面提出全局自动负载优化策略，通过统计历史事务的查询(Query)项，结合数据记录的存储位置，可以选取前N个(top N，N为大于或等于1的整数)可用于优化的查询项来生成数据分布图，并使用优化器来利用一定规则计算不同数据分布图的代价(Cost)，从而选取代价最低的数据分布图来构建迁移策略，以实现全局的负载均衡。

下面，将对本申请实施例能够适用的不同业务场景来进行介绍。

其一，OLTP业务场景，OLTP业务以小的事务(指单次修改的数据量较少)以及小的查询(指单次查询的数据量较少)为主，OLTP业务对于一致性的要求比较高，主要针对更新(Update)操作进行优化，在对外提供查询功能时则主要依赖索引结构来进行查询，每次查询涉及的数据量都比较少，并且，OLTP业务对于事务的时效性要求较高，在存储层中一般使用行存方式来存储数据。进一步的，支持OLTP业务的数据库系统也称为OLTP系统，OLTP系统表示事务性非常高的系统，一般都是高可用的在线系统，在评估OLTP系统的性能时，一般会选取每秒执行的交易或每秒执行的SQL操作的数量。

其二，OLAP业务场景，OLAP业务是在基于数据仓库多维型的基础上实现的面向分析的各类操作的集合。对于OLAP业务来讲，针对的是Ad-Hoc(点对点)查询进行优化，Schema(数据库对象的集合)一般采用星型模型，星型模型是多维的数据关系，由事实表和维表组成。OLAP业务对于事务的时效性要求通常没有OLTP业务那么高，但对于查询的性能要求往往会比较高，每次查询的数据量也通常比较大，并且查询过程中通常需要多表Join(指将数据库中多个数据表关联在一起后进行相关SQL操作)，在存储层中一般使用列存方式来存储数据。

其三，NoSQL(Not Only SQL，非关系型数据库)业务场景，NoSQL是对不同于传统的关系型数据库的数据库管理系统的统称。NoSQL用于超大规模数据的存储，这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。可选地，NoSQL数据库可以分为以下四类：键值数据库、列族数据库、文档数据库和图数据库。

键值数据库：主要用在所有数据记录都通过主键来访问的情况下。在键值数据库中，Key(键名)用来定位Value(键值)，通常，Value对于键值数据库而言是不可见的，在这种情况下不能对Value进行索引和查询，只能对Key进行查询，但也有部分键值数据库支持二级索引，这种情况下也支持对Value进行索引和查询。此外，Value可以存放任意类型的数据。键值数据库比较适合存在大量写操作的业务场景，键值数据库具有良好的伸缩性，理论上可以通过横向扩展实现无限扩容，但是键值数据库不支持回滚操作，所以无法支持涉及增删改操作的事务。

列族数据库：一般用列族数据模型，列族数据库由多个数据行构成，每行数据包含多个列族，不同的数据行可以具有不同数量的列族，属于同一列族的数据会存放在一起。列族数据库主要适合于批量数据处理，因为列族数据库能够降低IO开销，且支持大量用户并发查询。

文档数据库：一种非关系数据库，旨在将数据作为类JSON(JavaScript ObjectNotation，JS对象简谱)文档存储和查询。一个文档就是文档型数据库中的一条数据记录，每个文档通常存储关于一个数据对象及其任何相关元数据的信息。通常，文档是以字段-值成对的形式来存储数据，值的类型和结构可以有多种，包括字符串、数字、日期、数组等。另外，文档数据库中文档存储的格式可以包括JSON、BSON(Binary JSON，二进制形式的JSON)、XML(Extensible Markup Language，可扩展标记语言)等。

图数据库：用来表示一个对象的集合，包括顶点以及连接顶点的边。图数据库专门使用图作为存储模型来存储数据，采取完全不同于键值数据库、列族数据库和文档数据库的数据模型，图数据库可以高效存储不同顶点之间的关系，比较适用于社交网络、模式识别、以及路径寻找等业务场景。

NoSQL一般采用KV(Key-Value，键值对)接口，对于一致性要求相比于OLTP没有那么高，一般的只要求单行事务，但是NoSQL针对整个集群的吞吐量要求高。图数据库是区别于关系型的另外一种模型，在多跳关系查询业务中，性能要远超关系模型，但是在存储模型上，图数据库可以使用KV作为存储模型，而在更新数据的时候，对于数据的一致性要求较高。文档数据库对于KV接口来讲，每一个Value都有来自解释的Schema，相对于SQL来讲，每一个Key Value的Schema都可以解释。

在上述针对OLTP、OLAP、NoSQL的相关概念的解释说明的基础上，能够看出来不同的业务场景各自对于数据库系统的要求有不同的侧重点，比如OLTP业务要求高一致性，常使用行存格式，OLAP业务要求查询性能，常使用列存格式，NoSQL要求高吞吐量，包括键值数据库、列族数据库、文档数据库和图数据库等非关系型数据库。

而本申请实施例提供的基于无共享结构搭建的分布式数据库系统，能够针对不同的业务场景，利用不同存储格式的多副本来满足不同业务对于性能、成本以及可靠性的要求，从而能够为用户平衡分布式、性能以及成本需求，下面将结合系统架构来进行详细说明。

图1是本申请实施例提供的一种事务执行方法的实施环境示意图。参见图1，本申请实施例涉及的基于无共享结构搭建的分布式数据库系统中，包括网关服务器101、元信息管理服务器102以及分布式存储集群103。

网关服务器101负责接收用户侧客户端的链接，相当于一个网关或代理模块，能够针对客户端发起的业务请求，执行SQL的解析并在生成执行结果之后，向客户端返回最后的执行结果。

比如，用户在登录终端上的应用客户端之后，触发应用客户端生成业务请求，调用分布式数据库系统提供的API(Application Programming Interface，应用程序编程接口)将该业务请求发送至网关服务器101。

可选地，用户侧使用的终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、智能语音交互设备、智能家电、车载终端等，但并不局限于此。

元信息管理服务器102负责为整个分布式集群的元信息管理模块，负责存储每个TiKV节点实时的数据分布情况以及整体的拓扑结构。

在一些实施例中，该元信息管理服务器102可以与网关服务器101合并在同一个物理机上，也即是，让元信息管理服务器102充当网关服务器101。

分布式存储集群103包括KV存储设备和加速存储设备。其中，KV存储设备负责存储数据记录，采取基于Key-Value的数据管理模式，为了提升读写效率，通常会以region模式来组织一定数量的Key-Value对，region是有一定数据范围的，每个region都负责存储某个主键范围(KeyRange)内的所有数据记录。其中，加速存储设备的主要功能是为分析型的相关业务场景(如OLAP业务)提供加速。

在分布式存储集群103中，基于多副本机制来保证存储集群的高可用性，可选地，本申请实施例在分布式存储集群103中，对每条数据记录，都提供异构的存储副本，换言之，每条数据记录可以以不同存储格式来存储副本，比如，对某条Recard 1，分别以行存格式、列存格式、二进制日志等格式来存储副本，这样不仅能够通过多副本机制来保证高可靠性，而且还能够通过异构副本来支持不同类型的业务场景。

在分布式存储集群103中，采用Raft算法来保持副本间的数据一致性，也提供了容灾能力。Raft算法涉及的每个副本都以region作为基本单元来进行数据管理，在不同KV存储设备上的多个region构成了一个RaftGroup，RaftGroup是指基于Raft算法的副本组，包括一个主副本和至少一个从副本，主从副本之间可以通过选举的方式来自主切换。此外，数据记录在多个TiKV节点设备上的负载均衡，也是以region为单位来进行的，负载均衡由元信息管理服务器102来进行调度。分布式存储集群103可以进行线性扩容，以应付大数据场景下的业务处理需求。

示意性地，每个副本组中包括一个主副本和多个从副本，如图1所示，以副本组中包括一个主副本和两个从副本为例进行示意，主副本所在存储设备可称为主机，从副本所在存储设备可称为备机，每个主机或备机都对应配置有代理(Agent)设备，代理设备可以与主机或备机是物理独立的，当然，代理设备还可以作为主机或备机上的一个代理模块，以副本组1为例，副本组1包括一个主数据库及代理设备(主Database+agent，简称主DB+agent)，此外还包括两备数据库及代理设备(备Database+agent，简称备DB+agent)。

在一些实施例中，上述网关服务器101、元信息管理服务器102以及分布式存储集群103所构成的分布式数据库系统，可以视为一种向用户终端提供数据服务的服务器，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。

用户侧使用的终端以及上述服务器可以通过有线或无线通信方式进行直接或间接地连接，且本申请可应用于各种场景，包括但不限于云技术、人工智能、智慧交通、辅助驾驶等，本申请在此不做限制。

在一些实施例中，本申请实施例涉及的分布式数据库系统可采用区块链架构，区块链系统在本质上是去中心化式的分布式数据库系统，采用共识算法保持区块链上不同节点设备所记载的账本数据一致，通过密码算法保证不同节点设备之间账本数据的加密传送以及不可篡改，通过脚本系统来拓展账本功能，通过网络路由来进行不同节点设备之间的相互连接。区块链系统中包括一条或多条区块链，区块链是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。

下面，将在上述实施环境的基础上，对基于无共享结构搭建的分布式数据库系统的逻辑架构进行说明，上述基于无共享结构搭建的分布式数据库系统，也称为基于智能感知存储体系的分布式数据库。

图2是本申请实施例提供的基于智能感知存储体系的分布式数据库的逻辑架构图，如图2所示，在基于智能感知存储体系的分布式数据库200中，包括计算集群201和存储集群202，计算集群201由计算引擎驱动，存储集群202由分布式异构存储引擎驱动。

在计算集群201中，通常包括多个计算设备，这些计算设备构成分布式的计算集群，计算设备上由计算引擎来实现事务解析和SQL操作。可选地，对计算引擎来说，以KV接口2011为基础，封装出SQL接口2012、Graph(图数据库)接口2013、Document(文件)接口2014、优化器/执行器接口2015、事务算法接口2016等其他接口。需要说明的是，KV接口2011不是指所有数据记录的访问都以KV接口2011来访问，KV接口2011只是切分数据的标准，在访问数据记录时仍然可以按照不同的接口，来将相关事务下推到存储集群202来执行并提交(或者回滚)，并且，不同副本也可以根据KV操作以及元数据来生成不同的存储格式。

在存储集群202中，通常包括多个存储设备，这些存储设备构成分布式的存储集群，存储设备上由分布式异构存储引擎来实现不同存储格式的副本存储和副本同步，可选地，对同一份数据记录来说，通过控制同一份数据记录的不同副本所在存储设备的物理位置，能够在满足性能成本的同时，保证同一份数据记录的不同副本可以跨节点、跨机架、跨IDC(Internet Data Center，互联网数据中心)或者跨区域，以实现副本位置自适应。

对分布式异构存储引擎来说，需要通过多副本机制来保证存储集群202的可靠性，比如，在同一副本组中基于Raft算法来实现主从副本之间的数据同步，这时的副本组也称为RaftGroup，副本组中包括一个主副本和至少一个从副本，主副本和从副本可以具有不同的存储格式(即异构副本)。示意性地，副本组内包括行存引擎副本、列存引擎副本、压缩引擎(Compressed Engine)副本、二进制日志生成器(Binlog Generator)等，同一数据记录的不同副本能够应用到不同存储引擎，通过在不同存储引擎之间同步KV操作来保证副本一致，这样能够针对不同的业务场景，来利用不同存储格式的副本来满足不同业务对于性能、成本以及可靠性的需求，例如，对于OLTP业务则使用行存引擎副本作为主副本来提供服务，对于OLAP业务则使用列存引擎副本作为主副本来提供服务。

进一步的，本申请实施例还提出了细粒度的数据划分和数据亲和性感知，当前架构以Key-Value为基础，将数据按照Key-Value进行了细粒度的切分，这样数据能够自动根据负载和数据量来进行分裂、迁移，并且，还能够根据不同的应用场景来选择不同的数据形态，从而提供了同一数据记录在不同数据形态上切换的基础。

在基于智能感知存储体系的分布式数据库200中，基于无共享架构搭建分布式数据库系统，使得整个系统可以进行水平扩展，保证了系统的良好扩展性。并且，系统内的每个节点设备(如计算设备或存储设备)都同时会具备存储以及计算能力，都能够全局的看到KV元数据以及Schema元数据，每个节点设备都能够承担任何类型的计算以及存储任何形态的数据，因此系统内的节点设备是多元形态的，需要说明的是，这并不代表基于智能感知存储体系的分布式数据库200不能实现存算分离，只是在保证存算分离的基础上，提供了多元形态的节点设备，即每个节点设备都具有计算和存储功能，并且任何一个节点设备都能够远程访问其他节点设备中的数据记录。

以下，将针对上述基于智能感知存储体系的分布式数据库，介绍其事务执行流程。

图3是本申请实施例提供的一种事务执行方法的流程图。参见图3，该实施例由基于无共享结构搭建的分布式数据库系统中的计算设备执行，该实施例包括下述步骤：

301、针对涉及批量结构化查询语言SQL操作的目标事务，计算设备确定该批量SQL操作关联的多条数据记录。

本申请实施例涉及的计算设备，是指上述基于智能感知存储体系的分布式数据库中计算集群中的任一由计算引擎驱动的节点设备，计算设备负责判断路由到本节点的目标事务是否符合相似数据条件，在该目标事务操作的多条数据记录符合相似数据条件的情况下，将目标事务下推到下述步骤302中确定的目标存储设备来执行目标事务，在该目标事务操作的多条数据记录不符合相似数据条件的情况下，则由计算设备担任2PC算法中的协调者，来负责对目标事务涉及的各个参与者(即目标事务涉及SQL操作的数据记录所在的各个存储设备)进行事务协调。

本申请实施例涉及的目标事务，是基于外部的业务请求进行SQL解析得到的涉及批量SQL操作的事务，例如，业务请求可以是批量查询请求、批量交易(增删改)请求等，以批量查询请求为例，在金融场景下，该查询请求为查询当月流水等，在智慧交通场景下，该查询请求为查询附近空闲停车位等，本申请实施例不对业务请求的内容进行具体限定。

在一些实施例中，业务请求是由用户通过终端上的应用客户端向分布式数据库系统发送的请求，示意性地，用户在终端上登录应用客户端，触发应用客户端生成该业务请求，调用分布式数据库系统提供的API，将该业务请求发送至分布式数据库系统。

在一些实施例中，计算设备直接接收应用客户端通过API发送的业务请求，对该业务请求进行SQL解析，得到目标事务的SQL语句。

在一些实施例中，计算设备接收网关服务器转发的业务请求，网关服务器作为计算集群和应用客户端之间的中转，比如，网关服务器将新到的业务请求随机地转发到计算集群中的任一计算设备，或者，网关服务器将业务请求优先转发到计算集群中当前负载较低的计算设备，以更好地实现负载均衡。计算设备接收到网关服务器转发的业务请求之后，对该业务请求进行SQL解析，得到目标事务的SQL语句。

在一些实施例中，计算设备接收网关服务器转发的目标事务的SQL语句，即，网关服务器在接收到业务请求之后，先对该业务请求进行SQL解析，得到目标事务的SQL语句，再将目标事务的SQL语句转发到计算设备(可以是随机转发，或者优先向负载较低的计算设备转发)，本申请实施例对此不进行具体限定。

在本申请实施例中，仅关注在SQL语句中涉及到批量SQL操作的目标事务，换言之，在对业务请求解析得到目标事务的SQL语句之后，若该SQL语句中涉及对多条数据记录执行批量SQL操作，此时，先确定该批量SQL操作涉及的多条数据记录，这里的数据记录存储了数据表的定义中所有数据列的实例化信息(指每个数据列对应的字段数据)，这里的SQL操作是指数据库操作，包括读操作和写操作。

通常，目标事务的SQL语句是一个SQL操作序列，SQL操作序列中的不同SQL操作可能指向相同或者不同的数据记录，而在分布式数据库系统中，目标事务的批量SQL操作涉及的多条数据记录，可能位于相同或者不同的存储设备上，在基于智能感知存储体系的分布式数据库中，由于会将数据记录按照KV进行划分，分成多个连续的逻辑区间(即主键范围)，不同区间的KV数据会存在存储集群的多个存储设备上，此外，还保证将符合相似数据条件的数据记录尽量存储在同一存储设备上，因此可以通过判断目标事务操作的多条数据记录是否符合相似数据条件，从而来确定该多条数据记录是否位于同一存储设备上，这样能够确定出来目标事务是否能够以单机事务的方式来执行。

302、在该多条数据记录符合相似数据条件的情况下，计算设备确定该多条数据记录所在的目标存储设备，该目标存储设备用于存储符合该相似数据条件的数据记录。

在一些实施例中，计算设备针对上述步骤301确定得到的多条数据记录，判断该多条数据记录是否符合相似数据条件，可选地，该相似数据条件包括下述至少一项：该多条数据记录各自的主键均处于同一主键范围内；或，该多条数据记录均属于热点数据，该热点数据用于表征在历史时间段中被频繁访问的数据记录；或，该多条数据记录各自的SQL操作语义符合语义关联条件。

在该相似数据条件包括该多条数据记录各自的主键均处于同一主键范围内的情况下时，此时分布式数据库系统会将不同主键范围的数据记录存放在不同的存储设备上，比如，将主键范围为1-500的数据记录存放在Node 1上，将主键范围为501-1000的数据记录存放在Node 2上，将主键范围为1001-1500的数据记录存放在Node 3上，若计算设备检测到该多条数据记录各自的主键均处于同一主键范围内，则将用于存放该主键范围内数据记录的存储设备确定为目标存储设备，比如，若检测到该多条数据记录的主键范围均位于1-500，则将Node1确定为目标存储设备。

在该相似数据条件包括该多条数据记录均属于热点数据的情况下，此时分布式数据库系统会将热点数据存放在同一存储设备上，比如，将热点数据都存放在当前系统内负载较低的Node 10上，若计算设备检测到该多条数据记录均属于热点数据，则将用于存储热点数据的存储设备确定为目标存储设备，比如，若检测到该多条数据记录均属于热点数据，则将Node 10确定为目标存储设备。

在一些实施例中，热点数据可进一步划分成第一热点数据和第二热点数据，第一热点数据是指根据历史时间段中被访问次数或被修改次数统计得到的热点数据，第二热点数据则是根据机器学习模型提取到的数据特征与第一热点数据的数据特征符合相似条件的热点数据，这时可以将第一热点数据存储在一个存储设备上，将第二热点数据存储在另一个存储设备上，比如，将第一热点数据存储在Node 1上，将第二热点数据存储在Node 2上，这时，若计算设备检测到该多条数据记录均属于第一热点数据，则将用于存放第一热点数据的存储设备确定为目标存储设备，比如，若检测到该多条数据记录均属于第一热点数据，则将Node 1确定为目标存储设备；若计算设备检测到该多条数据记录属于第二热点数据，则将用于存放第二热点数据的存储设备确定为目标存储设备，比如，若检测到该多条数据记录均属于第二热点数据，则将Node 2确定为目标存储设备。可选地，还可以将第一热点数据和第二热点数据存储在同一个存储设备上，比如将第一热点数据和第二热点数据都存储在Node 1上，这时若检测到该多条数据记录属于第一热点数据或者第二热点数据，都会将Node 1确定为目标存储设备。

在该相似数据条件包括该多条数据记录各自的SQL操作语义符合语义关联条件的情况下，此时分布式数据库系统会将SQL操作语义符合语义关联条件的数据记录存放在同一存储设备上，比如，将数据表中的主键记录和二级索引数据存放到同一存储设备上，又比如，将经常被同一SQL查询事务一起访问的数据记录存放到同一存储设备上，又比如，将图数据库中关系相近的节点所代表的数据记录存放到同一存储设备上等。这时，若计算设备检测到该多条数据记录的SQL操作语义符合语义关联条件，那么将用于存放SQL操作语义符合语义关联条件的数据记录的存储设备确定为目标存储设备，比如，计算设备检测到该多条数据记录实际上是同一张数据表中的主键记录或二级索引数据，或者，该多条数据记录经常被同一SQL查询事务一起访问(例如经常被同一SQL查询事务执行Join操作)，或者，该多条数据记录在图数据库中位于关系相近的节点，这样代表了该多条数据记录符合语义关联条件，那么将用于存放SQL操作语义符合语义关联条件的数据记录的存储设备确定为目标存储设备。

303、计算设备向该目标存储设备下发该目标事务，以使该目标存储设备以单机事务的方式执行该目标事务。

由于在上述步骤302中，已经判断了目标事务操作的多条数据记录是否符合相似数据条件，在该多条数据记录符合相似数据条件的情况下，代表该多条数据记录是存放同一个存储设备即目标存储设备中的，此时，计算设备可以通过本步骤303，将目标事务的SQL语句继续下发到该目标存储设备，从而由目标存储设备能够以单机事务的方式执行该目标事务，并在执行完毕后提交或回滚该目标事务，而无需经过2PC算法的多轮通信交互。正是由于在本申请实施例涉及的分布式数据库系统中，节点设备是具有多元形态的，即每个节点设备都同时具有计算和存储功能，因此计算设备能够将目标事务下推到目标存储设备，而目标存储设备也会具有事务执行功能，并由于目标事务涉及的多条数据记录全都位于目标存储设备的本地，因此能够以单机事务的方式执行目标事务。

在一些实施例中，在该多条数据记录不符合相似数据条件的情况下，代表该多条数据记录存放在至少两个互不相同的存储设备中，此时计算设备可以充当2PC算法中的协调者，来协调目标事务所涉及的至少两个存储设备(参与者)分别执行分配到各自设备上的子事务。2PC算法可划分为准备阶段和提交阶段，在进入准备阶段之前，计算设备将目标事务拆分成每个存储设备各自需要本地执行的子事务，接着向每个存储设备分发各自的子事务，存储设备接收到分发的子事务后本地执行该子事务，并向存储设备返回子事务执行结果，计算设备汇总所有存储设备返回的子事务执行结果，在所有子事务执行结果均为执行成功的情况下，进入到2PC算法的准备阶段，计算设备向每个存储设备发送Prepare(准备)请求，存储设备在接收到Prepare请求后，本地验证子事务是否存在数据冲突，向计算设备返回本地验证结果，计算设备汇总所有存储设备返回的本地验证结果，在所有本地验证结果均为无数据冲突的情况下，进入到2PC算法的提交阶段，计算设备向每个存储设备发送Commit(提交)请求，存储设备在接收到Commit请求后，本地提交子事务，将相关数据落盘并清理上下文信息、持有的锁资源等，否则，在任一存储设备子事务执行失败，或者任一存储设备的本地验证结果为有数据冲突，这时都将全局回滚目标事务。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过在分布式数据库系统中预先定义将符合相似数据条件的数据记录尽可能存储在同一存储设备上，这样针对涉及批量SQL操作的目标事务，先判断涉及的多条数据记录是否符合相似数据条件，在符合相似数据条件时能够确定得到一个目标存储设备，这一目标存储设备存储了目标事务涉及的所有数据记录，从而计算设备无需以2PC算法来协调目标事务，只需要将目标事务下推到目标存储设备，使得目标存储设备能够以单机事务的方式来执行目标事务，由于涉及批量SQL操作的事务通常都会涉及多个数据分区或跨越多个存储设备，通过将符合相似数据条件的数据记录整合在同一存储设备，能够极大减少分布式数据库系统中需要以2PC算法协调的、涉及批量SQL操作的事务数量，从而极大降低了分布式数据库系统中处理涉及批量SQL操作的事务时的通信开销，简化了针对涉及批量SQL操作的事务的处理流程，提升了针对涉及批量SQL操作的事务的执行效率。

在上一实施例中，简单介绍了在本申请实施例涉及的基于智能感知存储体系的分布式数据库中，如何处理涉及批量SQL操作的事务，并且由于符合相似数据条件的数据记录都会尽可能存储在同一存储设备上，这样能够将部分涉及批量SQL操作的事务转换成单机事务来执行。

下面，将详细介绍本申请实施例涉及的基于智能感知存储体系的分布式数据库，如何通过系统架构来实现各种功能。基于智能感知存储体系的分布式数据库，核心突出点是“感知”，感知体现在两个方面，一方面是对于系统的感知，系统会根据自身的状态情况适时的进行一些策略的调度，比如后面的实施例中将会介绍到的数据迁移策略，另一方面是对于用户的感知，用户能够自定义数据的形态、数据的存储位置以及相似数据的定义。如图2所示，能够看出来图2中示出了如下几种感知方式：存储格式感知、数据亲和性感知、存储资源感知、冷热数据感知和可靠性感知。

存储格式感知：同一份数据记录可以根据不同业务的需求支持不同的存储格式，比如OLAP业务一般使用列存引擎，在系统内对OLAP业务建立列存格式的副本；OLTP业务对于时效性、时延要求较高，一般使用行存引擎，则在系统内对OLTP业务建立行存格式的副本；SQL优化器和执行器会根据业务的不同，自动选择在行存引擎上执行，还是在列存引擎上执行；此外，对于OLTP业务，如果有Binlog订阅或者增量备份的业务需求，在系统内也可以增加Binlog Generator(二进制日志生成器)的副本，用于产生Binlog给下游业务订阅，或者作为增量备份的增量部分；此外，Compressed Engine(压缩引擎)是一个综合能力最强的引擎，独创的算法可以在保证性能的同时，在不解压缩的情况下提供访问数据的能力，同时有效节省存储空间和内存资源，一般用于数据量较大，但是对于性能要求较高的业务场景。

数据亲和性感知：在存算分离的架构下，执行同一个Query(查询)请求，RPC次数越少，跨网络访问的数据量越小，整体系统的查询性能就越高。反过来，由于对存储引擎的要求是把经常访问的数据(即符合相似数据条件的数据记录)尽量的放在在相同的位置，这样计算引擎就能够自动根据数据的位置把相关事务下推到存储节点，从而能够以单机事务的方式执行相关事务。比如，针对OLTP业务，尽量把同一张数据表中的数据记录(主键记录)和二级索引数据存放在同一存储设备，如果事务所欲写入的数据记录都在同一存储设备，事务会自动将二阶段提交优化至一阶段提交，即将分布式事务优化成单机事务，此外，由于主键记录和二级索引数据存放在同一存储设备，索引查询也会把回表操作下推至同一存储设备来完成。又比如，针对OLAP业务，把经常一起Join的数据表中的数据记录存放到相同的存储设备，那么SQL优化器也会自动把Join操作下推至存储设备去执行，有效减少了数据记录在不同设备之间的迁移。还比如，针对图计算引擎来讲，把关系相近的节点对应的数据记录存放到相同的存储设备，也可以有效的提升图查询的性能。

存储资源感知：在数据库运行过程中，不同的数据记录需要的资源类型是完全不一样的，比如热点数据需要消耗更多的CPU、内存和IO等计算资源，而冷数据(指不经常访问的非热点数据)更多的只是消耗存储容量即存储资源。因此，通过对不同的数据记录分配不同类型的资源，并采用不同的压缩算法，能够实现存储资源感知。

冷热数据感知：对于热点数据分配更多的内存，尽量让热点数据缓存到内存当中；而针对冷数据则是采用压缩率更高的压缩算法以节约存储资源。数据的冷热程度是由系统根据负载来判断，并且还会定期自动调整，从而能够在有效的资源限制下，提供更好的事务处理性能。

可靠性感知：不同应用对于数据的可靠性要求不一样，用户可以配置自己的可靠性策略，提供不同级别的可靠性保证，而数据感知体系在移动数据副本的时候，会保证可靠性策略优先满足，比如，假设用户配置了跨IDC级别的可靠性，那么在调度同一份数据记录的副本时，会保证该数据记录的两个副本不能够放在同一个IDC上，从而在迁移数据副本的同时保证了跨IDC级别的可靠性。

以下，将针对数据亲和性进行详细说明，数据亲和性就是指数据是否符合相似数据条件，在分布式数据库中将数据按照KV进行划分，分成多个连续的逻辑区间即主键范围，不同主键范围的KV数据会存放在存储集群的多个存储设备上面。在批量更新数据的场景下，传统的单机数据库只存在单个数据节点设备，因此客户端只需要与一个数据节点设备进行通信，但对于分布式数据库来说，由于数据可能存放在不同存储设备中，因此需要与多个存储设备进行网络通信，并且2PC算法来保证一致性的情况下需要经过多轮网络通信，因此整个分布式系统的网络开销很大。

图4是本申请实施例涉及的一种分布式系统中涉及批量SQL操作的事务的处理流程示意图，如图4所示，示出了在分布式数据库的系统架构下，针对涉及批量SQL操作(如，增删改查)的事务，计算引擎401会下发一个该事务的批量SQL操作指令，此时，先判断当前事务操作的数据记录涉及单个存储设备还是多个存储设备，对于单个存储设备(如仅涉及存储设备4024)来说，只需要通过一次网络通信就能够执行事务，对于多个存储设备(如涉及存储设备4021-4023)来说，则需要向多个存储设备都发送一个RPC，可想而知整个事务执行过程中的网络通信时间会线性增加，本申请实施例正是针对分布式数据库中可能存在的高频率网络通信这一情况，提出了数据亲和性的概念，旨在减少分布式数据库中涉及批量SQL操作事务在执行过程中的网络通信，从而减少分布式系统中的网络开销，进而提升分布式系统的性能。

数据亲和性的核心思想是将相似的数据存储在相同的位置，即，将符合相似数据条件的数据记录尽可能存储在相同的存储设备，可选地，将符合相似数据条件的数据记录定义如下：(Ⅰ)位于同一个KeyRange即主键范围中的数据记录，由于分布式数据库会将数据分片基于KeyRange来进行细粒度划分，在细粒度划分时本身就会兼顾相似数据的相关属性，因此处于同一KeyRange的数据记录本身就在逻辑区间层面上具有相似性；(Ⅱ)分布式系统中统计到的经常访问的热点数据，即上述实施例涉及的第一热点数据，分布式系统可以定点定时来更新一段时间内统计到的高频数据，比如经常被访问的数据记录或者经常被修改的数据记录，这时可以选取一个负载较低的机器来存储统计得到的第一热点数据，相当于专门开辟了空间来存储第一热点数据，且兼顾了不同机器的负载压力；(Ⅲ)基于AI训练出的热点数据，即上述实施例涉及的第二热点数据，分布式系统可以保存在一段时间内执行的历史SQL任务，每个历史SQL任务作为一个样本训练得到机器学习模型(比如集成模型)，用于筛选出符合模型要求的相关特征的第二热点数据，同理，可以选取一个负载较低的机器来存储统计得到的第二热点数据，相当于专门开辟了空间来存储第二热点数据，且兼顾了不同机器的负载压力；(Ⅳ)SQL语句中具有关联语义的数据，即上述实施例涉及的SQL操作语义符合语义关联条件的数据记录，比如，将同一张数据表中的主键记录和二级索引数据存放在一起，将经常被同一SQL查询事务一起访问的数据存放在一起，将经常Join的数据表存放在一起，将图数据库中关系相近的节点对应的数据记录存放在一起等等，这样能够将具有相似的SQL操作语义的数据记录存放在相同的位置。

需要说明的是，由于相似数据条件可能包括(Ⅰ)至(Ⅳ)的不同情况，这时可以将符合(Ⅰ)至(Ⅳ)的所有数据记录存放在同一个存储设备上，或者，这时并不需要将符合(Ⅰ)至(Ⅳ)的所有数据记录存放在同一个存储设备上，而只需要保证尽可能将符合同种相似数据条件的数据记录存放在同一个存储设备上即可，比如，将符合(Ⅱ)的第一热点数据存放在Node 1上，将符合(Ⅲ)的第二热点数据存放在Node 2上，将符合(Ⅳ)的SQL语句中具有关联语义的数据存放在Node 3上等，本申请实施例对此不进行具体限定。

图5是本申请实施例提供的一种存储设备存放策略的对比示意图，如图5所示，在没有提出数据亲和性的情况下，存储设备的存放策略如数据节点501所示，数据节点501上存储的是KeyRange 1内连续的数据记录，在提出数据亲和性的情况下，存储设备的存放策略如数据节点502所示，在数据节点502上不单单存储有KeyRange 1内连续的数据记录，还会存放热点数据以及SQL操作语义符合语义关联条件的数据记录，其中，热点数据可以包括系统定时统计到的第一热点数据和基于AI训练得到的第二热点数据，其中，SQL操作语义符合语义关联条件的数据记录主要包括：OLTP业务中的数据表中的主键记录和二级索引数据、OLAP业务中经常被同一SQL查询事务一起访问的数据表、图数据库中关系相近的节点的数据记录等。

图6是本申请实施例提供的一种基于数据亲和性的批量SQL操作的事务的处理流程的原理性示意图，如图6所示，在应用数据亲和性这一特性之后，对于计算引擎601下发的涉及批量SQL操作的事务，先判断事务涉及批量SQL操作的数据记录是否符合相似数据条件602，判断标准依照上述介绍过的相似数据条的定义：(Ⅰ)位于同一个KeyRange即主键范围中的数据记录；(Ⅱ)分布式系统中统计到的经常访问的热点数据；(Ⅲ)基于AI训练出的热点数据；(Ⅳ)SQL语句中具有关联语义的数据。如果满足相似数据条件602，代表批量SQL操作的多条数据记录存在相似性，这时通过网络通信到对应存储设备6032去获取多条数据记录并执行当前事务，存储设备6032可以从KeyRange区间、热点数据区间以及SQL语义关联区间中查找到该多条数据记录，再依次对该多条数据记录执行批量SQL操作，在验证无数据冲突的情况可以提交当前事务，否则若验证存在有数据冲突则需要回滚当前事务。如果不满足相似数据条件602，代表批量SQL操作的多条数据不存在相似性，这时需要多次网络通信到多个存储设备6031-6032来执行分布式事务，比如每个存储设备只需要查找KeyRange区间来获取本地存储的数据记录，进而执行本地分发下来子事务，再按照2PC算法进行提交(或回滚)。

可以看出，对比符合相似数据条件和不符合相似数据条件两种情况，在不符合相似数据条件时必然存在多次网络通信，整体事务执行的网络时耗较长，而符合相似数据条件时则只需要一次网络通信，即可以单机事务的方式来执行涉及批量SQL操作的事务。因此，通过在分布式数据库中尽可能将相似的数据存放在相同的位置，能够加大缩短涉及批量SQL操作的事务处理过程的网络通信时长，从而提升分布式数据库架构的整体事务处理性能。

在上述图6中主要介绍了数据亲和性对于网络通信的影响，但减少网络通信仅是浅层表现，数据亲和性的影响中，更重要的是减少系统内分布式事务的数量(部分原本的分布式事务，被转换为单机事务执行)。在分布式数据库中，如果某个事务仅涉及到操作单个存储设备上的数据记录，称为单机事务，如果涉及到操作跨存储设备上的数据记录，称为分布式事务，由于分布式数据库本身存储集群中会配置多个存储设备，因此分布式事务是普遍存在的。为了保证事务操作的ACID特性，需要以2PC算法来提交分布式事务，即，引入了参与者和协调者，每一个参与者(即存储设备)都知道自身本地操作成功与否，协调者(即计算设备)统一来协调所有参与者的操作结果，并且指示所有参与者是否把操作结果真正的提交或者是回滚。

图7是本申请实施例提供的一种两阶段提交和一阶段提交的对比示意图，如图7所示，在单机事务的一阶段提交过程701中，不存在协调者和参与者的概念，这里以计算设备负责处理事务，而存储设备负责存储数据的情况为例进行说明(即不考虑本申请实施例涉及的多元形态节点)，只需要由计算设备的计算引擎向存储设备的存储引擎发送Commit提交指令就能够实现整个事务的提交，因此只存在一次RPC网络通信。在分布式事务的两阶段提交过程702中，涉及到准备阶段和提交阶段，在准备阶段，协调者需要给所有参与者发送Prepare请求，在提交阶段，协调者需要给所有参与者发送Commit请求，以使得每个参与者在本地将数据落盘、释放事务所持有的锁资源。假设不考虑对于异常逻辑时发生回滚的处理流程，以事务通过2PC算法全局提交的过程来与一阶段提交进行对比，在两阶段提交过程中，计算设备的计算引擎会向协调者发起一个RPC，假定当前事务中参与者的数量为2个，则协调者将会给每一个参与者发送两条RPC(分别是Prepare请求以及Commit请求)，暂不考虑异常逻辑导致回滚的情况，在整个两阶段提交过程中RPC调用次数为5次，存在五次网络通信，如果参与者数量更多，则RPC调用次数显然也会更多，网络通信次数也会跟多，而一阶段提交过程则仅存在一次RPC网络通信，可知，两阶段提交的过程中网络通信次数较大，因此会对分布式数据库的性能造成损失(导致不如单机数据库那样延时低)。

下面，将结合上述数据亲和性的概念，对本申请实施例涉及的基于智能感知存储体系的分布式数据库中，针对涉及批量SQL(如，增删改查)操作的目标事务的处理流程进行详细说明。

图8是本申请实施例提供的一种事务执行方法的流程图，参见图8，该实施例由基于智能感知存储体系的分布式数据库系统中的计算设备执行，该实施例包括下述步骤：

801、针对涉及批量结构化查询语言SQL操作的目标事务，计算设备确定该批量SQL操作关联的多条数据记录。

上述步骤801和上述步骤301类似，这里不做赘述。

802、计算设备判断该多条数据记录是否符合相似数据条件，在符合相似数据条件时，执行步骤803-804，在不符合相似数据条件时，执行步骤805-806。

在一些实施例中，该相似数据条件包括下述至少一项：该多条数据记录各自的主键均处于同一主键范围内；或，该多条数据记录均属于热点数据，该热点数据用于表征在历史时间段中被频繁访问的数据记录；或，该多条数据记录各自的SQL操作语义符合语义关联条件。

在该相似数据条件包括该多条数据记录各自的主键均处于同一主键范围内的情况下时，此时分布式数据库系统会将不同主键范围的数据记录存放在不同的存储设备上，比如，将主键范围为1-500的数据记录存放在Node 1上，将主键范围为501-1000的数据记录存放在Node 2上，将主键范围为1001-1500的数据记录存放在Node 3上，若计算设备检测到该多条数据记录各自的主键均处于同一主键范围内，则确定该多条数据记录符合该相似数据条件，再通过下述步骤803将用于存储该主键范围内数据记录的存储设备确定为目标存储设备，比如，若检测到该多条数据记录的主键范围均位于1-500，则确定该多条数据记录符合该相似数据条件，并将Node 1确定为目标存储设备。

在该相似数据条件包括该多条数据记录均属于热点数据的情况下，此时分布式数据库系统会将热点数据存放在同一存储设备上，比如，将热点数据都存放在当前系统内负载较低的Node 10上，若计算设备检测到该多条数据记录均属于热点数据，则确定该多条数据记录符合该相似数据条件，再通过下述步骤803将用于存储热点数据的存储设备确定为目标存储设备，比如，若检测到该多条数据记录均属于热点数据，则确定该多条数据记录符合该相似数据条件，并将Node 10确定为目标存储设备。

在一些实施例中，热点数据可进一步划分成第一热点数据和第二热点数据。

第一热点数据是指根据历史时间段中被访问次数或被修改次数统计得到的热点数据，比如，第一热点数据为：在历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的数据记录，其中，该访问次数阈值和修改次数阈值均为大于或等于1的整数，例如访问次数为1000、修改次数阈值为100等，本申请实施例对此不进行具体限定。这时，若计算设备检测到该多条数据记录均在该历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值，则代表该多条数据记录均属于第一热点数据，确定该多条数据记录符合该相似数据条件，再通过下述步骤803将用于存储第一热点数据的存储设备确定为目标存储设备。

第二热点数据则是根据机器学习模型提取到的数据特征与第一热点数据的数据特征符合相似条件的热点数据，比如，第二热点数据为：通过特征提取模型筛选得到的、数据特征与第一热点数据的数据特征符合相似条件的数据记录，该特征提取模型用于针对在该历史时间段内涉及批量SQL操作的历史事务所操作的数据记录提取数据特征，换言之，第二热点数据的数据特征与第一热点数据的数据特征符合相似条件。可选地，相似条件是指第二热点数据的数据特征和第一热点数据的平均特征之间的特征夹角小于夹角阈值，或者，第二热点数据的数据特征和第一热点数据的平均特征之间的欧式距离小于距离阈值，或者，第二热点数据的数据特征和第一热点数据的平均特征之间的余弦相似度大于相似度阈值等，本申请实施例对相似条件不进行具体限定，其中，夹角阈值为大于或等于0度的角度值，距离阈值为大于或等于0的数值，相似度阈值为大于或等于-1且小于或等于1的数值。这时，若计算设备检测到通过该特征提取模型对该多条数据记录各自提取到的数据特征与通过该特征提取模型对该第一热点数据提取到的数据特征符合相似条件，则代表该多条数据记录均属于第二热点数据，确定该多条数据记录符合该相似数据条件，再通过下述步骤803将用于存储第二热点数据的存储设备确定为目标存储设备。

在该相似数据条件包括该多条数据记录各自的SQL操作语义符合语义关联条件的情况下，此时分布式数据库系统会将SQL操作语义符合语义关联条件的数据记录存放在同一存储设备上，比如，将数据表中的主键记录和二级索引数据存放到同一存储设备上，又比如，将经常被同一SQL查询事务一起访问的数据记录存放到同一存储设备上，又比如，将图数据库中关系相近的节点所代表的数据记录存放到同一存储设备上等。这时，若计算设备检测到该多条数据记录的SQL操作语义符合语义关联条件，那么确定该多条数据记录符合该相似数据条件，再通过下述步骤803将用于存放SQL操作语义符合语义关联条件的数据记录的存储设备确定为目标存储设备。

在一些实施例中，计算设备可以在满足如下任一情况时，确定该多条数据记录各自的SQL操作语义符合语义关联条件：该多条数据记录仅包括同一数据表的主键记录和二级索引记录，相当于将同一张数据表中的表数据和二级索引数据视为符合语义关联条件；或，该多条数据记录在历史时间段中被同一SQL查询事务进行批量SQL操作的频次大于频次阈值，比如，被同一SQL查询事务多次关联进行Join操作等，相当于将历史时间段中经常被同一SQL查询事务一起访问的数据视为符合语义关联条件，其中，该频次阈值是任一大于或等于1的整数；或，将该多条数据记录转换到图数据库后，该多条数据记录各自对应的多个节点中任意两个节点之间存在连接边且该连接边的边长不超过边长阈值，相当于将图数据库中关系相近的节点所代表的数据视为符合语义关联条件，其中，该边长阈值是任一大于或等于0的数值。

在一些实施例中，除了上述示例提供的相似数据条件之外，技术人员可以自定义更多或者更少的相似数据条件，以灵活应对不同的业务场景或业务需求，本申请实施例对此不进行具体限定。

803、计算设备在该多条数据记录符合相似数据条件的情况下，确定该多条数据记录所在的目标存储设备。

其中，该目标存储设备用于存储符合该相似数据条件的数据记录。

在一些实施例中，若通过上述步骤802检测到该多条数据记录各自的主键均处于同一主键范围内，则将用于存储该主键范围内数据记录的存储设备确定为目标存储设备，比如，分布式数据库中将主键范围为1-500的数据记录存放在Node 1上，将主键范围为501-1000的数据记录存放在Node 2上，将主键范围为1001-1500的数据记录存放在Node 3上，若检测到该多条数据记录的主键范围均位于1-500，则将Node 1确定为目标存储设备。

在一些实施例中，若通过上述步骤802检测到该多条数据记录均属于热点数据，则将用于存储热点数据的存储设备确定为目标存储设备，比如，分布式数据库中将热点数据都存放在当前系统内负载较低的Node 10上，若检测到该多条数据记录均属于热点数据，则将Node 10确定为目标存储设备。

在一些实施例中，在针对热点数据划分成第一热点数据和第二热点数据的情况下，可以将第一热点数据存储在一个存储设备上，将第二热点数据存储在另一个存储设备上，比如，将第一热点数据存储在Node 1上，将第二热点数据存储在Node 2上，这时，若通过上述步骤802检测到该多条数据记录均属于第一热点数据，则将用于存放第一热点数据的存储设备确定为目标存储设备，比如，若检测到该多条数据记录均属于第一热点数据，则将Node 1确定为目标存储设备；若通过上述步骤802检测到该多条数据记录均属于第二热点数据，则将用于存放第二热点数据的存储设备确定为目标存储设备，比如，若检测到该多条数据记录均属于第二热点数据，则将Node 2确定为目标存储设备。可选地，还可以将第一热点数据和第二热点数据存储在同一个存储设备上，比如将第一热点数据和第二热点数据都存储在Node 1上，这时若通过上述步骤802检测到该多条数据记录属于第一热点数据或者第二热点数据，都会将Node 1确定为目标存储设备。

在一些实施例中，若通过上述步骤802检测到该多条数据记录各自的SQL操作语义符合语义关联条件，则将用于存放SQL操作语义符合语义关联条件的数据记录的存储设备确定为目标存储设备，比如，分布式数据库中将数据表中的主键记录和二级索引数据存放到Node 4上，将经常被同一SQL查询事务一起访问的数据记录存放到Node 5上，将图数据库中关系相近的节点所代表的数据记录存放到Node 6上，这时，若通过上述步骤802检测到该多条数据记录是同一张数据表的主键记录和二级索引数据，则将Node 4确定为目标存储设备，若通过上述步骤802检测到该多条数据记录在历史时间段内被同一SQL查询事务进行批量SQL操作的频次大于频次阈值，则将Node 5确定为目标存储设备，若通过上述步骤802检测到在将该多条数据记录转换到图数据库后，该多条数据记录各自对应的多个节点中任意两个节点之间存在连接边且该连接边的边长不超过边长阈值，则将Node 6确定为目标存储设备。

需要说明的是，本申请实施例涉及的历史时间段，是指任一比当前时刻早的历史上的时间区间，比如，历史时间段可以是最近一周、最近一个月、最近三个月、最近半年、最近一年等，还可以是从数据库建库开始至今，或者，历史时间段还可以是指定的从某年某月某日到任一早于或等于当前时刻的指定时刻，例如从2000年6月1日至今，本申请实施例对历史时间的表示形式以及时间精度不进行具体限定。

804、计算设备向该目标存储设备下发该目标事务，以使该目标存储设备以单机事务的方式执行该目标事务。

上述步骤804与上述步骤303类似，这里不做赘述。

在一些实施例中，由于本申请实施例涉及的基于智能感知存储体系的分布式数据库，还提供了不同存储格式的异构副本，因此，可以支持根据业务类型来切换主副本的功能。即，计算设备可以基于该目标事务所关联的业务类型，向该目标存储设备发送与该业务类型相匹配的主从切换指令，该主从切换指令用于指示该目标存储设备将该多条数据记录中与该业务类型适配度最高的副本切换为主副本，以在该切换完毕的主副本上执行该目标事务。进一步的，目标存储设备在接收到该主从切换指令之后，可以基于Raft算法实现主从副本之间的切换，以将主副本切换成与目标事务所关联的业务类型适配度最高的副本，从而在切换后的主副本上执行该目标事务的SQL操作。

在一些实施例中，计算设备可以在向目标存储设备下发的目标事务的同时发送该主从切换指令，或者计算设备单独下发主从切换指令，又或者，主从切换指令并非是单独的指令，而是由计算设备在下发目标事务的同时，也将该目标事务所关联的业务类型下发到目标存储设备，由目标存储设备基于接收到的业务类型，自动地将主副本切换成与该业务类型适配度最高的副本，本申请实施例对此不进行具体限定。

在一些实施例中，业务类型和存储副本之间可以有如下适配度关系：在该业务类型为OLAP业务的情况下，与该OLAP业务适配度最高的副本为列存副本，以适应于OLAP业务对多表Join操作的需求，满足OLAP业务所要求的高查询性能；或，在该业务类型为OLTP业务的情况下，与该OLTP业务适配度最高的副本为行存副本，以适应于OLTP业务对时效性的需求，满足OLTP业务所要求的高时效、低延时；或，在该业务类型为OLTP业务且存在二进制日志订阅需求的情况下，与该OLTP业务适配度最高的副本为携带二进制日志生成功能的副本，以满足业务方要求订阅二进制日志的需求，并且这类二进制日志还能够作为增量备份的增量部分，来满足业务方进行增量备份的需求，这样能够针对特定需求选择携带二进制日志生成功能的副本。

在上述过程中，正是由于基于智能感知存储体系的分布式数据库中，提供了不同存储格式的异构副本，而不同存储格式的副本与不同业务类型相互适配，进一步的提供了针对不同业务类型，及时切换到适配度最高的主副本的主从切换方式，从而能够灵活适用于OLTP、OLAP、存在二进制日志Binlog订阅需求的OLTP业务等各类业务场景。

在上述步骤802-804，介绍了如何判断目标事务涉及的多条数据记录是否满足相似数据条件，以及在满足相似数据条件的情况下，能够将目标事务以单机事务的方式来进行执行。由于在分布式数据库中，相似数据条件是可能会随着时间推移而发生变化的，比如原本的热点数据会随着时间推移变成冷数据，而某些冷数据可能随着业务需求而转换成热点数据，或者业务向数据库中写入了新的热点数据等，因此，分布式数据库需要定期来对符合相似数据条件的数据进行刷新，从而可以将不再是热点数据的冷数据迁移出内存，而转存到磁盘中进行持久化存储，同时，还可以将新检测到的热点数据迁移到系统内当前负载较低的存储设备中，比如将访问频次最高的部分热点数据存入到内存，将其余部分的热点数据存入到磁盘中，实现对符合相似数据条件的数据的定期刷新和动态调整。

在一些实施例中，每间隔目标时长，元信息管理服务器或者任一计算设备可以重新确定在该目标时长内符合该相似数据条件的数据记录，比如，将从当前时刻之前的目标时长到当前时刻作为新的历史时间段，统计第一热点数据、预测第二热点数据，并确定符合语义关联条件的相似数据；接着，将该目标时长内符合该相似数据条件的数据记录迁移至分布式数据库系统中计算负载小于负载阈值的存储设备中，其中，负载阈值是任一大于或等于0的数值。

在上述过程中，通过定期刷新符合相似数据条件的数据记录，能够实现对符合相似数据条件的数据的定期刷新和动态调整，避免发现热点数据过期等情况，从而实时跟进以降低系统内分布式事务的数量，最大程度降低涉及批量SQL操作的事务在执行过程的通信开销，并且，由于在对符合相似数据条件的数据记录进行刷新后，会迁移到系统内负载较低的计算设备上，从而能够保证在迁移过程中系统内的负载均衡。

在一些实施例中，可以将不同类型的相似数据存放在不同的存储设备上。比如，统计得到该目标时长内被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的第一热点数据之后，将该第一热点数据均迁移至计算负载小于负载阈值的第一存储设备；通过特征提取模型筛选得到的该目标时长内的第二热点数据之后，将该第二热点数据均迁移至计算负载小于负载阈值的第二存储设备，其中，该特征提取模型用于针对在该目标时长内涉及批量SQL操作的历史事务所操作的数据记录提取数据特征，该第二热点数据的数据特征与(新统计得到的)第一热点数据的数据特征符合相似条件；确定出来该目标时长内SQL操作语义符合该语义关联条件的至少一条数据记录之后，再将该至少一条数据记录均迁移至计算负载小于负载阈值的第三存储设备。

在上述过程中，通过将不同类型的相似数据存放在不同的存储设备上，能够避免将所有的相似数据都存放在同一个存储设备上时这一存储设备的性能受到较大影响，从而能够更好地实现分布式数据库系统的负载均衡。

805、计算设备在该多条数据记录不符合相似数据条件的情况下，确定该多条数据记录所在的多个存储设备。

在一些实施例中，在该多条数据记录不符合相似数据条件的情况下，代表涉及批量SQL操作的目标事务仍然是一个分布式事务，无法转换成单机事务来进行执行，这时，可以确定该多条数据记录涉及到的多个存储设备，比如，根据该多个数据记录各自所在的主键范围，确定用于存储对应主键范围的存储设备，重复执行上述操作能够确定得到多个存储设备。

806、计算设备向该多个存储设备分发各自对应的该目标事务的子事务，以使该多个存储设备在执行分发得到的子事务后，以分布式事务的方式对目标事务进行两阶段提交。

在一些实施例中，由于目标事务仍然是一个分布式事务，分布式事务需要通过2PC算法来进行协调，此时，计算设备可以充当2PC算法中的协调者，上述步骤805确定的多个存储设备可以充当2PC算法中的参与者，从而来执行目标事务。

在一些实施例中，计算设备将目标事务拆分成每个存储设备各自需要本地执行的子事务，接着向每个存储设备分发各自的子事务，存储设备接收到分发的子事务后本地执行该子事务，并向存储设备返回子事务执行结果，计算设备汇总所有存储设备返回的子事务执行结果，在所有子事务执行结果均为执行成功的情况下，可以以2PC算法来对目标事务进行两阶段提交。

在2PC算法的准备阶段，计算设备向每个存储设备发送Prepare请求，存储设备在接收到Prepare请求后，本地验证子事务是否存在数据冲突，向计算设备返回本地验证结果，计算设备汇总所有存储设备返回的本地验证结果，在所有本地验证结果均为无数据冲突的情况下，进入到2PC算法的提交阶段，计算设备向每个存储设备发送Commit请求，存储设备在接收到Commit请求后，本地提交子事务，将相关数据落盘并清理上下文信息、持有的锁资源等，否则，在任一存储设备子事务执行失败，或者任一存储设备的本地验证结果为有数据冲突，这时都将全局回滚目标事务。

图9是本申请实施例提供的一种数据亲和性在分布式事务中应用方式的示意图，如图9所示，假设某个数据表中包括ID(标识)、Name(名称)、Age(年龄)、DeptID(部门标识)、Grade(等级)共5个字段，并为每个字段都添加了一个索引，例如，对ID字段添加索引Clustered Index，对Name字段添加索引Second Index_1，对Age字段添加索引SecondIndex_2，对DeptID字段添加索引Second Index_3，对Grade字段添加索引Second Index_4。在传统分布式数据库中，存储引擎会将这张数据表的二级索引数据分散到4个存储设备901-904上。假设某一时刻新到一个事务T，需要在这张数据表中插入一条数据记录，那么需要对这张表的所有二级索引数据都进行更新，由于二级索引数据分散到了4个存储设备上，因此事务T是一个涉及到4个参与者的分布式事务，将会产生至少8次网络通信。而应用本申请实施例涉及的数据亲和性策略之后，由于同一张数据表的二级索引数据是符合语义关联条件的，因此这张数据表的所有二级索引数据会被几种存储在存储设备901上面，这样能够将两阶段提交的分布式事务转换成一阶段提交的单机事务，极大降低分布式数据库中分布式事务的数量，提升原本应该是分布式事务但被转换成单机事务这类事务的执行效率，从而提升分布式数据库的整体性能。

在另一些实施例中，假设存储设备901的负载本身较高，出于负载均衡的考虑，也可以将相似的数据存放在尽量少的存储设备上，比如，将Second Index_1和Second Index_2的二级索引数据存放在存储设备901上，将Second Index_3和Second Index_4的二级索引数据存放在存储设备902上，这样能够介绍分布式事务的参与者数量，即，将涉及到4个参与者的分布式事务转换成涉及到2个参与者的分布式事务，从而也能够降低分布式事务的网络开销，提升分布式数据库的整体性能。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过在分布式数据库系统中预先定义将符合相似数据条件的数据记录尽可能存储在同一存储设备上，这样针对涉及批量SQL操作的目标事务，先判断涉及的多条数据记录是否符合相似数据条件，在符合相似数据条件时能够确定得到一个目标存储设备，这一目标存储设备存储了目标事务涉及的所有数据记录，从而计算设备无需以2PC算法来协调目标事务，只需要将目标事务下推到目标存储设备，使得目标存储设备能够以单机事务的方式来执行目标事务，由于涉及批量SQL操作的事务通常都会涉及多个数据分区或跨越多个存储设备，通过将符合相似数据条件的数据记录整合在同一存储设备，能够极大减少分布式数据库系统中需要以2PC算法协调的、涉及批量SQL操作的事务数量，从而极大降低了分布式数据库系统中处理涉及批量SQL操作的事务时的通信开销，简化了针对涉及批量SQL操作的事务的处理流程，提升了针对涉及批量SQL操作的事务的执行效率。

在上述各个实施例中，都详细介绍了在基于智能感知存储体系的分布式数据库中，如何优化原本需要进行两阶段提交的分布式事务，即，通过提出数据亲和性，将相似的数据尽量存储在相同的位置，从而将分布式事务转换成单机事务来进行提交(即将两阶段提交转换成一阶段提交)，即使某些分布式事务没有被转换成单机事务，也可能会极大减少2PC算法涉及的参与者的数量。并且，由于系统内的节点设备都是多元形态的，即每个节点设备都兼具计算和存储功能，因此在这一架构下，计算设备上的计算引擎或SQL执行器，能够将事务下推到存储设备来进行执行。这针对当前的大数据时代，在数据重要性被无限放大、数据作为数据管理的核心的背景下，提供一个高可用的分布式数据库系统具有尤其重要的现实意义，并且由于分布式异构存储副本，能够满足不同业务对于性能、可靠性以及成本的需求。

在上述基于智能感知存储体系的分布式数据库的基础上，通过将存储层的数据亲和性与计算层来相结合，还提供了一种全局自动负载优化策略，旨在通过统计历史事务涉及的查询(Query)项，来自动实现数据迁移和全局负载均衡。

在一些实施例中，元信息管理服务器或任一计算设备可以从多个历史事务中筛选得到至少一个待优化事务，该待优化事务指未以单机事务的方式执行的历史事务；接着，基于该至少一个待优化事务，生成多个迁移策略信息，该迁移策略信息用于指示如何对该待优化事务涉及操作的数据记录进行重分布；接着，从该多个迁移策略信息中，确定执行代价最小的目标策略信息；最后，基于该目标策略信息，在分布式数据库系统中，对该至少一个待优化事务涉及操作的数据记录进行数据迁移。

在上述过程中，通过统计一段时间内的历史事务中存在哪些待优化事务，从而确定这些待优化事务的数据位置优化空间，从中选取代价最小的目标策略信息，依次在分布式数据库系统中进行数据迁移，从而能够针对待优化事务涉及操作的数据记录实现系统内的数据重分布，有利于优化将后续同类的分布式事务都优化成单机事务来进行提交，并且由于将执行代价最小作为目标策略信息的选取标准，也能够实现全局自动化负载均衡。

在一些实施例中，上述迁移策略信息为数据分布图，该数据分布图用于指示将该待优化事务涉及操作的数据记录从原存储设备迁移至新存储设备的数据流向，这时，在生成迁移策略信息时，也即是基于该至少一个待优化事务，生成多个不存在冲突的数据分布图，该不存在冲突的数据分布图是指不存在将同一数据记录从原存储设备迁移至多个新存储设备。可选地，该数据分布图除了用于指示数据迁移的数据流向之外，还可以指示本次迁移的数据记录在同步协议中是担任主副本还是从副本，即，数据分布图还用于指示本次迁移的数据记录的角色是同步协议中的主副本，还是同步协议中的从副本，这样使得在按照数据分布图进行数据重分布的时候，能够快速分配同步协议中的主从副本，有利于提升数据迁移效率。

例如，假设存在待优化事务T1和T2，事务T1操作了Node 1上的Record 150和331以及Node 3上的Record1210，事务T2操作了Node 1上的Record331和431以及Node4上的Record 1610，那么事务T1的优化方向是将Record150和331从Node1迁移到Node 3，事务T2的优化方向则是将Record 331和431从Node1迁移到Node 4，这时必然在数据分布图中存在冲突，因此一个优化方向要求将Record 331迁移到Node3，另一个优化方向要求将Record331迁移到Node4。

在上述过程中，通过以数据分布图的方式来表征迁移策略信息，能够很方便的判断出来是否存在冲突，即，数据分布图中如果存在从同一节点出发的两条或两条以上的边，那么比如代表会将这一节点的数据记录从原存储设备迁移到多个新存储设备，因此必然存在冲突，通过筛选出来不存在冲突的数据分布图来作为最终候选的迁移策略信息，能够保证迁移策略信息必定不会由于存在冲突而不可用(但仍然可能会存在较高代价，因此需要进一步筛选)。

在一些实施例中，对任一迁移策略信息，可以基于该迁移策略信息的存储代价、通信代价或者负载代价中的至少一项确定得到该迁移策略信息的执行代价，其中，该存储代价表征将该待优化事务涉及操作的数据记录以当前存储格式存储时带来的存储开销，该通信代价表征将该待优化事务涉及操作的数据记录从原存储设备迁移至新存储设备的过程中造成的通信开销，该负载代价表征将该待优化事务涉及操作的数据记录迁移至新存储设备后对新存储设备所带来的负载情况。

在一些实施例中，对任一迁移策略信息中涉及任一条待迁移的数据记录，比较不同存储引擎造成的代价，以便于选取最优存储引擎来作为本条数据记录的存储代价，综合所有待迁移的数据记录的存储代价，即可得到该迁移策略信息总体的存储代价。

在一些实施例中，对任一迁移策略信息，获取该迁移策略信息在进行数据迁移过程中的跨网络通信次数、跨节点访问数据量或者跨节点时延中至少一项因素，对上述至少一项音素进行加权求和得到该迁移策略信息的通信代价。

在一些实施例中，对任一迁移策略信息，确定该迁移策略信息涉及到将数据迁移至的每个新存储设备的负载情况，该负载情况包括但不限于CPU、内存以及数据在缓冲池(BufferPoll)的缓存率等指标，综合所有新存储设备的负载情况，即可得到该迁移策略信息的负载代价。

在一些实施例中，对每个迁移策略信息，在获取到该迁移策略信息的存储代价、通信代价和负载代价之后，可以对该存储代价、通信代价和负载代价进行加权求和，以得到该迁移策略信息的执行代价。接着，比较所有迁移策略信息各自的执行代价，选取执行代价最小的迁移策略信息作为目标策略信息。最后，按照选定的目标策略信息在整个分布式数据库系统中实现数据重分布。

在上述过程中，通过全面考虑迁移策略信息的存储代价、通信代价以及负载代价，能够从多个维度来综合衡量按照迁移策略信息进行数据迁移后会造成的性能开销，从而有利于从CBO(Cost-Based Optimization，基于成本的优化)方式出发决策出最佳的迁移策略信息。

图10是本申请实施例提供的一种全局负载自动优化策略的原理性流程图，如1000所示，以仅针对查询类的历史事务(即历史查询事务)进行优化为例进行说明，首先，统计一段时间内的所有历史Query，接着，从所有历史Query中确定出每个待优化Query，由于待优化Query数量可能会比较多，为避免迁移策略信息过于复杂，可以选取top N(N≥1)个待优化Query，例如，从所有待优化Query中选取查询频次最高的N个作为top N的待优化Query。接着，基于top N个待优化Query，生成K(K≥1)个不存在冲突的数据分布图，通过SQL优化器来计算每个数据分布图(即迁移策略信息)的执行代价，选取执行代价最小的数据分布图作为最终全局迁移计划的目标策略信息，由全局负载均衡器来基于目标策略信息来进行数据迁移，以实现数据重分布。

在本申请实施例中，结合存储引擎和SQL优化器，能够根据过往执行过的历史事务，统计出尚存哪些待优化事务，并合理生成多个迁移策略信息，计算每个迁移策略信息的执行代价，并选定执行代价最小的迁移策略信息作为最终的全局迁移计划，以实现全局自动化负载均衡及优化。

图11是本申请实施例提供的一种事务执行装置的结构示意图，请参考图11，该装置包括：

第一确定模块1101，用于针对涉及批量SQL操作的目标事务，确定该批量SQL操作关联的多条数据记录；

第二确定模块1102，用于在该多条数据记录符合相似数据条件的情况下，确定该多条数据记录所在的目标存储设备，该目标存储设备用于存储符合该相似数据条件的数据记录；

下发模块1103，用于向该目标存储设备下发该目标事务，以使该目标存储设备以单机事务的方式执行该目标事务。

本申请实施例提供的装置，通过在分布式数据库系统中预先定义将符合相似数据条件的数据记录尽可能存储在同一存储设备上，这样针对涉及批量SQL操作的目标事务，先判断涉及的多条数据记录是否符合相似数据条件，在符合相似数据条件时能够确定得到一个目标存储设备，这一目标存储设备存储了目标事务涉及的所有数据记录，从而计算设备无需以2PC算法来协调目标事务，只需要将目标事务下推到目标存储设备，使得目标存储设备能够以单机事务的方式来执行目标事务，由于涉及批量SQL操作的事务通常都会涉及多个数据分区或跨越多个存储设备，通过将符合相似数据条件的数据记录整合在同一存储设备，能够极大减少分布式数据库系统中需要以2PC算法协调的、涉及批量SQL操作的事务数量，从而极大降低了分布式数据库系统中处理涉及批量SQL操作的事务时的通信开销，简化了针对涉及批量SQL操作的事务的处理流程，提升了针对涉及批量SQL操作的事务的执行效率。

在一种可能实施方式中，该相似数据条件包括该多条数据记录均属于热点数据，该热点数据用于表征在历史时间段中被频繁访问的数据记录；

基于图11的装置组成，该第二确定模块1102包括：

第一确定单元，用于在该多条数据记录均属于该热点数据的情况下，将用于存储该热点数据的存储设备确定为该目标存储设备。

在一种可能实施方式中，该热点数据包括在该历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的第一热点数据；

该第一确定单元用于：

在该多条数据记录均在该历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的情况下，将该多条数据记录均确定为该第一热点数据，将用于存储该第一热点数据的存储设备确定为该目标存储设备。

在一种可能实施方式中，该热点数据包括通过特征提取模型筛选得到的第二热点数据，该特征提取模型用于针对在该历史时间段内涉及批量SQL操作的历史事务所操作的数据记录提取数据特征，该第二热点数据的数据特征与第一热点数据的数据特征符合相似条件，该第一热点数据在该历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值；

该第一确定单元用于：

在通过该特征提取模型对该多条数据记录各自提取到的数据特征与该第一热点数据的数据特征符合相似条件的情况下，将该多条数据记录均确定为该第二热点数据，将用于存储该第二热点数据的存储设备确定为该目标存储设备。

在一种可能实施方式中，该相似数据条件包括该多条数据记录各自的SQL操作语义符合语义关联条件；

基于图11的装置组成，该第二确定模块1102包括：

第二确定单元，用于在该多条数据记录各自的SQL操作语义符合该语义关联条件的情况下，将用于存储符合该语义关联条件的数据记录的存储设备确定为该目标存储设备。

在一种可能实施方式中，该第二确定单元还用于：

在该多条数据记录仅包括同一数据表的主键记录和二级索引记录的情况下，确定该多条数据记录各自的SQL操作语义符合该语义关联条件；或，

在该多条数据记录在历史时间段中被同一SQL查询事务进行批量SQL操作的频次大于频次阈值的情况下，确定该多条数据记录各自的SQL操作语义符合该语义关联条件；或，

在将该多条数据记录转换到图数据库后，该多条数据记录各自对应的多个节点中任意两个节点之间存在连接边且该连接边的边长不超过边长阈值的情况下，确定该多条数据记录各自的SQL操作语义符合该语义关联条件。

在一种可能实施方式中，该相似数据条件包括该多条数据记录各自的主键均处于同一主键范围内；

该第二确定模块1102还用于：

在该多条数据记录各自的主键均处于同一主键范围内的情况下，将用于存储该主键范围内的数据记录的存储设备确定为该目标存储设备。

在一种可能实施方式中，基于图11的装置组成，该装置还包括：

重新确定模块，用于每间隔目标时长，重新确定在该目标时长内符合该相似数据条件的数据记录；

第一迁移模块，用于将该目标时长内符合该相似数据条件的数据记录迁移至分布式数据库系统中计算负载小于负载阈值的存储设备中。

在一种可能实施方式中，该第一迁移模块用于：

将该目标时长内被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的第一热点数据，均迁移至计算负载小于负载阈值的第一存储设备；

将该目标时长内通过特征提取模型筛选得到的第二热点数据，均迁移至计算负载小于负载阈值的第二存储设备，该特征提取模型用于针对在该目标时长内涉及批量SQL操作的历史事务所操作的数据记录提取数据特征，该第二热点数据的数据特征与该第一热点数据的数据特征符合相似条件；

将该目标时长内SQL操作语义符合该语义关联条件的至少一条数据记录，均迁移至计算负载小于负载阈值的第三存储设备。

在一种可能实施方式中，该下发模块1103还用于：

基于该目标事务所关联的业务类型，向该目标存储设备发送与该业务类型相匹配的主从切换指令，该主从切换指令用于指示该目标存储设备将该多条数据记录中与该业务类型适配度最高的副本切换为主副本，以在该切换完毕的主副本上执行该目标事务。

在一种可能实施方式中，在该业务类型为OLAP业务的情况下，与该OLAP业务适配度最高的副本为列存副本；或，在该业务类型为OLTP业务的情况下，与该OLTP业务适配度最高的副本为行存副本；或，在该业务类型为OLTP业务且存在二进制日志订阅需求的情况下，与该OLTP业务适配度最高的副本为携带二进制日志生成功能的副本。

在一种可能实施方式中，基于图11的装置组成，该装置还包括：

筛选模块，用于从多个历史事务中筛选得到至少一个待优化事务，该待优化事务指未以单机事务的方式执行的历史事务；

生成模块，用于基于该至少一个待优化事务，生成多个迁移策略信息，该迁移策略信息用于指示如何对该待优化事务涉及操作的数据记录进行重分布；

第三确定模块，用于从该多个迁移策略信息中，确定执行代价最小的目标策略信息；

第二迁移模块，用于基于该目标策略信息，在分布式数据库系统中，对该至少一个待优化事务涉及操作的数据记录进行数据迁移。

在一种可能实施方式中，该迁移策略信息为数据分布图，该数据分布图用于指示将该待优化事务涉及操作的数据记录从原存储设备迁移至新存储设备的数据流向；

该生成模块用于：

基于该至少一个待优化事务，生成多个不存在冲突的数据分布图，该不存在冲突的数据分布图是指不存在将同一数据记录从原存储设备迁移至多个新存储设备。

在一种可能实施方式中，对任一迁移策略信息，该迁移策略信息的执行代价基于该迁移策略信息的存储代价、通信代价或者负载代价中的至少一项确定得到，该存储代价表征将该待优化事务涉及操作的数据记录以当前存储格式存储时带来的存储开销，该通信代价表征将该待优化事务涉及操作的数据记录从原存储设备迁移至新存储设备的过程中造成的通信开销，该负载代价表征将该待优化事务涉及操作的数据记录迁移至新存储设备后对新存储设备所带来的负载情况。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

需要说明的是：上述实施例提供的事务执行装置在执行涉及批量SQL操作的事务时，仅以上述各功能模块的划分进行举例说明，实际应用中，能够根据需要而将上述功能分配由不同的功能模块完成，即将计算设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的事务执行装置与事务执行方法实施例属于同一构思，其具体实现过程详见事务执行方法实施例，这里不再赘述。

图12是本申请实施例提供的一种计算设备的结构示意图，该计算设备1200可因配置或性能不同而产生比较大的差异，该计算设备1200包括一个或一个以上处理器(CentralProcessing Units，CPU)1201和一个或一个以上的存储器1202，其中，该存储器1202中存储有至少一条计算机程序，该至少一条计算机程序由该一个或一个以上处理器1201加载并执行以实现上述各个实施例提供的事务执行方法。可选地，该计算设备1200还具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该计算设备1200还包括其他用于实现设备功能的部件，在此不做赘述。

在示例性实施例中，还提供了一种计算机可读存储介质，例如包括至少一条计算机程序的存储器，上述至少一条计算机程序可由终端中的处理器执行以完成上述各个实施例中的事务执行方法。例如，该计算机可读存储介质包括ROM(Read-Only Memory，只读存储器)、RAM(Random-Access Memory，随机存取存储器)、CD-ROM(Compact Disc Read-OnlyMemory，只读光盘)、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种计算机程序产品或计算机程序，包括一条或多条程序代码，该一条或多条程序代码存储在计算机可读存储介质中。计算设备的一个或多个处理器能够从计算机可读存储介质中读取该一条或多条程序代码，该一个或多个处理器执行该一条或多条程序代码，使得计算设备能够执行以完成上述实施例中的事务执行方法。

本领域普通技术人员能够理解实现上述实施例的全部或部分步骤能够通过硬件来完成，也能够通过程序来指令相关的硬件完成，可选地，该程序存储于一种计算机可读存储介质中，可选地，上述提到的存储介质是只读存储器、磁盘或光盘等。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (30)

1.一种事务执行方法，其特征在于，所述方法包括：

针对涉及批量结构化查询语言SQL操作的目标事务，确定所述批量SQL操作关联的多条数据记录；

在所述多条数据记录符合相似数据条件的情况下，确定所述多条数据记录所在的目标存储设备，所述目标存储设备用于存储符合所述相似数据条件的数据记录；

向所述目标存储设备下发所述目标事务，以使所述目标存储设备以单机事务的方式执行所述目标事务。

2.根据权利要求1所述的方法，其特征在于，所述相似数据条件包括所述多条数据记录均属于热点数据，所述热点数据用于表征在历史时间段中被频繁访问的数据记录；

所述在所述多条数据记录符合相似数据条件的情况下，确定所述多条数据记录所在的目标存储设备包括：

在所述多条数据记录均属于所述热点数据的情况下，将用于存储所述热点数据的存储设备确定为所述目标存储设备。

3.根据权利要求2所述的方法，其特征在于，所述热点数据包括在所述历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的第一热点数据；

所述在所述多条数据记录均属于热点数据的情况下，将用于存储所述热点数据的存储设备确定为所述目标存储设备包括：

在所述多条数据记录均在所述历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的情况下，将所述多条数据记录均确定为所述第一热点数据，将用于存储所述第一热点数据的存储设备确定为所述目标存储设备。

4.根据权利要求2所述的方法，其特征在于，所述热点数据包括通过特征提取模型筛选得到的第二热点数据，所述特征提取模型用于针对在所述历史时间段内涉及批量SQL操作的历史事务所操作的数据记录提取数据特征，所述第二热点数据的数据特征与第一热点数据的数据特征符合相似条件，所述第一热点数据在所述历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值；

所述在所述多条数据记录均属于热点数据的情况下，将用于存储所述热点数据的存储设备确定为所述目标存储设备包括：

在通过所述特征提取模型对所述多条数据记录各自提取到的数据特征与所述第一热点数据的数据特征符合相似条件的情况下，将所述多条数据记录均确定为所述第二热点数据，将用于存储所述第二热点数据的存储设备确定为所述目标存储设备。

5.根据权利要求1所述的方法，其特征在于，所述相似数据条件包括所述多条数据记录各自的SQL操作语义符合语义关联条件；

所述在所述多条数据记录符合相似数据条件的情况下，确定所述多条数据记录所在的目标存储设备包括：

在所述多条数据记录各自的SQL操作语义符合所述语义关联条件的情况下，将用于存储符合所述语义关联条件的数据记录的存储设备确定为所述目标存储设备。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

在所述多条数据记录仅包括同一数据表的主键记录和二级索引记录的情况下，确定所述多条数据记录各自的SQL操作语义符合所述语义关联条件；或，

在所述多条数据记录在历史时间段中被同一SQL查询事务进行批量SQL操作的频次大于频次阈值的情况下，确定所述多条数据记录各自的SQL操作语义符合所述语义关联条件；或，

在将所述多条数据记录转换到图数据库后，所述多条数据记录各自对应的多个节点中任意两个节点之间存在连接边且所述连接边的边长不超过边长阈值的情况下，确定所述多条数据记录各自的SQL操作语义符合所述语义关联条件。

7.根据权利要求1所述的方法，其特征在于，所述相似数据条件包括所述多条数据记录各自的主键均处于同一主键范围内；

所述在所述多条数据记录符合相似数据条件的情况下，确定所述多条数据记录所在的目标存储设备包括：

在所述多条数据记录各自的主键均处于同一主键范围内的情况下，将用于存储所述主键范围内的数据记录的存储设备确定为所述目标存储设备。

8.根据权利要求1所述的方法，其特征在于，所述方法还包括：

每间隔目标时长，重新确定在所述目标时长内符合所述相似数据条件的数据记录；

将所述目标时长内符合所述相似数据条件的数据记录迁移至分布式数据库系统中计算负载小于负载阈值的存储设备中。

9.根据权利要求8所述的方法，其特征在于，所述相似数据条件包括所述多条数据记录各自的SQL操作语义符合语义关联条件；

所述将所述目标时长内符合所述相似数据条件的数据记录迁移至分布式数据库系统中计算负载小于负载阈值的存储设备中包括：

将所述目标时长内被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的第一热点数据，均迁移至计算负载小于负载阈值的第一存储设备；

将所述目标时长内通过特征提取模型筛选得到的第二热点数据，均迁移至计算负载小于负载阈值的第二存储设备，所述特征提取模型用于针对在所述目标时长内涉及批量SQL操作的历史事务所操作的数据记录提取数据特征，所述第二热点数据的数据特征与所述第一热点数据的数据特征符合相似条件；

将所述目标时长内SQL操作语义符合所述语义关联条件的至少一条数据记录，均迁移至计算负载小于负载阈值的第三存储设备。

10.根据权利要求1所述的方法，其特征在于，所述方法还包括：

基于所述目标事务所关联的业务类型，向所述目标存储设备发送与所述业务类型相匹配的主从切换指令，所述主从切换指令用于指示所述目标存储设备将所述多条数据记录中与所述业务类型适配度最高的副本切换为主副本，以在所述切换完毕的主副本上执行所述目标事务。

11.根据权利要求10所述的方法，其特征在于，在所述业务类型为联机分析处理OLAP业务的情况下，与所述OLAP业务适配度最高的副本为列存副本；或，在所述业务类型为事务联机处理OLTP业务的情况下，与所述OLTP业务适配度最高的副本为行存副本；或，在所述业务类型为OLTP业务且存在二进制日志订阅需求的情况下，与所述OLTP业务适配度最高的副本为携带二进制日志生成功能的副本。

12.根据权利要求1所述的方法，其特征在于，所述方法还包括：

从多个历史事务中筛选得到至少一个待优化事务，所述待优化事务指未以单机事务的方式执行的历史事务；

基于所述至少一个待优化事务，生成多个迁移策略信息，所述迁移策略信息用于指示如何对所述待优化事务涉及操作的数据记录进行重分布；

从所述多个迁移策略信息中，确定执行代价最小的目标策略信息；

基于所述目标策略信息，在分布式数据库系统中，对所述至少一个待优化事务涉及操作的数据记录进行数据迁移。

13.根据权利要求12所述的方法，其特征在于，所述迁移策略信息为数据分布图，所述数据分布图用于指示将所述待优化事务涉及操作的数据记录从原存储设备迁移至新存储设备的数据流向；

所述基于所述至少一个待优化事务，生成多个迁移策略信息包括：

基于所述至少一个待优化事务，生成多个不存在冲突的数据分布图，所述不存在冲突的数据分布图是指不存在将同一数据记录从原存储设备迁移至多个新存储设备。

14.根据权利要求12所述的方法，其特征在于，对任一迁移策略信息，所述迁移策略信息的执行代价基于所述迁移策略信息的存储代价、通信代价或者负载代价中的至少一项确定得到，所述存储代价表征将所述待优化事务涉及操作的数据记录以当前存储格式存储时带来的存储开销，所述通信代价表征将所述待优化事务涉及操作的数据记录从原存储设备迁移至新存储设备的过程中造成的通信开销，所述负载代价表征将所述待优化事务涉及操作的数据记录迁移至新存储设备后对新存储设备所带来的负载情况。

15.一种事务执行装置，其特征在于，所述装置包括：

第一确定模块，用于针对涉及批量结构化查询语言SQL操作的目标事务，确定所述批量SQL操作关联的多条数据记录；

第二确定模块，用于在所述多条数据记录符合相似数据条件的情况下，确定所述多条数据记录所在的目标存储设备，所述目标存储设备用于存储符合所述相似数据条件的数据记录；

下发模块，用于向所述目标存储设备下发所述目标事务，以使所述目标存储设备以单机事务的方式执行所述目标事务。

16.根据权利要求15所述的装置，其特征在于，所述相似数据条件包括所述多条数据记录均属于热点数据，所述热点数据用于表征在历史时间段中被频繁访问的数据记录；

所述第二确定模块包括：

第一确定单元，用于在所述多条数据记录均属于所述热点数据的情况下，将用于存储所述热点数据的存储设备确定为所述目标存储设备。

17.根据权利要求16所述的装置，其特征在于，所述热点数据包括在所述历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的第一热点数据；

所述第一确定单元用于：

在所述多条数据记录均在所述历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的情况下，将所述多条数据记录均确定为所述第一热点数据，将用于存储所述第一热点数据的存储设备确定为所述目标存储设备。

18.根据权利要求16所述的装置，其特征在于，所述热点数据包括通过特征提取模型筛选得到的第二热点数据，所述特征提取模型用于针对在所述历史时间段内涉及批量SQL操作的历史事务所操作的数据记录提取数据特征，所述第二热点数据的数据特征与第一热点数据的数据特征符合相似条件，所述第一热点数据在所述历史时间段中被访问次数大于访问次数阈值或被修改次数大于修改次数阈值；

所述第一确定单元用于：

在通过所述特征提取模型对所述多条数据记录各自提取到的数据特征与所述第一热点数据的数据特征符合相似条件的情况下，将所述多条数据记录均确定为所述第二热点数据，将用于存储所述第二热点数据的存储设备确定为所述目标存储设备。

19.根据权利要求15所述的装置，其特征在于，所述相似数据条件包括所述多条数据记录各自的SQL操作语义符合语义关联条件；

所述第二确定模块包括：

第二确定单元，用于在所述多条数据记录各自的SQL操作语义符合所述语义关联条件的情况下，将用于存储符合所述语义关联条件的数据记录的存储设备确定为所述目标存储设备。

20.根据权利要求19所述的装置，其特征在于，所述第二确定单元还用于：

在所述多条数据记录仅包括同一数据表的主键记录和二级索引记录的情况下，确定所述多条数据记录各自的SQL操作语义符合所述语义关联条件；或，

在所述多条数据记录在历史时间段中被同一SQL查询事务进行批量SQL操作的频次大于频次阈值的情况下，确定所述多条数据记录各自的SQL操作语义符合所述语义关联条件；或，

在将所述多条数据记录转换到图数据库后，所述多条数据记录各自对应的多个节点中任意两个节点之间存在连接边且所述连接边的边长不超过边长阈值的情况下，确定所述多条数据记录各自的SQL操作语义符合所述语义关联条件。

21.根据权利要求15所述的装置，其特征在于，所述相似数据条件包括所述多条数据记录各自的主键均处于同一主键范围内；

所述第二确定模块还用于：

在所述多条数据记录各自的主键均处于同一主键范围内的情况下，将用于存储所述主键范围内的数据记录的存储设备确定为所述目标存储设备。

22.根据权利要求15所述的装置，其特征在于，所述装置还包括：

重新确定模块，用于每间隔目标时长，重新确定在所述目标时长内符合所述相似数据条件的数据记录；

第一迁移模块，用于将所述目标时长内符合所述相似数据条件的数据记录迁移至分布式数据库系统中计算负载小于负载阈值的存储设备中。

23.根据权利要求22所述的装置，其特征在于，所述相似数据条件包括所述多条数据记录各自的SQL操作语义符合语义关联条件；

所述第一迁移模块用于：

将所述目标时长内被访问次数大于访问次数阈值或被修改次数大于修改次数阈值的第一热点数据，均迁移至计算负载小于负载阈值的第一存储设备；

将所述目标时长内通过特征提取模型筛选得到的第二热点数据，均迁移至计算负载小于负载阈值的第二存储设备，所述特征提取模型用于针对在所述目标时长内涉及批量SQL操作的历史事务所操作的数据记录提取数据特征，所述第二热点数据的数据特征与所述第一热点数据的数据特征符合相似条件；

将所述目标时长内SQL操作语义符合所述语义关联条件的至少一条数据记录，均迁移至计算负载小于负载阈值的第三存储设备。

24.根据权利要求15所述的装置，其特征在于，所述下发模块还用于：

基于所述目标事务所关联的业务类型，向所述目标存储设备发送与所述业务类型相匹配的主从切换指令，所述主从切换指令用于指示所述目标存储设备将所述多条数据记录中与所述业务类型适配度最高的副本切换为主副本，以在所述切换完毕的主副本上执行所述目标事务。

25.根据权利要求24所述的装置，其特征在于，在所述业务类型为OLAP业务的情况下，与所述OLAP业务适配度最高的副本为列存副本；或，在所述业务类型为OLTP业务的情况下，与所述OLTP业务适配度最高的副本为行存副本；或，在所述业务类型为OLTP业务且存在二进制日志订阅需求的情况下，与所述OLTP业务适配度最高的副本为携带二进制日志生成功能的副本。

26.根据权利要求15所述的装置，其特征在于，所述装置还包括：

筛选模块，用于从多个历史事务中筛选得到至少一个待优化事务，所述待优化事务指未以单机事务的方式执行的历史事务；

生成模块，用于基于所述至少一个待优化事务，生成多个迁移策略信息，所述迁移策略信息用于指示如何对所述待优化事务涉及操作的数据记录进行重分布；

第三确定模块，用于从所述多个迁移策略信息中，确定执行代价最小的目标策略信息；

第二迁移模块，用于基于所述目标策略信息，在分布式数据库系统中，对所述至少一个待优化事务涉及操作的数据记录进行数据迁移。

27.根据权利要求26所述的装置，其特征在于，所述迁移策略信息为数据分布图，所述数据分布图用于指示将所述待优化事务涉及操作的数据记录从原存储设备迁移至新存储设备的数据流向；

所述生成模块用于：

基于所述至少一个待优化事务，生成多个不存在冲突的数据分布图，所述不存在冲突的数据分布图是指不存在将同一数据记录从原存储设备迁移至多个新存储设备。

28.根据权利要求26所述的装置，其特征在于，对任一迁移策略信息，所述迁移策略信息的执行代价基于所述迁移策略信息的存储代价、通信代价或者负载代价中的至少一项确定得到，所述存储代价表征将所述待优化事务涉及操作的数据记录以当前存储格式存储时带来的存储开销，所述通信代价表征将所述待优化事务涉及操作的数据记录从原存储设备迁移至新存储设备的过程中造成的通信开销，所述负载代价表征将所述待优化事务涉及操作的数据记录迁移至新存储设备后对新存储设备所带来的负载情况。

29.一种计算设备，其特征在于，所述计算设备包括一个或多个处理器和一个或多个存储器，所述一个或多个存储器中存储有至少一条计算机程序，所述至少一条计算机程序由所述一个或多个处理器加载并执行以实现如权利要求1至权利要求14任一项所述的事务执行方法。

30.一种存储介质，其特征在于，所述存储介质中存储有至少一条计算机程序，所述至少一条计算机程序由处理器加载并执行以实现如权利要求1至权利要求14任一项所述的事务执行方法。

Images