共计 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/