ToB企服应用市场:ToB评测及商务社交产业平台

标题: 如何给一个 HTAP 数据库做基准测试?StoneDB学术分享会第4期 [打印本页]

作者: 王國慶    时间: 2022-10-22 20:13
标题: 如何给一个 HTAP 数据库做基准测试?StoneDB学术分享会第4期

在最新一届国际数据库顶级会议 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 是专门测试 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 CH-Benchmark 的执行规则

这里就是需要用到基准参数控制 OLTP 和 OLAP 工作负载的并发执行。
2 CH-Benchmark 评测度量的性能指标

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


为了进行这一比较,我们首先从 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 的执行规则

固定 OLTP (tpmC)为首要目标,然后动态地控制 OLAP 的 Worker 线程。这种方式在执行过程中会根据 OLTP 的实时吞吐量来调整添加 OLAP 工作流,由此测试出在固定 OLTP 性能下能获得的最大 OLAP 性能。
优势是增加了时间窗口的选择。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

四、其他 HTAP 测试标准

首先介绍一下端到端(End-to-End)的 HTAP 评测基准,比如:
Swarm64 HTAP benchmark

稍早的有 Swarm64 HTAP benchmark:
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),比如:

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

这个就是在 select 基础上增加了一些 insert、delete 和 update 操作。
好了,以上就是本期的分享内容,欢迎点赞收藏转发,咱们下一期再见~
StoneDB 代码已完全在 Github 开源,欢迎关注:
https://github.com/stoneatom/stonedb
StoneDB 官网:
_https://stonedb.io/

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!




欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4