共计 5373 个字符，预计需要花费 14 分钟才能阅读完成。
在最新一届国内数据库顶级会议 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/defa…
- 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）的规模。
对于查问语句，有三点大的批改：
- 保留了 TPC-C 中的五个事务：新订单（New Order）：客户输出一笔新的订货交易；领取操作（Payment）：更新客户帐户余额以反映其领取情况；发货（Delivery）：发货（模仿批处理交易）；订单状态查问（Order Status）：查问客户最近交易的状态；库存状态查问（Stock Level）：查问仓库库存情况，以便可能及时补货。
- 批改了 TPC-H 的 22 条查问，批改了 table name 和 join key，并缩小了算术运算。
- 删掉了刷新函数（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 事务提供更好的服务。
举个栗子：隔离执行为 [email protected] tpmC，混合执行为 [email protected] 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/s6…
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 官网：
_https://stonedb.io/