目前，大事务对现代关系数据库系统的设计提出了挑战，因其需要管理未提交的更改。OceanBase是一个分布式关系数据库系统，它实现了基于日志结构合并树（LSM-tree）的存储引擎，以实现高读写性能。现有基于LSM-tree的系统对大事务的支持仍然受到内存限制且效率低下等问题。本文提出了MaLT，一个在OceanBase系统中高效管理大事务的框架。MaLT通过引入了事务上下文表（TCT）和事务数据表（TDT）来管理基于LSM-tree的存储引擎中的事务状态。本文设计了一种高效的恢复机制，以在系统意外故障后提供数据库高可用性。MaLT直接在LSM-tree中实现事务，并利用其独特的特性。事务的回填和撤销操作被无缝集成到LSM-tree的合并阶段。这实现了高效的提交和回滚，同时有助于避免从未提交的大事务中恢复系统时的即时延迟。MaLT还将事务信息直接嵌入到LSM-tree中，以提高读写性能。实验结果证明了MaLT在OceanBase中实现的方法的有效性和可扩展性。

1. 研究背景与动机

近年来，日志结构合并树（LSM-tree）越来越多地被用作现代关系数据库管理系统（RDBMSs）的存储引擎。LSM-tree遵循只追加原则来处理异地更新。摄入的数据首先在内存中缓冲为MemTable，然后作为不可变的SSTable刷新到磁盘。这种结构提供了管理快速写入的能力，并且有助于高效利用空间。OceanBase是一个分布式关系数据库系统，它采用LSM-tree作为其存储引擎。通过实施一些优化策略，如每日增量大合并，OceanBase实现了高读写性能。

1.1 大事务对数据库管理系统的挑战

许多现代应用程序需要复杂的事务，这些事务涉及对多个表和记录进行大量的数据操作。虽然基于LSM-tree的关系数据库管理系统有诸多优势，但在管理大事务时，它们面临挑战。这些事务通常涉及比内存还大的事务数据，在处理未提交的更改时，会导致内存不足的工作负载。同时，长时间运行的事务会在很长一段时间内占用碎片化的资源，这也会导致资源释放的潜在问题，并阻碍数据库恢复过程的效率。一些现代关系数据库管理系统（如TiDB和CockroachDB）也采用LSM-tree作为它们的存储引擎。然而，这种设计面临着以下挑战：

1. 事务大小限制：虽然现有的基于LSM-tree的数据库支持适度大小的大事务，但由于内存或日志大小的限制，它们仍然存在局限性。一些基于LSM-tree的数据库遵循Percolator模型支持事务，该模型依赖内存来管理所有未提交的数据，这些系统中的事务大小不能超过可用内存。另一方面，像RocksDB这样的数据库通过将未提交的更改临时写入磁盘来支持比内存大的事务，但是它们的实现需要为一个事务保留所有的预写日志（WAL），以在事务提交前跟踪事务状态。这导致日志文件过大，从而根据日志容量限制了事务大小。

2. 恢复效率低下：大事务还会带来高昂的恢复成本。当系统遇到异常情况时，恢复过程包括重做和撤销阶段。为了恢复这些事务，需要花费很长时间来撤销所有操作，并且在这个过程中需要一直持有锁。虽然现有方法提出了消除基于B+树的数据库中大事务恢复问题的方案，但这些方法不适用于基于LSM-tree的系统，因为LSM-tree不允许对SSTable进行原地更新。此外，重做和撤销阶段都依赖于活动事务和已终止事务的状态，即管理事务状态的持久性至关重要。

3. LSM-tree特性利用不足：现有系统通常将LSM-tree存储引擎抽象为键值存储，将其视为一个黑盒。这种设计限制了LSM-tree支持大事务。为了支持大事务，最常见的实现方式是在提交或回滚时，将提交版本或回滚状态作为键值对写入LSM-tree，以使旧状态无效。但是由于LSM-tree的只追加性质，磁盘上的SSTable是不可变的，因此重写会产生与事务大小相同的额外I/O。除了上述开销，在提交和回滚过程中，这种黑盒式的实现方式也无法基于此对读写操作进行优化。

1.2 提出MaLT的动机

为了解决上述挑战，本文设计了MaLT，用于在OceanBase中管理大事务。它具有以下特点：

1. 支持大于内存的事务：为了便于在基于LSM-tree的数据库中执行大于内存的事务，将未提交的更改写入磁盘至关重要。为了消除对为单个事务保留整个预写日志的依赖，MaLT引入了一种外部结构来存储事务状态，包括活动状态、已提交状态和已回滚状态。因此，MaLT设计了专为LSM-tree架构定制的事务上下文表（TCT）和事务数据表（TDT）。TCT负责记录内存中的活动事务上下文；TDT记录已提交/已回滚事务的状态。通过结合TCT和TDT，MaLT在提交时利用TCT和TDT有效地更新未提交更改的事务状态。因此，MaLT可以有效地支持大于内存的事务，且没有任何限制。

2. 事务状态的有效持久化和高效恢复：同时，MaLT进一步利用TCT和TDT进行恢复，并为它们设计了专门的持久化策略。通过确保TCT在磁盘上的完整保存，MaLT在重做阶段能够恢复活动事务。而TDT则按照与LSM-tree类似的结构来持久化已终止的事务状态，以实现更高效的存储，并利用TDT跳过撤销阶段。这消除了与恢复过程相关的即时延迟，并且无论事务大小如何，都能实现恒定时间的恢复。

3. 基于LSM-tree优化的高效事务执行：与传统的关系数据库管理系统通常将存储引擎抽象为键值存储不同，MaLT将事务信息直接嵌入到LSM-tree存储引擎中。这实现了一系列优化：

● 首先，由于TCT和TDT框架管理事务状态，在提交或回滚时，无需立即进行回填或回滚操作。这使得MaLT能够将事务状态的回填和回滚无缝集成到LSM-tree的合并阶段，由此可以在恒定时间内实现高效的事务提交和回滚。

● 此外，MaLT中的MemTable和SSTable存储特定于事务的元数据，从而实现高效的数据过滤和检索，显著提高了读写性能。

● 总体而言，MaLT通过这些基于LSM-tree架构的优化策略，实现了非常高效的提交、回滚和执行操作。

1.3 应用场景

本小节报告了一个应用场景：一位客户实施了一个金融平台，该平台要求其数据库对大事务提供强大的支持。这个金融平台对数据库系统有特定要求：它在上午会迎来业务高峰，下午安排备份。随后，在没有业务数据活动时，会进行涉及大事务的批处理。晚上，平台在数据导入时要处理每次提交包含250万条记录的大事务，并且在此期间还需要进行DDL同步。该平台的关键需求包括确保业务高峰期的高性能以及大事务批处理期间的稳定性。

对于OceanBase的早期版本，经常导致内存过载或日志磁盘故障，需要手动干预恢复。即使在早期版本实现了对大事务的支持后，提交和回滚速度仍然是事务执行的一个问题。若在OceanBase中实现MaLT，其确保了对大于内存事务的支持。无论事务大小，提交和回滚时间都是恒定的。并且整体数据导入性能提高了23.9%（时间从11778.4秒减少到8966.0秒）。

1.4 本文的贡献

MaLT在管理大事务方面具有高效性、可扩展性和高可用性。本文的贡献总结如下：

● 本文设计了MaLT，使OceanBase内基于LSM-tree的系统能够支持大于内存的事务。

● 本文提出了专为在LSM-tree中有效管理事务状态而设计的TCT和TDT，使MaLT实现了大事务的高效提交、回滚和恢复。

● 利用LSM-tree的特性，本文为MaLT开发了几种优化技术，进一步提高了提交、回滚和执行操作的性能。

● 实验在OceanBase系统中部署了MaLT。结果证明了该方案的效率和有效性。

2. 背景

2.1 OceanBase

OceanBase是一个高性能的分布式关系数据库系统，旨在满足现代互联网规模应用对可扩展性、跨区域容错和成本效益的要求。OceanBase借助无共享架构展现了高可扩展性和高可用性，使其成为大型企业系统的可靠选择。

最新版本OceanBase4.0引入了Paetica，融合了无共享和全共享原则。这种混合方法使OceanBase能够满足从小型企业到大型组织的广泛业务需求。它具有集成的SQL引擎、事务处理引擎和存储引擎，便于在单机和分布式模式之间无缝切换。这种灵活性提高了可扩展性，降低了延迟，并确保了高效的事务管理。

2.2 LSM-tree

近年来，一种趋势是采用日志结构合并树（LSM-tree）作为存储层，特别是在键值存储（如LevelDB、RocksDB和BigTable）。LSM-tree遵循只追加结构，首先将传入的写入和更新在内存中缓冲为MemTable，并通过预写日志（WAL）确保数据的持久性。当MemTable超过限制时，它将数据刷新到磁盘，成为不可变的排序运行（即SSTable）。这种结构最大限度地减少了随机I/O。LSM-tree采用分层结构存储数据，磁盘上的SSTable按级别组织，级别越低容量越小，级别越高容量呈指数级增加。传入的更新存储在较低级别，以使较高级别中的陈旧数据无效。当特定级别的数据达到其容量时，将调用合并操作以重新组织数据。合并操作是LSM-tree中定期触发的后台进程，它选择较低级别的文件进行排序合并到较高级别。在此过程中，陈旧数据被删除，以降低空间利用率并提高读取性能。

2.3 大事务

对于大于内存的事务，内存不足的工作负载会导致写入和更新的开销。缓冲区管理可以处理内存和辅助存储之间I/O操作开销，但是目前的几种缓冲区管理技术无法处理大于内存的事务。现代数据库管理系统通常采用窃取策略，允许将未提交的更改刷新到磁盘，从而释放内存资源并减少开销。一系列内存数据库也强调对大于内存事务的管理，探索使用新硬件和技术（如非易失性内存（NVM）和远程直接内存访问（RDMA））来改善缓冲区管理的可能性。

大事务的恢复也具有挑战性。对于传统的基于B+树的数据库，ARIES是一种经典的恢复算法，具有窃取和无强制策略、预写日志、补偿日志等特点。尽管ARIES有诸多优点，但为了从长时间运行的事务中恢复，撤销阶段的恢复时间与事务大小成正比，此过程中持有的排他锁也会使数据库在此阶段无法访问。考虑到数据库的可用性，CTR在Azure SQL Server中提出了利用多版本并发控制（MVCC）机制跳过撤销阶段以提高效率。

3.MaLT的设计

3.1 MaLT中的LSM-tree

本节介绍OceanBase中LSM-tree的结构，并突出MaLT中实现的独特优化，这些优化将事务信息与存储引擎紧密集成。

3.1.1 OceanBase的设计目标

MaLT框架基于LSM-tree的基础设计构建。在大多数基于LSM-tree的主流数据库实现方法存在几个缺点：

1. LSM-tree不支持原地更新。因此，在提交时的版本回填和回滚期间的数据清理等任务，需要额外的追加操作，导致行级I/O负担增加和写放大问题。

2. 黑盒设计限制了针对各种数据使用场景进行优化的能力，无法选择合适的数据结构和存储方法来实现高效的单点查找和范围查询。

3. 这些限制使得在没有事务信息的情况下，更难利用LSM-tree的不可变和增量特性。

鉴于这些挑战，OceanBase采取了不同的方法，直接在LSM-tree中实现大事务，利用其固有特性优化流程。

3.1.2 OceanBase中LSM-tree的实现

MaLT中的LSM-tree结构

OceanBase采用哈希表和B树相结合的方式构建MemTable。这种混合结构确保了高效的单点查找和范围查询。OceanBase中的SSTable由2MB的宏块组成，旨在实现高效的范围读取和紧凑存储。OceanBase采用基线加增量的设计，较低级别包含较小的SSTable用于存储增量数据更改，而较高级别通过合并将这些更改整合到较大的SSTable中。合并操作通常安排在非高峰时段进行，以尽量减少对系统性能的影响。

3.1.3 MaLT中的事务信息

MaLT在LSM-tree中实现大事务，MaLT中的相关事务信息如下：

MaLT的版本边界结构

1. 多版本实现：MaLT遵循MVCC机制，MemTable使用从最新到最旧排序的链表结构管理数据的多个版本。每个版本都标注有版本号和相应的事务ID，以实现有效的并发控制。同时SSTable也维护多版本数据，每个版本都由版本号和事务ID标记。SSTable中的版本存储在连续的磁盘空间中，以方便高效访问。

2. 快照读：为实现快照读功能，MaLT根据不同的读写场景，引入哈希表或B+树来识别MemTable或SSTable中的多版本行。随后，MaLT通过利用快照版本在MemTable的多版本链表或SSTable的索引宏块中定位正确的版本。与键值存储实现相比，作者利用版本信息过滤掉不必要的版本，并在LSM-tree内进行计算下推，并使用专门的算法来提高特定用户场景下的读取效率。比如在涉及热点行的场景中，采用版本合并算法来最小化开销，并利用索引高效定位多版本数据的起始点。

3. 版本边界：与传统LSM-tree不同，MaLT为MemTable和SSTable都维护了版本边界，这些边界代表了它们相应日志内的数据边界。上图展示了每个SSTable如何精确划定各自日志内的数据边界。可以看到SSTable1仅包含从系统变更号（SCN）1到SCN3的数据，SSTable2包含从SCN4到SCN9的数据，而MemTable则保存从SCN10开始的所有数据。SCN不仅是数字标识符，还作为与事务提交版本相关联的逻辑时钟。这些信息为读写优化提供了更好的支持。

4. 事务操作：为了保留前面指定的事务信息，MaLT维护一个内存中的链表，按照执行时间顺序跟踪事务操作，称为Tx_Opts。当事务提交或回滚时，MaLT使用这个事务操作索引来维护相应数据上的事务信息。由于在支持大事务之前，SSTable中只存储已提交事务的数据。因此，MaLT只需要将在MemTable中正确维护的事务信息持久化到SSTable中。

3.2 事务表

MaLT需要一个外部结构来管理事务状态，以便进一步进行回填和重做过程。MaLT首先设计了事务数据，用于记录事务的状态。在事务的不同阶段，设计并使用TCT和TDT来管理活动事务和已终止事务。

这种分离设计能够令MaLT解耦TCT和TDT，赋予它们不同的功能和存储方案。这种设计的好处包括：

●  在内存中高效管理活动事务。

●  有效地存储已终止事务。

●  将回填和撤销操作与合并无缝集成。

事务表

3.2.1 事务数据

事务数据是一个固定大小的结构，用于记录事务状态。事务数据记录的关键字段总结如下：

●  TxID：事务ID。

● State：事务的当前状态，包括运行中（RUNNING）、已回滚（ABORT）和已提交（COMMIT）。

● Commit_Version：事务的提交版本。它决定了不同版本数据对该事务的可见性。

事务数据是承载事务状态的基本单元，在事务执行的不同阶段被TCT和TDT引用。通过事务数据，事务状态可以零拷贝传输。当一个事务开始时，事务管理器会同时初始化相应的事务数据，并赋予相关信息，如TxID和State。

3.2.2 事务上下文表（TCT）

事务上下文表（TCT）是ARIES中活动事务表（ATT）的一种新颖实现。与ATT相比，TCT有三个关键点：

●  TCT更加强调事务处理、提交和恢复的效率。

●  TCT优先管理事务上下文。

●  TCT维护了未来优化所需的关键内部结构。

TCT旨在在事务处理和恢复过程中管理内存中的事务上下文。事务上下文由数据信息和执行信息两个主要部分组成。数据信息主要代表事务数据，而执行信息包括事务执行所需的其他详细信息（如两阶段提交状态）。

TCT使用哈希表来组织事务数据，这有助于高效检索和更新活动事务的状态，确保操作能够快速且准确地执行。TCT完全在内存中维护，仅在进行检查点操作时持久化到磁盘，以便恢复。进行检查点操作时，TCT会按照LSM-tree的刷新流程写入磁盘，同时内存中的TCT不会被释放。

Tx_Opts也通过链表的形式在TCT中维护，在事务执行和重做阶段都会对其进行主动管理。Tx_Opts记录固定数量的事务操作，而非记录所有事务活动，这样能确保该结构获取管理事务所需的关键变化，从而降低提交和回滚时的成本。

3.2.3 事务数据表（TDT）

TCT用于管理内存中的活动事务，若使用TCT存储所有已终止的事务，可能会带来较高的内存成本。为此，MaLT引入了事务数据表（TDT），负责存储和持久化已提交和已回滚的事务数据，方便进一步访问事务状态。

为了避免频繁的I/O操作降低系统性能，以及TDT中的写入量大于读取量的问题，MaLT为TDT设计一个符合LSM-tree原理的存储过程是合理的。具体来说，TDT也由事务数据内存表（TMemTable）和事务数据SSTable（TSSTable）组成，分别对应内存和磁盘中的数据。

TMemTable用于查询事务状态。由于每次仅访问一个事务数据，即不存在对事务状态的范围查询，TMemTable被设计为内存哈希表，以实现高效的插入和点查询操作。当事务提交或回滚时，事务数据会被插入到TMemTable中，并且不再被TCT引用。之后，它会经历与LSM-tree中类似的冻结和合并过程。此外，在事务提交前，TMemTable会先写入并刷新重做日志，以确保提交的持久性。

对于大事务而言，TCT和TDT的一个重要功能是在查询未提交更改时，提供对事务数据的访问。当事务访问未提交的行时，MaLT会根据TxID，按照TCT、TMemTable和TSSTable 的顺序进行点查询，查找相应的事务数据。然后根据事务数据中的提交版本确定该版本的可见性。如果版本可见，将其作为快照读的起始点；否则，继续查找下一个版本。

3.3 使用事务表进行恢复

大事务在恢复过程中会产生巨大成本。一旦系统崩溃，可能需要将事务的所有操作回滚到事务开始时的状态，恢复成本与事务大小成正比。这个过程会一直持有锁，导致数据库长时间无法使用。MaLT具有恢复机制，它利用前面提出的事务表在LSM-tree中实现高效恢复。

1. 利用TCT进行重做操作：TCT记录了活动事务的信息。因此，在重做阶段，MaLT首先根据之前的检查点，对持久化在磁盘上的TCT进行完全恢复。随着TCT的恢复，所有活动事务都恢复可用状态。然后，数据库从检查点开始重复事务日志，重做所有操作。

MaLT采用物理日志，使得恢复过程能够在行级别并行且无序地重做所有操作。在重放事务日志时，会将数据的系统变更号（SCN）与行中的版本SCN进行比较，以确定更新位置，从而支持无序重放。一旦所有重做日志都重放完毕，重做阶段就结束，并且恢复了所有需要回滚的活动事务。

2. 利用TDT跳过撤销操作：为了解决LSM-tree中将事务状态回填到未提交行的问题，MaLT依赖前面提到的多版本行中的事务ID，然后使用TDT以LSM-tree的形式存储事务数据。此外，通过检查TDT可以释放事务持有的资源和锁，因此不会影响服务的提供。在读取时，MaLT可以通过检查事务版本安全地跳过已回滚的数据版本。这使得MaLT能够跳过撤销阶段，实现非常高效的恢复。

对比SQL Server中的CTR的使用持久化版本存储和已回滚事务映射来处理大事务，MaLT利用TCT和TDT的特性，在提交或回滚时只需要将事务状态转移到TDT。这种设计确保了提交、回滚和恢复的延迟与事务大小无关。

3.4 后台合并

合并是LSM-tree中一个持续清理陈旧数据的后台过程。当定期触发合并时，它会将较低级别的数据排序合并到较高级别，从而消除较高级别中的陈旧数据。合并有助于降低系统的空间利用率和查询延迟。MaLT在以下几个方面创新性地增强了LSM-tree合并的功能：

1. 合并中的回填和撤销：尽管MaLT提出了TCT和TDT来持久化事务状态并管理大事务，但这会在查询数据时增加对TCT和TDT的额外查找。为了减少查找延迟，MaLT尝试利用TDT进行回填和撤销操作。一旦触发合并，对于那些已提交的事务，MaLT会扫描TDT中的事务数据，并回填未提交更改的相应版本；对于已回滚的事务，在合并过程中可以直接释放未提交的更改，以节省空间。

2. 事务数据清理：TDT还依赖合并来释放已使用的事务数据。对于特定事务数据的记录，一旦所有相关行的状态都被更新，就可以安全地从TDT中删除该记录。在合并过程中，首先获取SSTable的最小SCN。合并引擎将遍历这个SCN之前的事务数据，并检查它们是否可以安全清理。SCN是标识事务提交版本的逻辑时钟，它确保在生成最小SCN的SSTable合并期间，在此之前的任何未提交更改都已被回填或撤销。

事务数据清理

4. 优化

4.1 基于事务操作优化事务执行

1. 大事务执行：为了提高事务，尤其是写入操作的执行效率，MaLT在TCT中维护事务操作（Tx_Opts）。利用Tx_Opts，MaLT通过促进并行执行来高效处理大事务。Tx_Opts对执行大事务的操作进行批量缓冲。对于每个事务，相应的操作被划分为多个Tx_Opts，这便于使用多个线程并行处理事务。

虽然MaLT允许并行执行方式来提升事务处理能力，但确保多个Tx_Opts中操作执行顺序的正确性仍然重要，特别是当同一记录被多次更新时。与多路归并排序的思路类似，MaLT以并行且有依赖关系的方式实现它，以确保更新的正确性。

2. 小规模事务优化：对于那些在磁盘中没有脏页的小规模事务，按照TCT和TDT的相同流程处理会产生不必要的开销和延迟。因此，MaLT再次利用Tx_Opts：当事务提交或回滚时，MaLT遍历相应的Tx_Opts来回填事务状态和版本，或者回滚事务更新的数据。因此，回填和撤销操作在MemTable刷新之前就在其中进行。

Tx_Opts的大小由预定义的阈值限制。这意味着回填和撤销功能仅为小规模事务提供。当事务大小超过Tx_Opts的大小时，MaLT将依赖TCT和TDT来进一步管理事务的状态和版本。这种优化确保了MaLT对小规模事务的处理效率，这对于保证数据库的整体性能也至关重要。

4.2 利用事务信息优化读写操作

MaLT对版本边界的优化

MaLT进一步可以利用事务信息，特别是版本边界，在LSM-tree中进行多种优化。

1. 对于事务性读操作：MemTable和SSTable都是基于SCN和RowKey范围的数据集。读版本与SCN相关联，因此MaLT只需要读取SCN范围小于读版本的数据集。需要读取的数据包括MemTable、SSTable和MajorSSTable。

2. 对于事务性写操作：利用静态数据（如SSTables）的不可变性质，在MemTable的每一行中维护必要的事务信息：

●  Exist_State：该状态用于确定该行是否存在于SSTables中。

●  Lock_State：该状态用于确定该行在SSTables中是否持有行锁。

●  Max_Version：该行在SSTables中的最大提交版本。

通过维护这些事务信息，MaLT可以直接使用内存中存储的信息实现并发控制算法。比如通过验证Exist_State来管理主键冲突；通过Lock_State识别锁冲突；利用Max_Version确认不存在丢失更新异常，从而满足隔离级别的要求。这种方法避免了某些写路径中的磁盘读取，从而显著提高了OceanBase的性能。

此外，事务信息通过采用与基于SCN的修剪类似的逻辑，增强了备份场景。有了事务信息，MaLT可以在备份期间通过基于SCN物理移动文件，高效地处理特定的SSTable。

4.3 事务数据缓存

为了减少频繁读取事务数据（尤其是存储在磁盘TSSTable中的数据）的开销，本文还设计了事务数据缓存（TxDataCache），用于缓存频繁访问的事务数据。

TxDataCache采用两级结构：TxDataMiniCache和TxDataKVCache。

● TxDataMiniCache被设计为在查询级别持有有限大小的缓存，有效地处理了频繁访问的事务数据的结果。

● TxDataKVCache提供了更广泛的缓存解决方案，通过结合类似LRU（最近最少使用）这样的缓存淘汰机制，以提供更全面的缓存服务。

读取事务数据的过程

读取事务数据的过程如下：

1. 读取TxDataCache，TxDataCache存储频繁访问的事务数据。

2. 读取TCT，TCT在内存中维护活动（运行中）事务的信息。

3. 读取TDT，这涉及访问TMemTable和TSSTable。

5. 实验

本文中，实验的评估主要围绕两个对MaLT至关重要的问题：

●  性能：MaLT能否有效地处理各种大事务类型并展现出高性能？ 

●  系统开销：MaLT给系统带来了什么程度的开销，它对基准测试的整体性能有何影响，以及优化技术如何降低开销？

5.1 实验配置

1. 设置：实验在一台配备64核Intel (R) Xeon (R) Platinum 8369B CPU、400GB内存的服务器上进行。评估大多在单节点环境中进行，将核心存储性能与网络延迟等外部因素隔离开来。

2. 评估数据库：实验选择了包括OceanBase、MySQL 8.0、DB-A和DB-B在内的数据库进行比较：

●  OceanBase(OB)：实验在OceanBase中实现了MaLT。同时还实现了另外两个版本：没有MaLT的OceanBase（OB-NM），它缺少MaLT框架；以及没有优化的OceanBase（OB-NOP），它不优化事务信息并将LSM-tree视为键值存储。

●  DB-A：一个可扩展的关系数据库管理系统，支持OLTP工作负载。它采用标准的无共享架构，以提供高性能事务和强一致性。其存储层基于LSM-tree实现。

●  DB-B：一个分布式关系数据库管理系统，旨在支持不同类型的工作负载。其分布式存储层也基于LSM-tree来持久化数据。

●  MySQL：是基于B+树的主流经典关系数据库管理系统，支持大事务。它以在各种应用中的高性能能力而闻名。实验中使用MySQL 8.0企业版。

为了进行公平比较，实验对MySQL参数进行了优化；在DB-A和DB-B中，对于涉及相同分区的事务，利用enable_1pc允许一阶段提交（1PC），以提高带宽效率。它们的内存大小也都设置为400GB。

3. 基准测试：我们使用以下基准测试进行评估。

●  TPC-C：用于评估OLTP数据库性能的基准测试。实验中使用遵循TPC-C标准的软件BenchmarkSQL来测试数据库性能。

●  Sysbench：用于数据库系统的负载测试工具，适用于任何支持MySQL或PostgreSQL协议的数据库。在涉及大事务的实验中，实验使用带有自定义脚本的Sysbench来评估这些大规模操作的每秒事务数（TPS）。

5.2 大事务评估

大事务评估

MaLT的主要目标是支持大事务。为了评估批量导入场景的性能，实验使用Sysbench模拟从512MB到500GB不同大小的事务，使用10个线程同时执行大事务并测量每秒事务数TPS。

结果表明，在所有数据库中，带有MaLT的OceanBase在所有事务大小下的TPS最高。DB-B的瓶颈在于其内存限制，当处理大于50GB的事务时，它会出现故障并报告错误。另一方面，DB-A由于重写数据的成本较高，处理大事务的效率也较低。

实验进一步使用Sysbench生成从1GB到1024GB的单个大事务，并触发提交和回滚操作以评估它们相应的性能。

单个大事务在触发提交和回滚操作的性能

实验表明，MaLT在所有评估的数据库中提交和回滚时间最低。且无论事务大小如何，MaLT的提交和回滚时间都保持恒定，而大多数其他数据库在这些指标上显示出显著增加。DB-A在处理大事务回滚方面相对稳健。然而，其提交时间仍然随着事务大小的增加而增加。DB-B的事务大小受内存限制，因此当事务大小超过内存限制时会失败。虽然MySQL可以支持大事务，但其提交和回滚时间随着事务大小的增加而显著增加。

5.3 恢复评估

在出现异常情况时，为了消除大事务在恢复过程中的成本，MaLT还利用TCT和TDT对数据进行重做并跳过撤销阶段，提高了大事务恢复过程的效率。为评估MaLT的恢复时间。实验使用Sysbench在压力测试中模拟从20GB到200GB不同大小的事务，包括插入、更新和删除等操作。为了模拟现实场景，实验诱导故障并随后重启数据库系统。

OB使用/不使用MaLT的恢复能力评估

实验结果验证了MaLT使用的TCT和TDT在处理恢复方面的效率。与OB-NM相比，MaLT能够显著减少事务恢复所需的时间，从而实现高效的恢复，无论事务大小如何。

5.4 读取事务表的延迟

为评估执行事务的延迟。实验使用Sysbench生成从10k到100m行的数据，比较了不同场景下的延迟：回填（事务提交时立即回填事务状态）、从TDT读取以及带缓存的TDT读取。

执行事务延迟结果

实验表明，从磁盘访问TDT的过程比从内存中读取TCT具有更高的延迟，并且事务大小与读取延迟之间存在直接的正比关系。随着事务量的增加，读取TDT所需的时间相应增加。由于优化了事务执行，延迟显著降低。这种优化突出了缓存机制在减少读取延迟方面的成功。

5.5 TPC-C基准测试评估

实验展现了使用TPC-C基准测试评估多个数据库的结果，比较了带有MaLT的OceanBase（OB）、没有MaLT的OceanBase（OB-NM）、没有优化的OceanBase（OB-NOP）、MySQL、DB-A和DB-B。同时实验评估了不同事务类型（包括DELIVERY_BG、NEW_ORDER、ORDER_STATUS、PAYMENT和STOCK_LEVEL）的延迟以及tpmC（每分钟事务数）。

在不同数据集上TPC-C基准测试评估结果

从结果可以看出，与OB-NOP相比，OB的tpmC提高了约23%，平均延迟降低了22%。这种改进归因于Tx_Opts提高了小规模事务的执行效率，以及事务信息改善了读写性能。此外，OB、OB-NM和OB-NOP在评估中优于其他数据库，显示了OceanBase中LSM-tree设计的有效性。由于OB对LSM-tree结构保持细粒度的控制，最小化了不必要的I/O开销并提高了整体性能。尽管TPC-C基准测试中的事务大小并不是特别大，带有MaLT的OB在延迟和tpmC方面与OB-NM表现相当，表明MaLT引入的开销有限。

5.6 事务表的空间成本

为了全面研究这些事务表对空间开销的影响，本文通过改变TDT中记录的事务状态数量进行实验，然后观察由此产生的空间成本。总体而言，空间成本与TDT中的事务状态数量成正比。根据评估，TDT存储300万个事务仅需要0.3GB，存储3000万个事务需要3.09GB。这表明TDT和TCT的设计不会给系统带来过多的空间开销。

此外，MaLT包含一个定期触发的后台合并过程，实验使用TPC-C观察事务数据的后台回收。在TPC-C过程中，通过每十分钟记录一次TDT的磁盘空间使用情况发现，大约每十分钟会生成600~700MB的事务数据。这些数据大约每20~30分钟被合并和回收一次，确保通过回收来管理事务数据的数量，从而防止对后续性能产生影响。

6. 讨论

本文讨论在处理大事务、在OceanBase中开发MaLT以及将其强化为一个强大的生产系统过程中获得的一些经验：

6.1 分布式系统中的大事务

在分布式数据库环境中实现大事务时，会遇到的一些挑战。作为一个分布式数据库系统，OceanBase必须管理主节点和从节点，并通过日志进行同步。在生产场景中，一些从节点难以跟上领导者节点的速度，导致领导者和从节点之间的日志同步出现显著延迟，进而影响整体日志同步。这表明从节点需要具备与领导者节点相同的能力。为了解决这个问题，作者在从节点重放时，对每个数据使用与领导者节点相同的Tx_Opts索引，以确保进度一致。

此外，在分布式环境中，系统还必须应对确保分布式原子性的挑战。这涉及实施两阶段提交（2PC）过程并管理参与者。鉴于OceanBase的高可扩展性，参与者列表有时可能包含数万个条目，由于列表长度的原因，日志可能会跨越多个预写日志（WAL）。这进一步要求框架回收一些包含部分参与者列表的日志。为了解决这个问题，在这些场景中，MaLT将部分参与者列表持久化到TCT的执行信息中。

6.2 模块化事务表设计

OceanBase需要同时管理来自不同副本的备份和恢复。这就要求数据、TCT和TDT可以独立进行备份和恢复，即事务表的模块化设计。在设计TCT和TDT时，本文选择了一种解耦的方式：TCT负责维护活动事务，而TDT负责维护已提交或已回滚的事务。恢复过程利用数据、TCT和TDT所需的最小日志恢复点，显著提高了备份性能。

6.3 未来工作

由于不包含未提交数据的SSTable可以提高计算下推效率，作者的目标不仅仅是在合并期间回填事务状态。在实践中观察到大型事务不会与高并发的小型事务同时发生，单个SSTable通常只包含少数事务的数据。作者的目标是将有限数量的事务数据合并到SSTable元数据中，仅回填SSTable元数据，以确保在读写过程中可以直接访问事务状态。这种方法消除了对事务表的依赖，并允许在无需等待合并的情况下进行更进一步的存储优化。

7. 相关工作

支持大事务长期以来一直是数据库系统的一个基础研究领域：

1. ARIES为在B树存储模型中实现大事务提供了一种基础方法，并作为大多数数据库中大事务支持方案的基础。

2. MySQL是基于ARIES实现大事务的典型数据库示例。然而，提交和回滚期间持有锁的延迟与事务大小有关。

3. TiDB和CockroachDB也基于LSM-tree实现了事务模型。然而，它们主要将其用作键值存储。TiDB依赖Percolator实现的键值存储,其事务限制受数据库分配的内存限制，并且它也缺乏对窃取策略的支持。CockroachDB使用Pebble作为键值存储来实现事务支持。然而，由于事务语义直接在键值存储之上实现，提交和回滚需要覆盖事务涉及的行以更新事务状态。在LSM-tree的只追加原则下，这会在事务级别导致额外的I/O。

4. RocksDB和MongoDB都是基于LSM-tree实现的NoSQL数据库。它们的事务模块构建在LSM-tree之上，而没有在其中嵌入事务信息。MongoDB无法支持超出内存限制的大事务。RocksDB虽然支持大事务，但在事务回滚期间需要从预写日志中将原始行重新应用到LSM-tree。因此，事务大小和恢复时间受到日志磁盘大小的限制。

8. 结论

大事务给基于LSM-tree的关系数据库管理系统（RDBMS）带来了重大挑战。为应对这些挑战，本文提出了MaLT，一个在基于LSM-tree的RDBMS中管理大事务的框架。MaLT使用事务上下文表（TCT）和事务数据表（TDT）来实现有效的事务状态管理，整合了恢复和压缩机制，以确保数据库的高可用性。此外，本文还开发了几种优化技术，从不同方面确保系统性能，通过在分布式关系数据库系统OceanBase中实现了MaLT，显著提升了其处理大事务的能力。实验结果验证了MaLT的高性能以及事务提交和回滚的高效率。

论文解读联系人：

刘思源

13691032906（微信同号）

liusiyuan@caict.ac.cn