CN115080670A - 一种基于gpu加速的确定性事务并发控制方法 - Google Patents

Abstract

一种基于GPU加速的确定性事务并发控制方法，属于数据库事务处理领域；本发明将数据库事务迁移至GPU进行处理，将事务分解成单个读取操作或写入操作，后在GPU中按照先并行处理读取操作，后并行处理写入操作的顺序执行事务；在执行事务之后对事务进行事务内冲突检测和事务间冲突检测，并在完成两种检测后进行事务提交；本方法实现了事务内与事务间的无锁定全并发策略，并且在整体事务迁移到GPU执行前仅需确定事务的读写集，并不需要构造依赖图等计算资源消耗高的事务执行依赖数据，仅需在事务执行完成之后对其中的冲突进行检测。

Description

一种基于GPU加速的确定性事务并发控制方法

技术领域

本发明属于数据库事务处理领域，具体涉及一种基于GPU加速的确定性事务并发控制方法。

背景技术

事务处理是数据库中的经典问题。数据库事务就是指作为单个逻辑单元执行的一系列操作。现使用网上购物的一次交易来说明事务的含义。例如，一次完整的网上购物交易流程，至少包括以下几个对数据库的操作：1)更新客户所选商品的库存信息，2)保存客户付款信息，3)生成订单并保存在数据库中，4)更新用户相关信息。正常情况下，以上操作都顺利进行，最终会完成一次网络购物，并且与交易相关的所有数据库信息也成功的更新。但是，如果某一个环节出现了问题，那么整个交易都会失败。一旦失败，数据库中所有信息都必须保持在提交前的状态不变，而数据库的事务正是用来保障这种情况下交易的平稳性和预测性的技术。

BOHM是一个单节点确定性数据库，分两步运行事务。第一步，将每个输入事务的写入集的主键占位符与事务ID一起插入到多版本存储层中。第二步，事务必须为其读取集中的每个键读取一个特定版本——具有最大TID的那个，直到事务的TID——以强制执行确定性。当事务读取集中的所有键都准备好时，事务可以执行并更新之前插入的占位符。为了避免在将占位符插入存储层时发生争用，BOHM中的每个工作线程都会扫描所有输入事务以在其自己的分区中查找要更新的主键。

PWV是一个单节点确定性数据库，首先将每个输入事务分解为一组片段(即子事务)，使得每个片段只读取或写入一个分区。接下来它构建一个依赖图，其中一条边表示分区内的片段之间的冲突，并使用它来调度每个片段的执行以满足数据依赖和提交依赖的要求。

Aria是一个分布式确定性OLTP数据库，分两步执行事务。第一步，每个事务从数据库的当前快照中读取，并将写入保存在本地写入集中。其采用单版本方法，即使它缓冲写入事务直到批处理结束。一旦批处理中的所有事务在副本上完成执行，它就会进入提交阶段。副本上的提交阶段也运行在多个工作线程上，每个工作线程独立执行。在提交阶段，线程中止执行与早期事务冲突操作的事务，即具有较小TID的事务。例如，如果一个事务读取了由某个较早事务修改的记录，它就会中止。中止的事务会在下一批开始时自动安排执行，除非事务被显式的中止。如果事务与之前的事务没有冲突，系统会将其更改应用到数据库。

在单CPU上做事务处理，事务内以及事务间的并发效果并不是很好。

BOHM的缺陷在于，每个工作线程都会扫描所有输入事务以在其自己的分区中查找要更新的主键，在预处理阶段消耗量大量的计算资源。

PWV的缺陷在于，其以更细粒度的片段而不是整个事务来提交每个事务的写入，虽然后续事务会花更少的时间等待查看早期事务的写入，但代价是更昂贵的细粒度依赖图分析。

Calvin的缺陷在于，在多核机器中，一个单线程锁管理器很难使系统资源饱和，因为许多工作线程处于空闲状态等待锁。为了解决这个问题，可以将数据库划分为每台机器的多个分区，但这会通过引入更多的多分区事务来引入额外的开销，这些事务会因冗余执行而产生开销。

Aria的问题在于，由于CPU的线程数的限制，单批次事务数量有限，且采取事务内串行执行各个操作的策略。虽然其不需要提前知道事务执行前的情况，但其在单机上事务并发性做的并不好。

发明内容

针对现有技术的不足，本发明设计一种基于GPU加速的确定性事务并发控制方法；

一种基于GPU加速的确定性事务并发控制方法，具体包括以下步骤：

步骤1：CPU接收事务，解析事务请求并积累事务，在CPU收到事务请求之后，将事务解析成读写集，并赋予每个事务独立的事务ID，即TID；为每个事务内的读写操作赋予独立的操作ID，即OID；同时从数据库中获取当前数据库状态的快照，快照即数据库在某一时间点的视图，为后续事务执行做好准备；事务采取的是计算机随机生成一系列读写操作；

步骤2：采取四个线程作为一个协作组处理一个事务；整体采取先执行读操作，后执行写操作来执行事务，即将事务看成是读写操作集合，并发执行各项操作以达到更好的效果；同时对事务内各操作进行事务冲突检测，保证事务的原子性；所述线程是GPU中的一种计算资源，在启动GPU进行计算的时候预先分配线程数量让其调用；

步骤2.1：读操作阶段：协作组的每个线程通过协作组函数thread_rank获取当前线程在协作组中的线程ID，以此为处理读操作的次序；在读操作执行前，先将需要操作的数据库中数据拷贝到本地读写集中，避免直接操作快照中数据而造成数据不一致；进行完读操作后将下一个要操作的操作ID设置为当前操作ID+4，并进行下一个操作；直至所有事务中的读操作均执行完毕；

步骤2.2：写操作阶段：协作组的每个线程通过协作组函数thread_rank获取当前线程在协作组中的线程ID，以此为处理写操作的次序；在写操作之前，将要操作的数据保存到本地读写集中，避免直接操作快照中数据而造成数据不一致；然后再对数据进行写入操作，写入操作的结果也保存到本地读写集中；进行完读操作后将下一个要操作的操作ID设置为当前操作ID+4，并进行下一个操作；直至所有事务中的写操作均执行完毕；

步骤2.3：事务内冲突检测阶段：协作组的每个线程通过协作组函数thread_rank获取当前线程在协作组中的线程ID，以此为检测冲突的次序；由于每个线程处理的数据各不相同，且不涉及大规模同时对某一数据的写入操作，故有很好的并发效果；在检测过程中，若存在冲突，则修改读写集中INSIDE_STATE，设置为事务内存在异常状态，并在下一批处理中进行串行化处理；在事务内部分，检测冲突的标准为事务内各操作不存在RAW，WAR，WAW冲突；若检测完成且不存在上述冲突，则进入步骤3；

步骤3：进行事务间冲突检测，即在事务进行读写操作提交结果前与其他事物操作进行的冲突检测，将GPU中的所有线程四个线程为一组，然后每四个线程处理一个事务的冲突检测；

步骤3.1：协作组的每个线程通过协作组函数thread_rank获取当前线程在协作组中的线程ID，以此为冲突检测的次序；若事务的INSIDE_STATE为异常状态，则跳过不进行外部冲突检测；

步骤3.2：协作组每个线程分别调用RAW，WAR，WAW检测函数，对正在检测的事务内读取或者写入操作与其他事务的读取或者写入操作是否存在相应的冲突进行检测；其中，其他事务仅指事务ID比正在检测的事务小的事务；若存在冲突，则将本事务内对应冲突的标记设置为“存在冲突”，以便后续提交阶段使用；事务不存在WAW，且不存在WAR和RAW；事务不存在WAW，WAR与RAW存在一种，即可认为该事务不存在冲突，这是一种逻辑上对事务的重排序，很大程度的减少事务冲突导致的事务中止，进而导致的计算资源重复消耗；

步骤4：按照步骤2事务内冲突检测结果以及步骤3事务间冲突检测结果进行提交前审查；

步骤4.1：通过提交前检测，若无事务内部及外部冲突，则提交；提交时将事务内本地数据集中数据写回快照中；CPU内存中的数据通过将事务返回CPU时进行持久化记录；

步骤4.2：若内部存在冲突，则分两种情况：

情况1：外部无冲突，则在提交阶段结束后按照事务内串行化，事务间并行化执行；执行之后进行冲突检测和提交操作，避免消耗过多带宽和内存资源；

情况2：外部有冲突，则在CPU接收下一批事务时优先按照事务内串行化执行该事务；

步骤4.3：若外部存在冲突，则返回事务到CPU，与下一批事务传入GPU，且在下一批事务获取事务ID时保持原有事务ID不变，即保存了小的事务ID，在冲突检测中相对优先的执行。

本发明有益技术效果：

本发明提出一种利用GPU强大的计算能力，加速事务处理速度的确定性事务并发处理算法。为了加大事务间并发性，增加事务内并发性并保证事务原子性，通过控制分支分歧以及利用协作组能够实现更细粒度线程同步的特性来实现事务的大规模并发以及减少冲突导致的资源消耗。

本发明将事务处理部分移植到GPU中，控制分支分歧使得GPU资源得到最大化利用，采用协作组分组同步使得调度GPU线程变得更加灵活，可以按照具体事务的操作情况配置协作组线程数量。同时为了避免多次传输消耗PCI-E的带宽资源。

附图说明

图1本发明实施例确定性事务并发控制算法示意图；

图2本发明实施例一种基于GPU加速的确定性事务并发控制方法测试效果图；

图3本发明实施例一种基于GPU加速的确定性事务并发控制方法CPU和GPU间的逻辑架构；

图4本发明实施例一种基于GPU加速的确定性事务并发控制方法CPU和GPU间在硬件系统上的表现形式；其中TID表示事务ID。

具体实施方式

下面结合附图和实施例对本发明做进一步说明；

GPU从结构上来讲，通常包括通用计算单元，控制器和寄存器。由于其具有高并行结构，GPU在处理图形数据和复杂算法方面具有比CPU更高的效率。GPU拥有比CPU更多的ALU，即逻辑运算单元，使其可以在同一时间并行处理多个数据。

现如今GPU已经有向通用图形处理器，即GPGPU，的发展趋势，这就意味着GPGPU会承担许多原本有CPU处理的计算任务，其面对单指令多数据流(SIMD)且数据处理的运算量远大于数据调度和传输的需要时，通用图形处理器在性能上大大超越了传统的中央处理器。

一种基于GPU加速的确定性事务并发控制方法，如附图1所示，具体包括以下步骤：

步骤1：CPU接收事务，解析事务请求并积累事务，在CPU收到事务请求之后，将事务解析成读写集，并赋予每个事务独立的事务ID，即TID；为每个事务内的读写操作赋予独立的操作ID，即OID；同时从数据库中获取当前数据库状态的快照，快照即数据库在某一时间点的视图，为后续事务执行做好准备；事务采取的是计算机随机生成一系列读写操作；

步骤2：采取四个线程作为一个协作组处理一个事务；整体采取先执行读操作，后执行写操作来执行事务，即将事务看成是读写操作集合，并发执行各项操作以达到更好的效果；同时对事务内各操作进行事务冲突检测，保证事务的原子性；所述线程是GPU中的一种计算资源，在启动GPU进行计算的时候预先分配线程数量让其调用；

步骤2.1：读操作阶段：协作组的每个线程通过协作组函数thread_rank获取当前线程在协作组中的线程ID，以此为处理读操作的次序；在读操作执行前，先将需要操作的数据库中数据拷贝到本地读写集中，避免直接操作快照中数据而造成数据不一致；进行完读操作后将下一个要操作的操作ID设置为当前操作ID+4，并进行下一个操作；直至所有事务中的读操作均执行完毕；

步骤2.2：写操作阶段：协作组的每个线程通过协作组函数thread_rank获取当前线程在协作组中的线程ID，以此为处理写操作的次序；在写操作之前，将要操作的数据保存到本地读写集中，避免直接操作快照中数据而造成数据不一致；然后再对数据进行写入操作，写入操作的结果也保存到本地读写集中；进行完读操作后将下一个要操作的操作ID设置为当前操作ID+4，并进行下一个操作；直至所有事务中的写操作均执行完毕；

步骤2.3：事务内冲突检测阶段：协作组的每个线程通过协作组函数thread_rank获取当前线程在协作组中的线程ID，以此为检测冲突的次序；由于每个线程处理的数据各不相同，且不涉及大规模同时对某一数据的写入操作，故有很好的并发效果；在检测过程中，若存在冲突，则修改读写集中INSIDE_STATE，设置为事务内存在异常状态，并在下一批处理中进行串行化处理；在事务内部分，检测冲突的标准为事务内各操作不存在RAW，WAR，WAW冲突；若检测完成且不存在上述冲突，则进入步骤3；

步骤3：进行事务间冲突检测，即在事务进行读写操作提交结果前与其他事物操作进行的冲突检测，将GPU中的所有线程四个线程为一组，然后每四个线程处理一个事务的冲突检测；

步骤3.1：协作组的每个线程通过协作组函数thread_rank获取当前线程在协作组中的线程ID，以此为冲突检测的次序；若事务的INSIDE_STATE为异常状态，则跳过不进行外部冲突检测；

步骤3.2：协作组每个线程分别调用RAW，WAR，WAW检测函数，对正在检测的事务内读取或者写入操作与其他事务的读取或者写入操作是否存在相应的冲突进行检测；其中，其他事务仅指事务ID比正在检测的事务小的事务；若存在冲突，则将本事务内对应冲突的标记设置为“存在冲突”，以便后续提交阶段使用；事务不存在WAW，且不存在WAR和RAW；事务不存在WAW，WAR与RAW存在一种，即可认为该事务不存在冲突，这是一种逻辑上对事务的重排序，很大程度的减少事务冲突导致的事务中止，进而导致的计算资源重复消耗；

步骤4：按照步骤2事务内冲突检测结果以及步骤3事务间冲突检测结果进行提交前审查；附图3为CPU和GPU间的逻辑架构；图4为CPU和GPU间在硬件系统上的表现形式；其中TID表示事务ID。

步骤4.1：通过提交前检测，若无事务内部及外部冲突，则提交；提交时将事务内本地数据集中数据写回快照中；CPU内存中的数据通过将事务返回CPU时进行持久化记录；

步骤4.2：若内部存在冲突，则分两种情况：

情况1：外部无冲突，则在提交阶段结束后按照事务内串行化，事务间并行化执行；执行之后进行冲突检测和提交操作，避免消耗过多带宽和内存资源；

情况2：外部有冲突，则在CPU接收下一批事务时优先按照事务内串行化执行该事务；

步骤4.3：若外部存在冲突，则返回事务到CPU，与下一批事务传入GPU，且在下一批事务获取事务ID时保持原有事务ID不变，即保存了小的事务ID，在冲突检测中相对优先的执行。

图2为本发明测试结果，其中横轴为TPC-C基准测试中的仓库数量，纵轴为事务测试通常使用的“每秒运行事务数量”，即Tps。在测试中，可以看出尽管随着仓库数量的增加，系统执行速度也随之下降，这可能与数据库规模扩大导致的访存时间增加相关。在仓库数小于20的情况下，整体事务执行速度可以达到200K以上，这样的效率相比Mysql快了200倍以上。

采用本发明所述的确定性事务并发控制方法法，对tpcc中非范围扫描的两个事务，New-Order和Payment事务，另外三个事务涉及范围查找，故目前不支持。由于GPU的内存大小限制，仓库数量不能达到众多分布式数据库系统所支持的成百上千。在2，4，6，8，10，20，40，60，80，100的仓库中进行tpcc测试，结果表明，每批次事务的数量与每批次线程数量对事务执行速度有很大的影响，仓库数量对事务发生冲突并进行重执行操作有很大影响。从实验结果来看，采用GPU执行事务效果很好，基本达到开始为了提高事务间并发性，并对事务内并发性且保证事务原子性的设计目的。

Claims (7)

1.一种基于GPU加速的确定性事务并发控制方法，其特征在于，具体包括以下步骤：

步骤1：CPU接收事务，解析事务请求并积累事务，在CPU收到事务请求之后，将事务解析成读写集，并赋予每个事务独立的事务ID，即TID；为每个事务内的读写操作赋予独立的操作ID，即OID；同时从数据库中获取当前数据库状态的快照，快照即数据库在某一时间点的视图，为后续事务执行做好准备；

步骤2：采取四个线程作为一个协作组处理一个事务；整体采取先执行读操作，后执行写操作来执行事务，即将事务看成是读写操作集合，并发执行各项操作以达到更好的效果；同时对事务内各操作进行事务冲突检测，保证事务的原子性；若检测完成且不存在冲突，则进入步骤3；

步骤3：进行事务间冲突检测，即在事务进行读写操作提交结果前与其他事物操作进行的冲突检测，将GPU中的所有线程四个线程为一组，然后每四个线程处理一个事务的冲突检测；

步骤4：按照步骤2事务内冲突检测结果以及步骤3事务间冲突检测结果进行提交前审查。

2.根据权利要求1所述的一种基于GPU加速的确定性事务并发控制方法，其特征在于，步骤1所述事务采取的是计算机随机生成一系列读写操作。

3.根据权利要求1所述的一种基于GPU加速的确定性事务并发控制方法，其特征在于，步骤2所述线程是GPU中的一种计算资源，在启动GPU进行计算的时候预先分配线程数量让其调用。

4.根据权利要求1所述的一种基于GPU加速的确定性事务并发控制方法，其特征在于，步骤2具体为：

步骤2.1：读操作阶段：协作组的每个线程通过协作组函数thread_rank获取当前线程在协作组中的线程ID，以此为处理读操作的次序；在读操作执行前，先将需要操作的数据库中数据拷贝到本地读写集中，避免直接操作快照中数据而造成数据不一致；进行完读操作后将下一个要操作的操作ID设置为当前操作ID+4，并进行下一个操作；直至所有事务中的读操作均执行完毕；

步骤2.2：写操作阶段：协作组的每个线程通过协作组函数thread_rank获取当前线程在协作组中的线程ID，以此为处理写操作的次序；在写操作之前，将要操作的数据保存到本地读写集中，避免直接操作快照中数据而造成数据不一致；然后再对数据进行写入操作，写入操作的结果也保存到本地读写集中；进行完读操作后将下一个要操作的操作ID设置为当前操作ID+4，并进行下一个操作；直至所有事务中的写操作均执行完毕；

步骤2.3：事务内冲突检测阶段：协作组的每个线程通过协作组函数thread_rank获取当前线程在协作组中的线程ID，以此为检测冲突的次序；由于每个线程处理的数据各不相同，且不涉及大规模同时对某一数据的写入操作，故有很好的并发效果；在检测过程中，若存在冲突，则修改读写集中INSIDE_STATE，设置为事务内存在异常状态，并在下一批处理中进行串行化处理；在事务内部分，检测冲突的标准为事务内各操作不存在RAW，WAR，WAW冲突；若检测完成且不存在上述冲突，则进入步骤3。

5.根据权利要求1所述的一种基于GPU加速的确定性事务并发控制方法，其特征在于，步骤3具体为：

步骤3.1：协作组的每个线程通过协作组函数thread_rank获取当前线程在协作组中的线程ID，以此为冲突检测的次序；若事务的INSIDE_STATE为异常状态，则跳过不进行外部冲突检测；

步骤3.2：协作组每个线程分别调用RAW，WAR，WAW检测函数，对正在检测的事务内读取或者写入操作与其他事务的读取或者写入操作是否存在相应的冲突进行检测；其中，其他事务仅指事务ID比正在检测的事务小的事务；若存在冲突，则将本事务内对应冲突的标记设置为“存在冲突”，以便后续提交阶段使用；事务不存在WAW，且不存在WAR和RAW；事务不存在WAW，WAR与RAW存在一种，即可认为该事务不存在冲突，这是一种逻辑上对事务的重排序，很大程度的减少事务冲突导致的事务中止，进而导致的计算资源重复消耗。

6.根据权利要求1所述的一种基于GPU加速的确定性事务并发控制方法，其特征在于，步骤4具体为：

步骤4.1：通过提交前检测，若无事务内部及外部冲突，则提交；提交时将事务内本地数据集中数据写回快照中；CPU内存中的数据通过将事务返回CPU时进行持久化记录；

步骤4.2：若内部存在冲突，则分两种情况进行处理：

步骤4.3：若外部存在冲突，则返回事务到CPU，与下一批事务传入GPU，且在下一批事务获取事务ID时保持原有事务ID不变，即保存了小的事务ID，在冲突检测中相对优先的执行。

7.根据权利要求6所述的一种基于GPU加速的确定性事务并发控制方法，其特征在于，步骤4.2所述两种情况具体为：

情况1：外部无冲突，则在提交阶段结束后按照事务内串行化，事务间并行化执行；执行之后进行冲突检测和提交操作，避免消耗过多带宽和内存资源；

情况2：外部有冲突，则在CPU接收下一批事务时优先按照事务内串行化执行该事务。

Images