现有的事务型评测基准，是否仍然适合评测分布式事务型数据库？
本文系华东师范大学数据学院 DBHammer 组瞿璐祎所著。
「瞿璐祎：研究生期间在华东师范大学数据学院 DBHammer 组致力于事务型数据库评测工作，已经在面向应用的事务数据库评测场景模拟以及分布式事务型数据库的评测上取得了一定的成果，其本人将继续致力于为国产数据库的发展添砖加瓦。」
随着分布式事务型数据库的快速发展，对其进行公平的性能评估和比较是非常有必要的，作者基于现有的事务型评测基准，对分布式事务型数据库的适用性进行了分析研究。
希望阅读完本文，你可以有所收获，有什么疑问也可以在底部留言探讨。
近年来，随着分布式事务型数据库的快速发展，对它们进行公平的性能评估和比较受到越来越多人的关注。虽然现有很多为数据库建立的评测基准，但对分布式事务型数据库的适用性仍缺乏全面的研究。因此，本文分析了现有的事务型评测基准对分布式事务型数据库的适用性。
我们首先总结了分布式事务型数据库的代表性架构，然后概述了分布式事务型数据库的瓶颈点。之后，我们根据现有的事务型评测基准的特点和设计目的对其进行了分类，并且分析它们是否仍然适用于评测分布式事务型数据库的瓶颈点。
我们首先调研了常用的事务型评测基准和分布式事务型数据库，将他们的发布的时间线标注在图 1 中。可见现有的事务型评测基准基本上大多在 2010 年前发布，但分布式事务型数据库却在 2010 年之后开始崭露头角。因此，这就引发一个问题，现有的事务型评测基准是否仍然适用于评测分布式事务型数据库？
图1：分布式数据库和OLTP基准的历史
分布式事务型数据库的典型架构
为了回答这一问题，我们首先调研了常见的分布式事务型数据库并将它们分为三个类：Share-Nothing 架构、Share-Nothing 分离架构和 Share-Storage 架构。
Share-Nothing 架构
Share-Nothing 架构采用预定义的规则，将数据划分为多个（分布式）节点，每个节点涵盖了查询、事务和存储引擎的功能模块，并在执行分布式事务或分布式查询时协调其他节点。它解决了两个关键的可扩展性问题，即存储可扩展性和分布式事务处理可扩展性。Share-Nothing 架构代表性的分布式事务型数据库有 H-Store，Spanner，VoltDB，Citus 和 OceanBase。
Share-Nothing 分离架构
Share-Nothing 分离架构将查询引擎和存储引擎分开，查询引擎是无状态的并且可以在任何数量的节点中运行，存储引擎提供具有多个副本的事务性存储访问。同时，他们不依赖于预定义的分布规则，而是将数据分为子块，并使用一个集中的管理控制器来平衡所有存储节点之间的存储和负载。因此，一个计算节点可以足够灵活地访问任何存储节点，并安排数据和负载量，根据优化的目标来调度数据和负载。然而，由于这种方式会产生许多网络开销，在复杂的分布式事务下，性能会比较差。这种架构下具有代表性的数据库有TiDB，CockroachDB 和 FoundationDB。
Share-Storage 架构
Share-Storage 架构为了处理复杂的事务型负载，牺牲了写入的灵活性和可扩展性。具体来讲，它们把查询引擎和事务管理在一个计算节点上，然后使用多个存储节点来存储数据和日志，所有其他计算节点都是只读节点，通过分离读和写，减轻了写节点的负担。这种架构在存储和读取负载方面具有可扩展性，但单个写节点可能成为数据库的瓶颈。然而，由于所有的事务都是在单个节点上执行的，即使是复杂的事务，其性能也不会受到分布式事务的影响。这种架构下具有代表性的数据库有 Aurora，PolarDB，Socrates 和 Taurus。
分布式事务处理中的瓶颈点
我们将这三种架构及其代表性的分布式事务型数据库在存储能力、事务处理能力、查询能力和调度能力这四个方面所涉及到技术罗列在图 2 中。此外，我们分析分布式事务型数据库在四个方面潜在的瓶颈点，其中存储瓶颈点影响事务处理，查询处理和调度，因此将它分散在这三个方面进行描绘。
图2：分布式数据库在支持事务处理方面的比较
事务处理能力
分布式事务跟传统的事务一样,也必须满足 ACID 约束, 但当数据被放置在不同的节点时,数据库会面对以下两个难题: 分布式并发控制和分布式提交。MVCC、OCC 和 2PL 被提出来以确保事务处理的正确性，表 2 中的 5 个分布式事务库采用了 MVCC 和 2PL 的组合，TiDB 和 CockroachDB 中使用了 Percolator，它是 OCC 的变种。由于分布式事务的复杂性，我们还需要考虑到分布式事务的上下文和时间戳管理。分布式 2PL 需要考虑多个节点锁的分配和释放；在 MVCC 中，如何在所有参与者之间分配版本信息是至关重要的；而在 OCC 中，如何在所有参与者之间原子化地完成验证也是很关键的。此外，全局性的时间戳管理是必不可少的，目前常见的有两种解决方案：严格增加且唯一的时间戳，由全局时间戳分配；全球时间戳服务，如 Spanner 中使用的 TrueTime API 和 CockroachDB 中的混合逻辑时钟。当一个分布式数据库无法提供全局快照时，RC 是它能支持的最高隔离级别。为了保证事务执行的正确性，不同节点的提交管理是很重要的。两阶段提交（2PC）和三阶段提交（3PC）几乎是所有分布式数据库的选择。
查询处理能力
分布式查询处理在分布式集群中是必要的，一个查询可能会访问不同的节点，分布式查询处理有两个主要挑战。一方面全局快照需要保证不同节点之间的数据一致性，如表 2 所示，除了 Citus，所有分布式数据库都为用户提供了全局快照；另一方面，查询优化器应该适应分布式环境，它应该考虑到分布式的特点如节点的资源消耗和底层的数据放置。
分布式事务型数据库中典型处理架构是将所有的客户请求路由到 leader 副本，而 slave 副本负责在主节点故障时提供可用性。但随着客户请求的爆炸性增长，slave 副本也被用来处理读请求来缓解 leader 副本的压力，而 leader 副本负责写入操作。为了获得高性能，表 2 中的分布式事务型数据库都采用了这种读写分离策略，尽管有几个分布式事务型数据库支持强一致性读如 TiDB，但它们必须等待 slave 上达到最新的数据时才能响应，因此导致性能降低。
调度能力
分布式事务型数据库中的调度包括自适应分割、弹性计算和存储移动。自适应分割指当 region 过热时，它采取自适应分片来分割这个 region，然后将其中一个 region 移动到其他节点上。弹性计算是用来调整物理资源，即当一个节点资源不足时，它将该节点的任务灵活地分配给其他空闲的节点。从表 2 来看，所有的分布式事务型数据库都具有弹性计算能力，但是 Aurora 和 PolarDB 只会扩展只读节点，因为它们只有一个写节点。Share-Nothing 架构比 Share-Nothing 分离架构扩展的成本更高，因为它必须同时扩展两种资源，即计算和存储。存储移动第一个目的是将分区均匀地分布在各节点上，从而减轻存储压力，避免单个节点上的磁盘爆炸。对于表 2 中的分布式事务型数据库，它们都实现了这个功能，但是使用了不同的策略。例如，Citus 中提供了一个分片再平衡器。第二个目的是把客户经常访问的分片放在同一个节点上，这个功能在学术界被广泛研究，但它的实施成本很高，所以表 2 中的分布式事务型数据库都不支持这个功能。
评测基准对于分布式事务型数据库的适用性
许多事务型评测基准被设计用来评估数据库，我们把它们分为微观评测基准、面向应用的评测基准和面向目的的评测基准。微观评测基准是用于测试一个系统或程序中的单一组件或任务的性能，关心的是子组件的性能。面向应用的基准和面向目的基准都是宏观基准，模拟一个应用程序的工作负载并用于评估系统的整体性能。面向目的的基准是面向应用的基准的一个特例，它更多地关注应用程序的特征，如秒杀应用中的高冲突和倾斜这一负载特征。
那么就有一个问题，这些基准是否仍然适用于评测分布式事务型数据库？为了回答这个问题，我们对数据放置策略等做了规范。对于这些评测基准的数据放置规则，例如 Hash 或 Range，我们假定表是根据相关表的主键划分数据的，即分区键，假定其他表和分区键的放置是绑定的。在此基础上，如果一个事务写（修改，删除）不同的分区 ID 的主键，就定义该事务为分布式事务；分布式查询访问来自不同分区的数据；自适应拆分可以在几种情况下被触发，例如负载中的热点；存储移动可能发生在数据项被频繁一起访问的时候；弹性扩展需要数据和负载同时满足可扩展性。
我们从数据 schema，负载等来探索这些评测基准评测分布式事务型数据库关于事务处理，查询处理和调度能力。如表 2 所示，“Yes”和“/” 意味着该评测基准是/否具备评测该项的能力，在分布式事务和分布式查询两项中注明了涵盖这项的事务。
图3：分布式事务型数据库基准测试的比较
微观评测基准
虽然现有很多微观基准，但它们是为了证明某些数据库组件的设计或算法改进的而提出的。由于它们并不是为测试整个数据库而设计的，所以我们在这里只提两个常用的微观评测基准：一个是用于早期数据库的 AS3AP，另一个是用于 NoSQL 数据库的 YCSB+T。AS3AP 由于没有把 CRUD 操作包装成事务，连最基本的事务的原子性都无法评测，因此，这边就不细说了。YCSB+T 是 YCSB 的扩展，用来评估 NoSQL 数据库的事务能力。YCSB+T 只含有 1 张表，6 类事务（insert, random-scan, range-scan, update, delete 和 read-modify-write），其中 random-scan 和 range-scan 事务很大概率涉及分布式查询，read-modify-write 事务每次读写两行，可能引发分布式事务。YCSB+T 可以控制参数分布访问（zipfian 分布），因此会引发热点。
面向应用的评测基准
DebitCredit 模拟了一个虚拟的银行交易系统，之后 TPC Council 在它基础上增添了一些新的特征和规范，形成了 TPC-A，但这两款由于过于简单，目前已经弃用了，便不再赘述了。TATP 评测基准模拟了一个电信业务，有 4 张表，其中 3 张表依赖于 Subscriber 表，可根据该表进行分区。TATP 有 7 个事务（Get-Subscriber-Data, Get-New-Destination, Get-AccessData, Update-Subscriber-Data, Update-Location, InsertCall-Forwarding 和Delete-Call-Forwarding），其中的写事务都是单点操作，故而没有分布式事务。TATP的评价指标有两个：MQTH（平均吞吐）和每类事务的响应时间。TPC-C 模拟了一个以仓库为中心的订单处理应用，这是最流行的基准之一。TPC-C 包括 9 张表，除了 Item 表，其他的表都依赖于 Warehouse 表按照特定的规则进行扩展，如每个仓库为 10 个地区提供服务。TPC-C 中有 5 类事务（NewOrder, Payment, Order-Status, Delivery 和Stock-Level），New-Order 是一个读写事务，当 item 由远程仓库供应时，会产生 1% 的分布式事务，但是没有考虑分布式事务的跨节点数。StockLevel 是一个只读事务，但是都当存在良好分区时，该事务不会存在分布式查询。TPC-C 中考虑了 ACID 的功能测试，主要的评价指标有 tpmC，price/tpmC，watts/KtpmC。TPC-E 模拟一家股票公司的业务，包括 33 张表，12 类事务，尽管有些事务可能有引发分布式事务和分布式查询，但却无法控制它们跨节点的数目。
面向目的的评测基准
SmallBank 用于评价快照隔离下不同可串行协议，模拟了一个银行系统。它包括 3 张表(Account, Saving 和 Checking)，都依赖于 Account 表进行扩展，有 5 类事务，可能存在一定的分布式事务，但不可控。PeakBench 模拟了高冲突，动态变化和极度倾斜的负载特征，设计了一个精细控制冲突的生成器。它含有 8 张表，4 类读事务和 6 类写事务。由于它没有明显的分区键可以保证读事务在一个节点上，因此可能会引发分布式查询，故而，也会引发分布式事务。此外，PeakBench 能很好地模拟热点和冲突，因此能评测数据库在调度上的处理能力。
实验
在这节中，我们探索不同分布式事务比例和冲突强度下的性能表现，这对分布式事务型数据库的设计方面起着举足轻重的作用。我们将 OceanBase（v3.1.1）部署在 10 节点的集群上，其中有 9 个 OBServer 和一个 OBProxy，将某友商国产数据库也部署在 10 节点的集群上。
我们通过控制分布式事务比例和冲突强度扩展了 TPC-C 中的 NewOrder 事务，在原始的 TPC-C 中，NewOrder 更新 Stock 表的 5-15 个 item，涉及到 1% 的分布式事务。我们将该值进行参数化来评测不同分布式事务比例下的数据库性能。此外，以前的仓库 ID 的访问是均匀分布的，我们也扩展了仓库 ID 的生成来生成不同的冲突。
TPC-C 的不同分布式事务比例
在图 4-5，我们通过调整不同分布式事务比例，展示了 NewOrder 事务在 OceanBase 和某友商数据库上的吞吐。首先，OceanBase 的吞吐远远高于某友商数据库的吞吐，尽管当分布式事务比例增长时，吞吐呈现下降趋势，但吞吐始终高于某友商数据库。其次，无论是 OceanBase 还是某友商数据库，当分布式事务比例增长时，吞吐都呈现下降的趋势。这说明不同的分布式事务比例对分布式事务型数据库的性能影响非常大，在评测分布式事务型数据库时需要把这一因素考虑在内。
图4 不同分布式事务比例下的 TPC-C 在 OceanBase 上的性能表现
图5 不同分布式事务比例下的 TPC-C 在友商数据库品牌上的性能表现
TPC-C 的不同数据访问分布
在图 6-7中，我们通过控制仓库 ID 的数据访问分布展示了 TPC-C 中的 NewOrder 事务在 OceanBase 和某友商数据库上的吞吐。访问分布从均匀分布到 Zipfian 分布中 s 为 0.5，0.99 和1.5。从图中，我们可以看到冲突对OceanBase和某友商数据库的影响都很大，当冲突强度越大，吞入下降的越剧烈。从数据访问分布从均匀分布到 Zipfian0.99 时，OceanBase 下降了 38%，而某友商数据库下降了 81%。这是因为某友商数据库是 Share-Nothing 分离架构，事务链路更长，冲突处理能力更差。
图6 不同冲突强度下的 TPC-C 在 OceanBase 上的性能表现
图7 不同冲突强度下的 TPC-C 在某友商数据库上的性能表现
在以上所提及的事务型评测基准上，如果我们想要评测数据库在冲突下的处理能力，可以使用 YCSB+T，TATP，SmallBank 和 PeakBench。虽然上面提到的基准都涉及到分布式事务除了 TATP，但是它们都不能控制分布式事务的比例和跨节点的数量，这对分布式事务型数据库的性能有很大的影响。若是想评测分布式事务型数据库中对分布式查询的处理能力，用户可以利用 YCSB+T，TPC-E 和 PeakBench；至于弹性计算能力，可以使用 PeakBench 进行评估。最后，没有一款评测基准考虑到了存储移动，而这对分布式数据库中调度能力的评测是至关重要的。
总之，一方面，现有的评测基准可以被改变用于评估上述瓶颈点；另一方面，考虑到分布式事务型数据库在未来的发展和成熟度，急需一款全新的能够评测所有分布式事务型数据库瓶颈点的评测基准。
第三期 OceanBase 技术征文大赛
火热进行中！
诚邀大家围绕 OceanBase 性能参数调优、压缩、转储等方向进行内容写作，也欢迎投稿关于 OceanBase 的使用心得或与其他开源数据库功能对比的内容。（戳）
法拉利/迈凯伦/奔驰模型 + OceanBase官方奖牌 + 精美周边等众多奖品等你来挑战！