TL;DR 本文介绍了一个新的确定性 OLTP 数据库，Aria 不需要在运行一个事务之前知道它的读/写集，并在很多基准集上取得了比现有的确定性数据库更好的性能。我们会在九月初的VLDB上介绍这个工作，欢迎大家来参加，链接如下：Conference Program (Flat Version) - VLDB2020 Tokyo
作者：Yi Lu, Xiangyao Yu, Lei Cao, Samuel Madden
论文链接：http://www.vldb.org/pvldb/vol13/p2047-lu.pdf
代码链接：https://github.com/luyi0619/aria
作者联系方式：yilu AT alum DOT mit DOT edu
ABSTRACT/摘要
确定性数据库能够有效地且无需协调地跨不同副本运行事务。但是，现有最前沿的的确定性数据库要求在执行事务之前就知道事务的读/写集，这使得确定性数据库在许多 OLTP 应用中不切合实际。在本文中，我们将介绍 Aria，它是一个没有这种限制的新的分布式确定性 OLTP 数据库。 Aria背后的关键思想是，它首先在执行阶段针对同一数据库快照执行一批事务，然后确定地（在副本之间也无需进行通信）选择应提交的事务，以确保在提交阶段事务的可串行化「serializability」。我们还提出了一种新颖的确定性重排序机制，该机制允许 Aria 以减少冲突数量为目标对事务进行排序。我们在八个节点的群集上进行的实验表明，在两个流行的基准（YCSB 和 TPC-C）上，Aria比传统的非确定性并发控制算法和最前沿的确定性数据库的性能要高出两倍。
1. INTRODUCTION/引言
现代数据库系统使用冗余「Replication」来实现高可用性，并使用数据分区来进行横向扩展。 冗余允许系统提供高可用性，即对机器故障的容错，但也需要进行额外的网络往返，以确保各副本间写入的一致性。 跨多个节点进行分区可以使系统获得更好的横向扩展。 但是，大多数数据库实现要求使用两阶段提交「2PC」 来解决由并发控制中的不确定事件（例如系统故障和竞争危害「race condition」）引起的问题。 这给分布式事务增加了额外的延迟，并损害了可扩展性和可用性（例如，由于协调器故障 「coordinator failures」）。
确定性并发控制算法提供了一种构建分布式和高可用性数据库系统的新方法。 它们通过确保不同的副本始终独立地产生相同的结果（只要给出了相同的输入事务）来避免使用昂贵的提交和复制协议。 因此，确定性数据库不必复制和同步分布式事务的更新，而只需跨不同副本复制输入事务。这可以异步完成，并且通常需要较少的通信。 另外，确定性数据库避免使用两阶段提交，因为它们自然地消除了并发控制中的不确定性竞争危害，并且能够通过重新执行相同的原始输入事务来从系统故障中恢复。
最新的确定性数据库 BOHM，PWV 和 Calvin 通过依赖关系图或有序锁来实现确定性。 BOHM 和 PWV 中的关键思想是，先基于一批输入事务的读写集构建依赖关系图。这样，只要事务按照依赖关系图运行，数据库就可以产生确定性的结果。 Calvin 中的关键思想是在执行事务之前并根据输入事务的顺序获取读/写锁。一旦获得所需的锁，便将事务分配给工作线程以执行。如图1左侧所示，现有确定性数据库在事务执行之前执行依赖关系分析，这要求先验地知道事务的读/写集。对于非常简单的事务，例如仅通过主键上去查找访问记录，可以轻松完成。但是，实际上，许多事务需要通过非主键去访问记录。对于此类查询，这些系统必须至少执行两次查询：一次确定读/写集，一次执行查询，如果两次执行之间的读/写集发生更改，则可能执行更多次。此外，Calvin 要求每个数据库分区使用单线程锁管理器，这极大地限制了它可以实现的并发性。
图1： Aria, BOHM, PWV 和 Calvin 的比较
在本文中，我们提出了一种新的数据库系统 Aria，其以完全不同的机制解决了以前的确定性 OLTP 数据库中的限制，该机制不需要对任何输入事务进行分析或预先执行。 Aria 分批运行事务。其关键思想是每个副本在相同的数据库快照上运行同一批事务，并以相同的方式解决冲突，从而确保确定性的执行。如图1的右侧所示，每个副本从数据库的当前快照读取并在执行阶段执行所有事务直至完成，然后确定地选择应提交哪些事务以及应该中止哪些事务以确保在提交阶段可串行化。为了获得良好的可伸缩性和较高的事务吞吐量，在提交阶段的可串行性检查将在每个事务上并行执行，并且不需要中央协调。中止的事务将安排在下一批事务开始时重新执行。这样，Aria 可以实现确定性地运行事务，而无需事先知道输入事务的读写集。需要注意地是，尽管乐观并发控制（OCC）算法也可以在执行后解决冲突，但是 OCC 中的事务可以根据线程调度的变化以不确定的顺序提交，这与Aria有本质的不同。
我们还介绍了一种新颖的确定性重排序机制，为减少冲突和提高Aria的吞吐量带来了新的机会。与现有的确定性数据库严格按照输入的顺序执行事务不同，我们的重新排序机制使Aria能够以减少中止事务的数量为目的来提交事务。此外，作为识别中止事务的过程中的一部分，重新排序是并行进行的，并且有极小的执行开销。
我们在单个多核节点上的评估表明，Aria 在 YCSB 上的性能大大优于传统的非确定性并发控制算法和最新的确定性数据库。此外，通过对具有偏态分布「skewed access」访问的 YCSB 工作负载进行确定性的重新排序，Aria能够实现高达三倍的更高事务吞吐量。在其中存在更多冲突的 TPC-C 的子集上，Aria 取得了与 PWV 相似的性能，并且比所有其他确定性数据库具有更高的性能。我们对在 Amazon EC2 上运行的八个节点的群集进行的评估表明，在 YCSB 和 TPC-C 上，Aria 的性能要比 Calvin 高出两倍。最后，我们显示 Aria 在16个节点上有近乎线性的可伸缩性。
总而言之，我们做出以下主要贡献：
我们介绍了 Aria，这是一种新的快速实用的确定性 OLTP 数据库。 它支持确定性事务执行，而无需任何输入事务的先验知识。
我们引入了确定性的重新排序方案使得在 Aria 的提交阶段减少冲突。
我们描述了 Aria 的实现，并用两个流行基准的进行了详细评估。 总体而言，Aria 在单个节点上的性能超过了最新的确定性数据库，并在八个节点的群集上取得了两倍的性能提高。
2. BACKGROUND/背景
在本节中，我们将对现有的不确定性和确定性并发控制协议如何使用冗余作为实现高可用性进行总结.
Replication in Nondeterministic Databases/不确定数据库中的冗余
高可用性系统通常会在多台计算机之间复制数据，这样一台或多台服务器出现故障时，系统仍会提供一定程度的可用性。我们将现有的复制策略大致分为两类：（1）异步复制和（2）同步复制。在异步复制中，数据在副本之间异步传播，这意味着事务可以在写入到达所有副本之前提交。异步复制减少了提交事务的等待时间，但是在发生故障时可能会遭受数据丢失的困扰。相反，在同步复制中，在事务提交之前，会确保写已经到达了所有副本。同步复制增加了等待时间，但是确保了副本之间的强一致性，并且一直是学术界与工业界最近关注的问题。
大多数事务处理系统都提供可序列化性，这要求数据库的结果是事务按照某些串行顺序执行产生的。大多数并发控制算法（例如，乐观并发控制和严格的两阶段加锁）都是不确定性的，这意味着在给定相同输入的情况下，由于副本执行事务的时间和线程调度的不同，不同的副本在并行事务上的结果会有差异。因此，需要确保副本之间的一致性。大多数复制协议都采用主丛备份方案或状态机复制方案。在主丛数据库备份系统中，主数据库运行事务并将结果传送到一个或多个备份中。备份将更改应用到数据库中，并定期向主数据库确认写完成的状态。在确认备份写入后，主数据库即可提交事务。在使用状态机复制的系统中，事务可以在任何副本上运行，但是读/写操作需要使用共识协议「consensus protocols」（例如 Paxos 或 Raft）进行排序。因此，非确定性系统能够保持一致，但是受到若干限制，包括需要多轮同步通信来提交事务，以及需要同步通常较大的输出值而不是较小的输入操作。
Deterministic Concurrency Control/确定性并发控制
确定性并发控制算法被提出来解决这些挑战。在确定性数据库中，每个副本都确定性地运行相同的一组有序事务，并将数据库从相同的初始状态转换为相同的最终状态。通常，在这些系统中，事务在执行之前首先要经过一个排序层「sequencing layer」。此排序层充当客户端和数据库之间的中间层，并确定客户端提交的事务的顺序。通常，排序层在多台机器上运行，以避免出现单点故障，并通过在 Paxos 或 Raft 实例上构建的复制日志来达成共识。为了避免不确定性（例如，由于获取当前时间或生成随机数的系统调用），排序层会对传入的事务进行预处理，以在传递给副本之前通过用常数值替换此类函数调用来消除此不确定性。因此，副本无需相互通信即可保持一致，从而使复制更简单，更高效。另外，确定性数据库还通过避免两阶段提交（2PC）来减少分布式事务的开销。在不确定性数据库中，2PC 用来确保分布式事务中的参与节点可以达成相同的提交/中止决策。相反，一个参与节点的故障不会影响确定性数据库中事务的提交/中止决策。
最近，有人提出了基于依赖图或有序锁的确定性协议，以在确保确定性的同时提供更多的并行性。尽管上述系统在构建确定性数据库方面迈出了重要的一步，但它们仍然存在一个局限性，使它们的应用不切实际：依赖关系分析要求必须执行事务前提前知道事务的读/写集（即主键的集合）。对于具有二级索引查找或其他数据依赖的事务，可能无法预先确定读/写集。在这种情况下，事务必须在数据库上运行以确定其读/写集。然后，事务中止并将这些预先计算的读/写集用于重新执行。但是，如果在此重新执行过程中读/写集中的任何键发生更改，则事务可能会多次执行。接下来，我们讨论为什么现有确定性数据库的设计会导致不良性能。
BOHM 是一个单节点确定性数据库，它分两步运行事务。第一步，它将每个输入事务的写集中主键的占位符以及事务 ID（TID）插入多版本存储层。第二步，事务必须为其读集中的每个键值读取特定版本（尽可能大的 TID 但要小于该事务的 TID），以确保执行确定性。当事务的读集中的所有键值都准备就绪时，事务便可以执行和更新之前插入的占位符。为避免在将占位符插入存储层时产生的多线程同步代价，BOHM中的每个线程都会扫描所有输入事务，以在其自己的分区中查找要插入的键值。
PWV 是一个单节点确定性数据库，首先将每个输入事务分解为一组片段（即子事务），使得每个片段只需要从一个分区读取或写入。接下来，它会构建一个依赖关系图，其中的边指示分区中各个块之间的冲突，并使用它来调度每个片段的执行，以满足数据依赖和提交依赖的需求。与 BOHM 不同，PWV 以更精细的片段（而不是整个事务）提交每个事务。这样，后面的事务花费更少的时间就能看到前面事务写入的值，而代价是更昂贵的细粒度依赖图分析。
Calvin 是一个分布式确定性数据库，它使用单线程锁管理器扫描输入事务，并根据预先声明的读/写集授予读/写锁。一旦获得了事务的所需要的锁，锁管理器接下来将事务分配给可用的工作线程以执行。执行完成后，工作线程将释放锁。锁管理器线程和工作线程的不同角色增加了系统的总体同步成本，并且一个分区上的锁必须由单个锁管理器线程授予。在具有多个内核的计算机中，一个单线程锁管理器很难充分利用系统资源，因为许多工作线程都是空闲地在等待锁管理器来分配事务。为了解决这个问题，数据库可以在每台机器上划分为多个分区。但是，引入更多的多分区事务会增加由于冗余执行而产生的开销。例如，如果
和
上的锁由两个不同的锁管理器授予，则将
和
都更新为
的事务必须运行两次
。
需要注意的是，BOHM 和 PWV 都通过依赖关系图实现执行确定性，并且依赖关系图是在事务执行之前构建的。Calvin 也按照依赖关系图运行事务，但是它是通过有序锁隐式实现的。在以下各节中，我们将讨论 Aria 如何实现确定性并解决上述问题。
3. SYSTEM OVERVIEW/系统总览
在已有背景知识的情况下，我们现在对Aria如何实现确定性执行进行一个概述。与现有的确定性数据库一样，Aria 中的副本不需要相互通信，并能独立运行事务。这是因为相同的结果将始终在确定性执行下产生。每个事务都经过一个排序层，并被分配一个唯一的事务 ID（TID）。 TID 指示事务之间的顺序；默认情况下，它指示事务的提交顺序，但是我们将在第5节中介绍的确定性重排序技术可能以不同的顺序提交事务。
图2：Aria 中的执行和提交阶段
Aria 在两个不同的阶段中批量运行事务：（1）执行阶段和（1）提交阶段，由同步屏障「barriers」分隔。在批处理中，每个Aria副本使用多个工作线程以任意顺序并行运行事务。事务以循环方式「round-robin」分配给工作线程。如图2所示，在执行阶段，每个事务都从数据库的当前快照读取数据，并将这些写入操作保存在本地写集中。与 BOHM 不同，Aria 采用单版本存储的方法，即使它缓冲事务的写操作直到批处理结束。一旦批处理中的所有事务都完成了在副本上的执行，它将进入提交阶段。副本上的提交阶段还可以在多个工作线程上运行，并且每个线程可以独立执行。在提交阶段，线程中止与较早事务（即具有较小 TID 的事务）有冲突操作的事务。例如，如果事务读取了某个较早事务修改的记录，则该事务将被中止。除非事务是被显式中止的（例如，由于违反某些完整性约束），否则中止的事务将在下一批开始时自动进行调度。如果一个事务与先前的事务没有冲突，则系统会将其更改应用于数据库。考虑图3中的示例，其中有四个事务。事务
与
有冲突。为确保可串行性，事务
被中止，并安排在下一批执行开始时执行。
图3：Aria 以批处理的方式运行事务
除了按照输入事务的顺序解决冲突外，Aria 还使用确定性的重新排序技术来减少提交阶段的冲突。 例如，考虑
个事务的序列，其中
读取记录
，并更新记录
，且
。 因此，每个事务（
除外）都会读取一个已被前一个事务修改的记录。 按照Aria中的默认算法，第一个事务是唯一一个可以提交的事务。 但是，这些“冲突”事务仍可以按序列
的顺序提交。 通过确定性重新排序，Aria 不会对输入事务进行物理上的重新排序。 相反，它将提交更多事务，使得结果仍可序列化，但等效于不同的事务输入顺序。
4. DETERMINISTIC BATCH EXECUTION/确定批处理执行
在本节中，我们将详细描述 Aria 如何在两个阶段中确定性地运行事务，以使已提交的事务的序列顺序严格遵循输入事务的顺序。 在第5节中，我们将介绍重新排序技术以放松此约束。
The Execution Phase/执行阶段
在此阶段中，每个事务将从数据库的当前快照读取，执行其逻辑，并将结果写入本地写集，如图4中的第1行至第3行所示。由于事务所做的更改均保留在本地并且它们没有直接提交给数据库，因此在执行阶段每个事务读取的快照始终是相同的。
事务完成执行后，它将遍历其本地写集并对其写集中的每个条目进行写预定，如图4中的第5行至第7行所示。
图4：Aria 中的执行与提交协议的伪代码
仅当预定事务的 TID 比先前的预定者小时，才可以对先前的写进行预定。如果现有预定来自的事务的 TID 更大，则旧的预定将作废，而将使用较小的 TID 进行新的预定。如果事务无法预定某个写，则事务必须中止。此外，事务还可以跳过提交阶段以优化性能，因为它知道至少一个预定不成功。需要注意的是，即使先前的预定失败，也不允许事务跳过其余的预定，而必须继续进行所有预定。这是因为预定是由多个工作线程并行进行的，而忽略其余预定将产生不确定的结果。
现在，我们使用一个示例来说明事务如何进行写预定。
示例1：考虑以下三个事务：
，
和
预定表最初是空的。事务
首先对其写进行预定。预定成功了，并且预定表现在具有条目
。然后，事务
通过在预定表中创建条目
成功进行了预定。最后，事务
尝试对记录
的预定。由于记录
已由事务
预定，并且
具有较大的 TID，因此预定失败，并且
必须中止。注意，即使我们以顺序的方式描述预定过程，整个过程其实可以以任意顺序并行进行，并且始终会产生相同的结果。
一旦所有事务完成执行并为对写进行预定后，系统便进入提交阶段。
The Commit Phase/提交阶段
Aria将并发控制与事务执行分开。在提交阶段，根据执行阶段进行的写预定，确定性地决定每个事务是否可以提交或中止。与非确定性数据库不同的是，Aria不需要两阶段提交即可提交分布式事务。原因有两个：（1）在执行阶段进行的写预定不会影响数据库中每个记录的值，即不需要回滚；（2）事务总可以提交（确定性保证了事务在重新执行之后总是产生相同的结果），即使发生了故障。
现在，我们介绍 Aria 用于确定事务是否可以提交的三种依赖关系：（1）如果事务
尝试更新某些
已经更新的记录，则事务
对
具有写后写（WAW）依赖关系，（2）如果事务
尝试更新某些
读取的记录，则事务
对
具有读后写（WAR）依赖关系，和（3）如果事务
尝试读取
已经更新了的记录，则事务
对
具有写后读（RAW）依赖关系。
Aria通过检查事务是否具有对任何早期事务
（
）的依赖关系来确定事务是否可以提交。系统必须检查两种依赖关系：（1）WAW 依赖关系：如果
写后写依赖于某个事务
，则必须中止。这是因为更新是独立更新到数据库上，并且多个事务更新了相同的记录，并且（2）RAW 依赖关系：如果
写后读依赖于某个事务
，它也必须中止，因为它本应该看到
的写，但实际上没有。需要注意的是，对于事务而言，更新早先的已被某些事务读取的记录是安全的。因此，默认情况下，Aria 不检查 WAR 依赖关系，但是，如第5节所述，确定性重新排序可以借助 WAR 依赖关系来帮助减少事务间的冲突。
请注意，通过中止具有 WAW 或 RAW 依赖关系的事务，Aria确保已提交事务的序列顺序与输入顺序相同。
规则1：如果一个事务对任何较早的事务没有 WAW 依赖关系或 RAW 依赖关系，则可以提交该事务。
Aria 不必遍历所有先前的事务即可检查 WAW 依赖关系和 RAW 依赖关系。相反，它使用事务的读/写集来查找写预定表。请注意，某些事务可能已在执行阶段中止，并且可以简单地跳过提交阶段，例如，某些事务的写预定在执行阶段失败了。如图4（第9-12行）所示，当事务的读集和写集中的键都不存在于写预定表中时，函数 HasConflicts 将返回 false。如果不存在依赖关系，则事务可以提交，并且所有写操作都将应用于数据库上。
与执行阶段一样，每个事务可以用任意顺序并行执行依赖关系的检查。除非该事务被显式中止（例如，违反某些完整性约束），否则中止的事务将被自动地调度到下一批事务中执行。中止事务的相对顺序保持不变。因此，每个事务最终都可以提交，因为批处理中的第一个事务始终可以提交，并且中止的事务的在批处理的位置一直前进。
5. DETERMINISTIC REORDERING/确定性重排序
输入事务的顺序影响批处理中可以提交的事务。 在本节中，我们首先介绍一个示例，然后介绍确定性重排序算法，该算法通过将 RAW 依赖关系转换为 WAR 依赖关系来减少中止事务的数量。在第6节中，我们将讨论当由于 WAW 依赖关系而导致的高中止率时，Aria采取的后备策略。
A Motivating Example/一个示例
我们使用一个示例来说明事务的顺序如何更改哪些事务以及可以提交多少事务。
示例2：考虑以下三个事务：
，
，和
图5：Aria 中的确定性重排序机制
如图5顶部所示，事务
对事务
具有 RAW 依赖关系，因为事务
在事务
写入后读取记录
。 遵循规则1，因为事务
和
都具有 RAW 依赖关系，所以只能提交事务
。 但是，如果我们提交所有三个事务，数据库的结果仍然等同于按照某种序列对这三个事务进行提交，其顺序是：
。
其核心思想是，通过对某些事务进行重新排序，可以将 RAW 依赖关系转换为 WAR 依赖关系，从而允许提交更多事务。 这是因为我们的系统不需要中止有 WAR 依赖关系的事务。
The Reordering Algorithm/重排序算法
通过稍微修改规则1，重新排序算法可以在一个批处理中提交更多事务。
规则2。如果满足两个条件，则事务可以提交：（1）它对任何较早的事务都不具有 WAW 依赖关系，并且（2）对具有较小 TID 的较早的事务既不具有 WAR 依赖关系，又不具有 RAW 依赖关系。
图6：Aria 中确定性重排序的伪代码
图6中给出了该算法的伪代码。第5-10行是按照规则2进行检查的伪代码。该伪代码替代了图4中的 Commit 函数。类似于上一节中介绍的算法，该代码可以并行运行，允许每个事务仅基于其读/写集和预定表来提交或中止。因为此算法允许具有 RAW 依赖关系的事务只要没有 WAR 依赖关系就可以提交，因此它可能导致最终的序列顺序不同于输入顺序。例如，在示例2（如图5的顶部所示）中，事务
和
具有 RAW 依赖关系，但没有 WAR 依赖关系，因此所有三个事务可以以等价的顺序
进行提交。
如第4节所述，我们使用写预定表检测 WAW 和 RAW 依赖关系。为了支持 WAR 依赖关系的检测，系统还需要在执行阶段进行读预定，如图6中第1行至第3行所示。使用读预订表，对数据库中的每条记录，系统都知道哪个事务首先读取了它，具有最小 TID 的事务。在提交阶段，如果事务的写集中的任何键出现在读预定表中并且该读取来自其他事务，则将检测到 WAR 依赖关系。
6. THE FALLBACK STRATEGY/后备策略
因为Aria不需要预先确定读/写集，并且可以在副本中的多个线程上并行运行，所以当 Aria 中的一批输入事务之间的 RAW 依赖和 WAW 依赖很少时，它可以提供优于现有确定性数据库的性能。确定性重排序机制可以将 RAW 依赖转换为 WAR 依赖，从而允许许多原本冲突的事务也能在满足可序列化的要求下提交。
在本节中，我们讨论当由于 WAW 依赖而导致高中止率的情况下（例如，两个事务更新同一条记录），Aria 所采用的后备策略。其关键思想是，我们在提交阶段的末尾添加一个新的后备阶段，并根据冲突事务之间的依赖关系重新运行已中止的事务。如第3节所述，每个事务在执行阶段读取数据库的当前快照，然后决定是否可以在提交阶段进行提交。当提交阶段完成时，每个事务都知道其完整的读/写集。每个事务的读/写集可用于分析冲突事务之间的依赖关系。因此，许多冲突的事务不需要在下一批中被重新安排执行。相反，Aria 可以采用与现有确定性数据库中相同的机制来重新运行那些冲突的事务。
在我们当前的实现中，我们使用与 Calvin 类似的方法，该方法很自然地可以支持分布式事务，尽管任何确定性并发控制都可能可行。在后备阶段，一些工作线程充当锁管理器，以按照 TID 顺序向每个事务授予读/写锁。事务被分配给可用的工作线程之一，并在获得所有锁后就对当前数据库执行（即数据库已经包含较小 TID 的事务提交的更改）。事务提交后，它将释放所有锁。只要事务的读/写集不变，事务就可以确定地提交。否则，它将以确定性方式在下一批中计划和执行。
Calvin 的原始设计仅使用一个线程以预定顺序授予读写锁。但是，在现代的多核节点上，单线程锁管理器无法使所有可用的工作线程饱和。为了更好地利用更多的 CPU 资源，我们的实现使用多个锁管理器线程来授予读写锁。每个锁管理器负责数据库的不同部分。从逻辑上讲，我们的新设计与原始设计等效，但效率更高。原始设计在单个节点上运行了多个 Calvin 实例。这是因为工作线程现在通过共享内存而不是套接字相互通信。
排序层负责监控数据库中中止率的移动平均值。当中止率超过阈值时，排序层确定性地让系统使用后备策略，然后在中止率下降时关闭后备策略。需要注意的是，后备策略可确保 Aria 在最坏的情况下与现有确定性数据库一样有效，因为不冲突的事务仅运行一次。但是，现有的确定性数据库至少运行两次输入事务：一次用来确定读/写集，一次用来执行查询。
7. CONCLUSION/结论
在本文中，我们介绍了 Aria，一种新的分布式确定性 OLTP 数据库。 通过采用确定性执行，Aria 能够有效地且无需协调跨副本执行事务，并且也不需要像现有工作中那样在执行事务前需要读写集的先验知识。该系统在执行阶段对同一数据库快照执行一批事务，然后确定性地选择应提交的事务，以确保在提交阶段提交的事务都满足可串行化。我们还提出了一种新颖的确定性重新排序机制，以便 Aria 以减少中止事务数量为目的去提交事务，同时满足事务的可串行化。 我们基于两个流行基准的测试结果表明，和传统的非确定性并发控制算法和最新的确定性数据库相比，Aria 在单个节点上的性能大大优于现有系统，在八个节点的群集上最多可取得两倍的性能提升。
网友评论