在最新一屆國際資料庫頂級會議 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）的規模。
關于查詢語句，有三點大的修改：
- 保留了 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 事務提供更好的服務。
舉個栗子：隔離執行為 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 開源，歡迎關注：