在最新一届国际数据库顶级会议 ACM SIGMOD 2022 上，来自清华大学的李国良和张超两位老师发表了一篇论文：《HTAP Database: What is New and What is Next》,并做了 《HTAP Database：A Tutorial 的专项报告。这几期学术分享会的文章，StoneDB 将系统地梳理一下两位老师的报告，带读者了解 HTAP 的发展现状和未来趋势。

在《深度干货！一篇 Paper 带您读懂 HTAP》这期中我们对HTAP产生的背景和现有的HTAP数据库及其技术栈做了比较全面的介绍。

在《爆肝整理 5000 字！HTAP 的关键技术有哪些？》这一期，我们对 HTAP 的五大关键技术进行了逐个解读。

本期主要介绍一下主流的几个的 HTAP 数据库基准测试。

编辑：宇亭

头图：Yeekin

关于 HTAP 数据库的基准测试，我们在学术分享会的第三期也介绍过一个来自慕尼黑工业大学 DB 组的相关工作，感兴趣可以了解一下，在这篇报告中，主要介绍两种：CH-Benchmark 和 HTAPBench。

如图所示，这两种基准测试的核心区别在于，CH-Benchmark 是混合负载测试，即 OLTP 和 OLAP 一起测；HTAPBench 是先固定统一 OLTP 的标准，然后在这个标准下再去控制测试 OLAP（当然还多了一个时间窗口的选择）。

这里顺便简单科普一下什么是 TPC-C 和 TPC-H：

先介绍一下 TPC 是啥，TPC（Transaction Processing Performance Council，事务处理性能委员会）是由数十家会员公司创建的非盈利组织，总部设在美国。TPC 的成员主要是计算机软硬件厂家，而非计算机用户，其功能是制定商务应用基准程序的标准规范、性能和价格度量，并管理测试结果的发布，其他更多信息就可以百度啦，总之这个组织在国际上很有影响力，学术界和工业界也都蛮认可的。

• TPC-C: TPC Benchmark C 于1992年7月批准，是一个在线交易处理（OLTP）基准。TPC-C 比以前的 OLTP 基准测试（如TPC-A）更复杂，因为它具有多种事务类型、更复杂的数据库和整体执行结构。TPC-C 涉及五个不同类型和复杂度的并发事务的混合，要么在线执行，要么排队等待延迟执行。数据库由九种类型的表组成，这些表存储的记录多而广泛。TPC-C 以每分钟事务数（tpmC）来衡量。虽然基准描述了批发供应商的活动，但 TPC-C 并不局限于任何特定业务部门的活动，而是代表必须管理、销售或分销产品或服务的任何行业。官网：https://www.tpc.org/tpcc/default5.asp
• TPC-H: TPC-H 是 TPC 组织制定的 OLAP 型数据库管理系统性能测试的一个标准，用来模拟真实商业的应用环境，以评估商业分析中决策支持系统（DSS）的性能。TPC-H 模拟真实商业交易数据库的动态查询，包含了一整套面向商业的 ad-hoc 查询和并发数据修改，强调测试的操作系统、数据库、和 I/O 性能，关注查询能力。通过TPC-H 测试，可以全方位评测系统的整体商业计算综合能力，具有普遍的商业实用意义。官网：https://www.tpc.org/tpch/

简单说，TPC-C 是专门测试 OLTP 的；TPC-H 是专门测试 OLAP 的。当然，其实还有个 TPC-DS 也比较知名（现在一般用来测数仓的），感兴趣也可以了解一下。

虽然以上两种测试基准已经非常给力，但是对于测试 HTAP 却又都显得片面了一些，因为 HTAP 数据库上是同时跑着 OLTP 和 OLAP 工作负载的，单独只考量 OLTP 或者 OLAP 的性能都是不对的，要测就得综合评估两者一起工作时的性能（比如 TP 和 AP 的隔离性），因此，后续有人提出了专门针对 HTAP 数据库的基准测试，其中比较知名的就是 CH-Benchmark 和 HTAPBench。

这两个测试基准单独拿出来都能写一篇文章，但在报告中其实只有两段话，我这一篇解读文章先做一个简单的介绍，后面会出扩充的讲解，欢迎大家关注 StoneDB 公众号。

一、CH-Benchmark

在 CH-Benchmark 中结合了 TPC-C 和 TPC-H 两种基准，它把原来 TPC-C 中的 9 个表和 TPC-H 中的 8 个表修改合并成了 12 个表，并将两者的伸缩模型也统一起来（Scaling TPC-H by the same factors of TPC-C）。

这里小编来解释一下,TPC-C 和 TPC-H 遵循不同的伸缩模型。TPC-C 遵循连续伸缩模型，仓库表中的数据随着系统性能的增加而增加。相反，TPC-H 遵循固定比例因子模型，其中数据库大小由比例因子设置，而与系统性能无关。在 CH-Benchmark 中要求令 TPC-H 的伸缩模型去与TPC-C的伸缩模型相适应（以TPC-C的伸缩模型为基础）,也就是要求根据TPC-C规则，去设定各表（Warehouse, Stock, Item, History, Neworder, Orderline, District, Customer, and Order）的规模。

关于查询语句，有三点大的修改：

1. 保留了 TPC-C 中的五个事务：新订单（New Order） ：客户输入一笔新的订货交易；支付操作（Payment） ：更新客户帐户余额以反映其支付状况；发货（Delivery） ：发货（模拟批处理交易）；订单状态查询（Order Status） ：查询客户最近交易的状态；库存状态查询（Stock Level） ：查询仓库库存状况，以便能够及时补货。
2. 修改了 TPC-H 的 22 条查询，修改了 table name 和 join key，并减少了算术运算。
3. 删掉了刷新函数（refresh functions）

1 CH-Benchmark 的执行规则

• 先仅测试 OLTP 或 OLAP，然后混合执行(OLTP+OLAP)
• 控制 OLTP 和 OLAP 并行流的个数（The number of parallel OLTP and OLAP streams）

这里就是需要用到基准参数控制 OLTP 和 OLAP 工作负载的并发执行。

2 CH-Benchmark 评测度量的性能指标

这里提出了一种基于参照系的评测指标，主要是结合每分钟事务(tpmC，transactions per minute)和每小时已完成查询(QphH，queries per hour)的指标。

• 面向 OLAP 的指标（OLAP 占据主导）：

• 面向 OLTP 的指标（OLTP 占据主导）：

为了进行这一比较，我们首先从 n 个 OLTP 和 m 个 OLAP 流隔离运行的运行中计算 tpmC 和 QphH 测量值之间的比率。然后，我们将此比率与并行执行 n 个 OLTP 和 m 个 OLAP 流的混合工作负载所产生的比率进行比较。与独立运行工作负载部分相比，并行执行的比例更高，这意味着数据库系统在并行执行中为 OLTP 事务提供更好的服务。

举个栗子：隔离执行为 5.7@5084 tpmC，混合执行为 6.5@5188 tpmC，这表示混合执行增加了 OLTP 吞吐量。

参考论文：Cole R, Funke F, Giakoumakis L, et al. The mixed workload CH-benCHmark[C]//Proceedings of the Fourth International Workshop on Testing Database Systems. 2011: 1-6.

二、HTAPBench

1 HTAPBench 的模式和工作负载

这一块是和 CH-Benchmark（TPC-C + TPC-H）一样的，不赘述了。

2 HTAPBench 的执行规则

• Fixed target tpmC with controllable OLAP workers

固定 OLTP （tpmC）为首要目标，然后动态地控制 OLAP 的 Worker 线程。这种方式在执行过程中会根据 OLTP 的实时吞吐量来调整添加 OLAP 工作流，由此测试出在固定 OLTP 性能下能获得的最大 OLAP 性能。

• Time window for querying newly-inserted data（查询新插入数据的时间窗口）

优势是增加了时间窗口的选择。Time window 这个不知道大家熟不熟悉，所谓时间窗口，就是根据时间划分窗口，是将指定时间范围内的所有数据组成一个 window，一次对一个 window 里面的所有数据进行计算。详细的不展开讲了，后续我把这篇论文拿出来解读一下子。

3 HTAPBench 评测度量的性能指标：

Under a certain TP throughput, the AP throughput per hour per worker（在一定 TP 吞吐量下，每个 Worker 每小时的 AP 吞吐量）

参考论文：Coelho F, Paulo J, Vilaça R, et al. Htapbench: Hybrid transactional and analytical processing benchmark[C]//Proceedings of the 8th ACM/SPEC on International Conference on Performance Engineering. 2017: 293-304.

三、对比

Comparison of HTAP End-to-End Benchmarks

• CH-Benchmark：
  • 优势：易用、执行灵活
  • 劣势：数据新鲜度较低
• HTAPBench：
  • 优势：数据新鲜度高
  • 劣势：固定了 OLTP 的指标

四、其他 HTAP 测试标准

首先介绍一下端到端（End-to-End）的 HTAP 评测基准，比如：

Swarm64 HTAP benchmark

稍早的有 Swarm64 HTAP benchmark：

• 结合了 CH-benchmark 和 HTAPBench
• 采用了 CH-benchmark 中的混合执行规则
• 采用了 HTAPBench 中的动态时间窗口。

Github地址：https://github.com/swarm64/s64da-benchmark-toolkit

OLxPBench

最近在 ICDE 2022 上 Kang 提出了 OLxPBench，这种基准测试有三个方法：Su-benchmark（TPC-C）、Fi-Benchmark（small-bank，面向小型银行）、Tabenchamark（TATP，面向电信行业）。

参考论文：Kang G, Wang L, Gao W, et al. OLxPBench: Real-time, Semantically Consistent, and Domain-specific are Essential in Benchmarking, Designing, and Implementing HTAP Systems[J]. arXiv preprint arXiv:2203.16095, 2022.

HATrick

来自威斯康辛大学 Miklai 在 SIGMOD 2022 新提出了一个叫 HATrick Benchmark 的混合基准。这个 HATrcik 融合了两个新的性能指标：吞吐边界（Throught frontier）和面向查询的新鲜度（Query-Driven Freshness）。

目前流行的HTAP基准包括 CH-Benchmark、HTAPBench 和 Swarm64。但在测试中有着以下的限制：无法测量性能隔离；无法测量新鲜度；无法识别设计类别。HATtrick benchmark 作为一个开源项目，补充了吞吐量前沿，整合了新鲜度测量方法，可以有效评测 HTAP 系统。

吞吐量：该概念的引入是为了捕捉事务处理和分析处理的性能。通过在2D图表中可视化吞吐量边界，我们可以理解 HTAP 系统的整体性能行为，并识别出问题所在。 Throught frontier

如上图，X 轴就是事务的吞吐，Y 轴就是分析的吞吐。这两张图怎么看的呢？简单来说，就是第一幅图中绿色曲线靠近红色对角线，表示系统相对稳定；第二张图中绿色曲线远离红色对角线，表示 AP 和 TP 两者工作负载受干扰较大。

新鲜度：该指标的设计，是为了捕捉HTAP系统对实时分析的支持程度。松散地说，HTAP系统的新鲜度是对OLAP查询可见的数据库更新的延迟度量。 参考论文：Milkai E, Chronis Y, Gaffney K P, et al. How Good is My HTAP System?[C]//Proceedings of the 2022 International Conference on Management of Data. 2022: 1810-1824.

Micro-benchmarks

除了端到端（End-to-End）的HTAP基准，还有一些特别针对数据组织（data organization，为啥特别要针对这个？因为数据组织是 HTAP 的五大关键技术之一的微型基准测试（Micro-benchmarks），比如：

• ADAPT Benchmark [Arulraj et al, SIGMOD 2016]

插入数据后简单的对一些列数据进行 select 操作。

• HAP Benchmark [Athanassoulis et al, VLDB 2019]

这个就是在 select 基础上增加了一些 insert、delete 和 update 操作。

好了，以上就是本期的分享内容，欢迎点赞收藏转发，咱们下一期再见~

StoneDB 代码已完全在 Github 开源，欢迎关注：

https://github.com/stoneatom/stonedb

StoneDB 官网：

_https://stonedb.io/