如何给一个 HTAP 数据库做基准测试?| StoneDB学术分享会 #4

语言: CN / TW / HK

图片

在最新一届国际数据库顶级会议 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。

图片

Overview of HTAP Benchmarks

如图所示,这两种基准测试的核心区别在于,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

在 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)

图片

1CH-Benchmark 的执行规则

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

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

2CH-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

1HTAPBench 的模式和工作负载

这一块是和 CH-Benchmark(TPC-C + TPC-H)一样的,不赘述了。

2HTAPBench 的执行规则

  • 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 里面的所有数据进行计算。详细的不展开讲了,后续我把这篇论文拿出来解读一下子。

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

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