編者按：?Benchmarking 作為一個衡量標尺，可從不同的維度來客觀公正公平的評價相關產(chǎn)品，例如：對應數(shù)據(jù)測評而言，有 TPC-C、TPC-H，TP-DS 等等?，F(xiàn)有的這些測評 TPC-X 標準（Benchmarking）真的適合現(xiàn)有的 OLTP&OLAP 混合型數(shù)據(jù)庫嗎？現(xiàn)在對于很多 HTAP 數(shù)據(jù)庫廠商來說，對外所發(fā)布的性能對比數(shù)據(jù)都是以 TPC-H 為基準，但是單方面或者說只看一個 TPC-H 真的能真實地反映出這些 HTAP 數(shù)據(jù)庫的指標嗎？這篇來自德國慕尼黑工業(yè)大學數(shù)據(jù)庫研究組的 Paper 就給大家介紹了一種專門針對 HTAP 數(shù)據(jù)庫測評的標準，真正的從 HTAP 的基礎出發(fā)，引出如何正確地評測一款 HTAP 數(shù)據(jù)庫產(chǎn)品。希望本文能夠給諸多的 HTAP 廠商起到拋磚引玉的作用。
當然，除了 TPC-H 之外，StoneDB 也會持續(xù)基于此類專門針對 HTAP 的 Benchmarking 上做出優(yōu)化，我們后續(xù)會及時給社區(qū)的小伙伴們同步我們的最新進展。

論文翻譯：王學姣

背景介紹

在正式開始介紹這篇論文前，我想先介紹一下這篇論文作者的背景，首先是三位作者的單位，慕尼黑工業(yè)大學（TMU），想必在DB組待過的同學應該不會陌生，著名的 HyPer 數(shù)據(jù)庫就是出自他們的手里。

HyPer 是一款高速主內存數(shù)據(jù)庫系統(tǒng)，可在不影響性能的前提下，同時進行聯(lián)機事務處理(OLTP)和聯(lián)機分析處理(OLAP)。此外，它還能在同一個系統(tǒng)中對交易和分析進行統(tǒng)一處理。

怎么樣？是不是聽著很耳熟？沒錯，在我們上一期的學術分享會也提到，李國良教授他們就把 HyPer 定義為第一代的 HTAP 數(shù)據(jù)庫，可以說，任何一家研究 HTAP 數(shù)據(jù)庫的企業(yè)，理解學習 Hyper 的架構還是有很有大幫助的。

讓我們回到 2010 年，那一年，谷歌大數(shù)據(jù)“三駕馬車”的論文最后一篇已經(jīng)發(fā)表了四年，Hadoop 系列分化項目勢頭正猛；Oracle 收購了 Sun 公司間接獲得了 MySQL，引起軒然大波；放眼整個數(shù)據(jù)庫行業(yè)，關系型數(shù)據(jù)庫也迎來了 NoSQL 運動的又一波挑戰(zhàn)；OLTP 和 OLAP 都在飛速發(fā)展，商業(yè)數(shù)據(jù)智能化分析的價值不斷被放大，適用于 HTAP 的市場業(yè)務場景需求也不斷增加，當時很多人提出了要做“Real-Time Business Intelligence（實時商業(yè)智能）”，在慕尼黑工業(yè)大學的數(shù)據(jù)庫研究組組長?Thomas Neumann?教授和同組的?Alfons Kemper?教授較早地意識到了這一點，他們認為使用傳統(tǒng)復雜的 ETL 鏈路處理方式會有天然的缺陷，包括不限于陳舊過時的數(shù)據(jù)（即數(shù)據(jù)新鮮度低）、系統(tǒng)的冗余和高昂的軟硬件維護費用等等，為了嘗試解決這些缺陷，他們正式發(fā)表了 HTAP 領域最經(jīng)典的奠基論文之一《HyPer: Hybrid OLTP&OLAP High-Performance Database System》，這篇論文在數(shù)據(jù)庫學術界上影響深遠，除了 HTAP 概念的雛形，也提及了 In-memory、MVCC等關鍵技術，同時也標志著 HyPer 數(shù)據(jù)庫的正式誕生。

而今天介紹的這篇《Benchmarking Hybrid OLTP&OLAP Database Systems》，正是由這兩位教授和他們的博士研究生 Florian Funke 共同發(fā)表的，當然，那個時候 HTAP 的概念還沒有提出來，他們在文中用的都是 “OLTP&OLAP 數(shù)據(jù)庫系統(tǒng)”，此文發(fā)表于2011年，同年6月他們還發(fā)表了一篇《The mixed workload CH-benCHmark》，也是講的 HTAP 數(shù)據(jù)庫基準測試，同樣非常經(jīng)典，值得一讀。不得不說，人家這么搞數(shù)據(jù)庫還是厲害，頭一年整出個數(shù)據(jù)庫類別，第二年這個類別的數(shù)據(jù)庫怎么評測都給你整的明明白白，出招快準狠就是這樣。

摘要

最近有這么一個操作型或實時商業(yè)智能（business intelligence，BI）的案例。在操作型 BI 場景下， OLTP 數(shù)據(jù)庫和 OLAP 數(shù)據(jù)倉庫分離的傳統(tǒng)架構存在嚴重的延時。為解決這一問題，OLTP&OLAP 數(shù)據(jù)庫系統(tǒng)正在緊鑼密鼓地開發(fā)中。第一代 OLTP&OLAP 混合型數(shù)據(jù)庫系統(tǒng)的出現(xiàn)要求有能夠衡量其性能的工具。

當前市場中已經(jīng)存在一些分別針對 OLTP 和 OLAP 工作負載廣泛使用的標準化基準，但是卻沒有針對 OLTP 和 OLAP 混合負載的基準。因此，我們基于針對 OLTP 負載的 TPC-C 基準和針對 OLAP 負載的 TPC-H 基準，定義了一個可以測試 OLTP 和 OLAP 混合負載的基準：TPC-CH。TPC-CH 基準執(zhí)行了如下混合工作負載：基于 TPC-C 的訂單輸入處理的事務性工作負載，以及基于該銷售數(shù)據(jù)庫的對應的 TPC-H 等效 OLAP 查詢套件。派生于最廣泛使用的 TPC 基準，TPC-CH 基準產(chǎn)生的結果與混合型系統(tǒng)和傳統(tǒng)的單工作負載系統(tǒng)具有很高的可比性。因此，我們能夠將我們的（或其他的）OLTP&OLAP 混合型數(shù)據(jù)庫系統(tǒng)同 OLTP 系統(tǒng)（如 VoltDB）的 OLTP 性能和OLAP 系統(tǒng)的 OLAP 性能進行比較。

1. 簡介

在線事務處理（online transaction processing，OLTP）和在線分析處理（online analytical processing，OLAP）這兩個領域對數(shù)據(jù)庫架構提出了不同的挑戰(zhàn)。事務通常是短期運行的，大多涉及選擇性很強的數(shù)據(jù)訪問；而分析查詢通常是長期運行的，大多需要掃描絕大部分數(shù)據(jù)。因此，具有高關鍵任務事務率的客戶目前只能操作兩個獨立的系統(tǒng)：一個操作型數(shù)據(jù)庫用于處理事務，一個數(shù)據(jù)倉庫用于分析查詢。數(shù)據(jù)倉庫定期從 OLTP 系統(tǒng)中同步更新數(shù)據(jù)，并將最新數(shù)據(jù)轉換為易于分析的模型。人們也嘗試過在操作型系統(tǒng)中直接執(zhí)行分析處理，但是這樣做帶來了難以接受的事務處理性能損耗【DHKK97】。

雖然這種數(shù)據(jù)分級（data staging）方法允許針對各自的工作負載對每個系統(tǒng)進行調優(yōu)，但存在以下幾個固有的缺點: 必須購買和維護兩套軟件和硬件系統(tǒng)。根據(jù)數(shù)據(jù)分級實施情況，可能需要增加額外的系統(tǒng)。所有系統(tǒng)都必須存儲相同數(shù)據(jù)的冗余副本，但最重要的是，用于分析的數(shù)據(jù)并非最新數(shù)據(jù)，而是數(shù)據(jù)倉庫中的陳舊快照。

近期有如下一個實時 BI 的案例。SAP 的聯(lián)合創(chuàng)始人 Hasso Plattner【Pla09】發(fā)表了自己對當前 OLTP 和 OLAP 分離的現(xiàn)狀的看法，并表示對市場更重視 OLTP 而感到遺憾。他強調了 OLAP 在戰(zhàn)略管理中的必要性，并將實時分析對管理的預期影響與互聯(lián)網(wǎng)搜索引擎對世界的影響進行了對比。實時 BI 推動了新的數(shù)據(jù)庫架構的誕生。這些新的數(shù)據(jù)庫架構通常以內存（in-memory）技術為基礎，如用于運營報告的行列混合存儲 OLTP 數(shù)據(jù)庫架構【SBKZ08，BHF09，KGT+10】和 HyPer【KN11】。它們使用一個系統(tǒng)來處理兩種工作負載，從而消除了數(shù)據(jù)分級的缺點。

不同的策略看起來可以在頻繁的插入和更新與長時間運行的 BI 查詢尋求平衡點：由交易觸發(fā)的修改可以作為增量數(shù)據(jù)收集起來，并定期合并到作為查詢基礎的主數(shù)據(jù)集中【KGT+10】?；蛘撸梢栽?DBMS 上開發(fā)支持版本控制功能，從而實現(xiàn)基于最新數(shù)據(jù)的事務處理與基于版本化數(shù)據(jù)快照執(zhí)行的查詢之間的隔離。

這種新型 DBMS 的產(chǎn)生要求能分析其性能的方法。混合系統(tǒng)之間需要進行對比，以便對不同的實現(xiàn)策略進行比較。它們還必須與傳統(tǒng)的通用 DBMS 和單工作負載 DBMS 進行比較，以證明其在性能和資源消耗方面的競爭力。

我們提出了 TPC-CH，這是一個旨在為所有類型的系統(tǒng)生成高度可比結果的測試基準（參見圖1）。下一章評價了各相關基準。第3章描述了 TPC-CH 的設計。第4章描述了我們用于測試的系統(tǒng)。第5章提供了各類型 DBMS 代表的設置以及測試結果。第6章對本論文內容進行了總結。

2. 相關工作

TPC（Transaction Processing Performance Council，事務處理性能委員會）指定了在工業(yè)界和學術界廣泛使用的基準來測量數(shù)據(jù)庫系統(tǒng)的性能特征。TPC-C 及其后繼產(chǎn)品 TPC-E 模擬了 OLTP 工作負載。TPC-C 中使用的模型由圍繞產(chǎn)品或服務的管理、銷售和分銷的九個表（relation）和五個事務組成。數(shù)據(jù)庫的初始數(shù)據(jù)隨機產(chǎn)生，隨著新訂單的處理而更新。TPC-E 模擬了一家經(jīng)紀公司的工作負載。它有一個更復雜的模型和偽真實的內容，用來更好地匹配實際的客戶數(shù)據(jù)。但是，與 TPC-E 相比，TPC-C 的使用更為普遍【Tra10c，Tra10d】，因此具有更好的可比性。

TPC-H 是 TPC 目前唯一活躍于市場上的決策支持基準。它模擬了類似于 TPC-C 的業(yè)務場景中的分析工作負載。該基準包含8個表以及能夠通過這8個表得到預期結果的22個查詢。它的后繼產(chǎn)品 TPC-DS 將采用星形模型、包含大約100個決策支持查詢和填充數(shù)據(jù)庫的 ETL 過程描述。但是，TPC-DS 目前尚未正式完成。

注意，通過簡單地使用兩個 TPC 模型（一個用于 OLTP，一個用于 OLAP）為混合型 DBMS 構建一個基準并不能產(chǎn)生有意義的結果。這樣的基準無法洞察系統(tǒng)如何處理其最具挑戰(zhàn)性的任務: 即如何并發(fā)處理對同一數(shù)據(jù)集事務和分析查詢。

在線事務處理（CBTR）綜合基準【BKS08】旨在衡量由 OLTP 和運營報告組成的工作負載的影響。CBTR 沒有結合現(xiàn)有的標準化基準，而是使用了一個企業(yè)的真實數(shù)據(jù)。作者提到了數(shù)據(jù)生成器的概念，從而能夠產(chǎn)生系統(tǒng)間可比較的結果。然而，CBTR 的重點似乎是為了某個企業(yè)的特定用例來對不同的數(shù)據(jù)庫系統(tǒng)進行比較。

3. 基準設計

我們設計 TPC-CH 的首要目標是可比性。因此，我們將 TPC-C 和 TPC-H 進行了結合。這兩個基準已經(jīng)得到了廣泛的使用并得到了市場的認可，且能夠快速實施。并且二者在設計上擁有足夠高的相似度，從而保證了可比性。

TPC-CH 由未經(jīng)修改的 TPC-C 模型和事務、以及 TPC-H 查詢的改編版本構成。由于這兩個基準的模型（參見圖2）都模擬了“必須管理、銷售或分發(fā)產(chǎn)品或服務”的業(yè)務【Tra10a，Tra10b】，它們之間有一些相似之處。兩個模型都包含ORDER(S) 和 CUSTOMER 表。此外，ORDER-LINE（TPC-C）和 LINEITEM（TPC-H）模型實體是 ORDER(S) 的子實體，因此彼此相似。

TPC-CH 保持所有 TPC-C 實體和關系完全不變，并集成了 TPC-H 模型中的 SUPPLIER、REGION 和 NATION 表。這些表在 TPC-H 查詢中頻繁使用，并允許以非侵入的方式集成到 TPC-C 模型中。SUPPLIER 包含固定數(shù)量（10,000條）的條目。因此，STOCK 中的一條記錄可以通過 STOCK.S I ID × STOCK.S W ID mod 10, 000 = SUPPLIER.SU SUPPKEY 與其唯一的供應商（SUPPLIER 表中對應記錄）關聯(lián)起來。

TPC-C 中的原始 CUSTOMER 表不包含引用自 NATION 表的外鍵。我們并沒有改變原始模型，從而保持了與現(xiàn)有 TPC-C 的兼容性，所以外鍵是從字段 C STATE 的第一個字符開始計算的。TPC-C 規(guī)定第一個字符可以有62個不同的值（即大寫字母、小寫字母、數(shù)字），因此我們選擇了62個國家來填充 NATION。根據(jù) TPC-H 規(guī)范，主鍵 N NATIONKEY 是一個標識符。它的值被規(guī)定，從而使得與這些值相關聯(lián)的 ASCII 值是一個字母或數(shù)字,即 N NATIONKEY ∈ [48, 57]∪[65, 90]∪[97. 122]。因此，不需要額外的計算來跳過 ASCII 碼中數(shù)字、大寫字母和小寫字母之間的間隔。不支持從字符轉換到 ASCII 碼的數(shù)據(jù)庫系統(tǒng)可能會偏離 TPC-H 模式，使用單個字符作為 NATION 的主鍵。REGION 包含國家的五個地區(qū)。新表之間的關系使用簡單的外鍵字段來建模：NATION.N REGIONKEY 和 SUPPLIER.SU NATIONKEY。

3.1 交易和查詢

如圖4中的概述所示，該工作負載由五個原始 TPC-C 事務和22個來自 TPC-H 的查詢組成。由于 TPC-C 模型是 TPC-CH 模型的子集，因此這5個原始事務可以直接執(zhí)行，無需修改:

New-Order 該事務將一個帶有多行數(shù)據(jù)的訂單輸入至數(shù)據(jù)庫中。

對于每行數(shù)據(jù)，99%的情況下，供應倉庫是主倉庫。主倉庫是固定的，其 ID 與一個終端相連。為了模擬用戶數(shù)據(jù)輸入錯誤，1%的事務失敗并觸發(fā)回滾：

• Payment：該事務更新客戶的賬號余額。15%的情況下，客戶是從一個隨機的遠程倉庫中選擇的，在另外85%的情況下，客戶與主倉庫相關聯(lián)。在60%的情況下，客戶是按姓氏選擇的，其他情況下則是按三要素鍵（three-component key）進行選擇的。

• Order-Status：該只讀事務報告客戶最后一個訂單的狀態(tài)。60%的情況下，客戶是按姓氏選擇的。在其他情況下，客戶按照客戶 ID 選擇。所選客戶始終與主倉庫相關聯(lián)。

• Delivery：該事務一次交付10個訂單。所有訂單都與主倉庫相關聯(lián)。

• Stock-Level：該只讀事務只對主倉庫進行操作，并返回那些最近有售賣記錄且?guī)齑嫠降陀陂撝档膸齑嫔唐返臄?shù)量。

TPC-CH 與其底層的 TPC-C 基準不同，因為它不模擬終端，并且在沒有任何思考時間的情況下生成客戶端請求，正如【Vola】所提議的。從而可以在相對較小的數(shù)據(jù)庫配置上實現(xiàn)非常高的事務率。TPC-CH 中的事務與 TPC-C 中的事務是相同的，因此 TPC-CH 的結果可直接與做了同樣修改的 TPC-C 的結果進行比較，例如 VoltDB【Vola】。此外，這些修改可以很容易地應用于現(xiàn)有的 TPC-C 工具，從而產(chǎn)生的結果與 TPC-CH 兼容。

對于工作負載中的 OLAP 部分，我們將 TPC-H 中的22個查詢應用到了 TPC-CH 模式中。在修改這些查詢以使之符合 TPC-CH 模型的過程的同時，我們也確保修改后的查詢保留了它們的業(yè)務語義和語法結構。例如，查詢5列出了通過本地供應商獲得的收入（請見Listing 1 和 Listing 2）。這兩個查詢將相似的表連接起來，具有相似的選擇標準，并執(zhí)行求和、分組和排序操作。

Listing 1: TPC-CH 查詢5

Listing 2: TPC-H 查詢5

TPC-CH 不需要 TPC-H 規(guī)定的刷新函數(shù)，因為 TPC-C 事務會不斷地更新數(shù)據(jù)庫。查詢何時必須包含這些更新將在下一章進行詳細說明。

3.2 基準參數(shù)

TPC-CH 有四個參數(shù)：第一個參數(shù)用于指定數(shù)據(jù)庫大小。在 TPC-C 中，數(shù)據(jù)庫的大小由倉庫的數(shù)量來決定。大多數(shù)表隨著倉庫數(shù)量的增加而增加，只有 ITEM、SUPPLIER、NATION 和 REGION 的大小不變。

第二個參數(shù)用于指定工作負載的構成。它可以純 OLAP、純 OLTP、也可以是兩種工作負載的任意組合。該參數(shù)通過指定連接到數(shù)據(jù)庫系統(tǒng)的并行 OLTP 和 OLAP 會話（流）的數(shù)量來設置。OLTP 會話按照官方規(guī)范【Tra10a】中描述的分布順序調度隨機 TPC-C 事務。OLAP 會話針對由這22個查詢組成的查詢集進行持續(xù)迭代。每個會話以不同的查詢開始，以避免會話之間的緩存效應，如圖4所示。

第三個輸入?yún)?shù)用于指定隔離級別。較低的隔離級別（如讀已提交）意味著較高的處理效率，而較高的隔離級別則保證了事務和查詢的結果質量。最后一個參數(shù)用來指定用做分析基礎的數(shù)據(jù)的新鮮度。它僅適用于工作負載組合同時包含 OLTP 和 OLAP 兩種負載的情況。數(shù)據(jù)新鮮度通過事務的時間或數(shù)量來指定，在該時間或數(shù)量之后，新發(fā)出的查詢集必須包含最新的數(shù)據(jù)。從而該基準可以同時支持兩種數(shù)據(jù)架構：一種可以支持在單一數(shù)據(jù)集上同時進行 OLTP 和 OLAP，另一種則是通過數(shù)據(jù)增量的應用來實現(xiàn)對 OLTP 和 OLAP 的支持。

3.3 報告要求

除了對用到的硬件和軟件的描述之外，報告還需要包含以下系統(tǒng)特征信息：OLTP 引擎的性能由 New-Order 事務和所有事務的吞吐量來衡量。在 OLAP 端，針對每一次迭代和每一個會話統(tǒng)計查詢響應時間。中值和查詢吞吐量也是統(tǒng)計指標。除了新鮮度參數(shù)之外，需要報告數(shù)據(jù)集已存在的時長最大值。對于內存型（in-memory）系統(tǒng)，總內存消耗會按一定時間間隔報告，其中包括已分配但尚未使用的內存塊。圖5提供了一個報告樣例。

4. 被測系統(tǒng)

在圖1中，我們將 DBMS 分為四類。我們從四類 DBMS 中各選了一個代表進行了 TPC-CH 基準測試。

4.1 分析型數(shù)據(jù)庫（OLAP）

MonetDB 是針對內存型 OLAP 數(shù)據(jù)庫的最有名的列存存儲方案。關于該系統(tǒng)的概述可以在總結性文件【bmk09】中找到。因此，我們使用 MonetDB 作為“OLAP型”類別的代表。此類別還包括 SAP 的 TREX (BWA)、IBM Smart Analytics Optimizer 和 Vertica 分析數(shù)據(jù)庫。

4.2 事務型數(shù)據(jù)庫（OLTP）

最近一家名為 VoltDB 的初創(chuàng)公司將?Michael Stonebraker?牽頭創(chuàng)造的 H-Store 原型【KKN+08】進行了商業(yè)化。VoltDB 是一個高性能的內存型 OLTP 系統(tǒng)，它采用無鎖方法【HAMS08】進行事務處理，其中事務在私有分區(qū)上操作，并以串行方式執(zhí)行【Volb】。因此，我們使用 VoltDB 作為事務型數(shù)據(jù)庫的代表。該類別還包括以下系統(tǒng): P*Time【CS04】、IBM solidDB、Oracle 的 TimesTen 以及新啟動的開發(fā)項目 Electron DB、Clustrix、Akiban、dbShards、NimbusDB、ScaleDB 和 Lightwolf。

4.3 通用數(shù)據(jù)庫（Universal）

此類別包含基于磁盤存儲的通用數(shù)據(jù)庫。我們選擇了一個流行的、商業(yè)上可用的系統(tǒng) System X 作為此類別的代表。

4.4 混合型數(shù)據(jù)庫（Hybrid）

這一類別包括 Hasso Plattner【Pla09】概述的 SAP 新數(shù)據(jù)庫開發(fā)和我們的 HyPer【KN11】系統(tǒng)。Crescando【GUMG10】是一個特殊的 OLTP&OLAP 混合型系統(tǒng)，但是它的查詢能力比較有限。

4.4.1 HyPer：虛擬內存快照

我們開發(fā)了一個新型 OLTP&OLAP 混合型數(shù)據(jù)庫系統(tǒng)，該系統(tǒng)通過操作系統(tǒng)的虛擬內存管理【KN11】對事務數(shù)據(jù)進行快照。在該架構下，OLTP 進程“擁有”數(shù)據(jù)庫，并定期（秒級或分鐘級）派生出 OLAP 進程。此 OLAP 進程創(chuàng)建了數(shù)據(jù)庫的新事務一致性快照。因此，我們利用操作系統(tǒng)提供的功能為新的、重復的進程創(chuàng)建虛擬內存快照。例如，在 Unix 中，這是通過調用 fork() 來為 OLTP 進程創(chuàng)建子進程來實現(xiàn)的。為了保證事務的一致性，fork() 應該只在兩個連續(xù)的事務之間執(zhí)行，而不應該在一個事務執(zhí)行過程中執(zhí)行。在4.4.1節(jié)中，我們將使用 undo 日志將動作一致的快照（在某個事務執(zhí)行過程中創(chuàng)建的）轉換成事務一致的快照來放寬此約束。

通過派生產(chǎn)生的子進程會獲得父進程地址空間的精確副本，如圖6中的重疊的頁框面板所示。使用 fork() 創(chuàng)建的這個虛擬內存快照將用于執(zhí)行一個 OLAP 查詢會話，如圖6中的右側部分所示。

快照精確地停留在 fork() 發(fā)生時的狀態(tài)。值得慶幸的是，最先進的操作系統(tǒng)不會立即復制這些內存段。相反，這些操作系統(tǒng)采用了一種延遲更新時復制（lazy copy-on-write）策略，如圖6所示。最初，父進程（OLTP）和子進程（OLAP）通過將任一虛擬地址（例如，到對象 a）轉換到相同的物理主存位置來共享相同的物理內存段。共享內存段在圖中用虛線框標識。一個虛線方格表示一個尚未復制的虛擬內存頁面。只有當對象被更新時，比如數(shù)據(jù)項 a，操作系統(tǒng)和硬件支持的更新時復制機制才啟動對 a 所在的虛擬內存頁面的復制。從而產(chǎn)生了可由執(zhí)行事務的 OLTP 進程訪問的新狀態(tài) a’，以及可由 OLAP 查詢會話訪問的舊狀態(tài) a。與圖中所示不同，額外的頁面實際上是為啟動頁面更改的 OLTP 進程創(chuàng)建的，而 OLAP 快照引用的是舊頁面。如果創(chuàng)建了多個這樣的快照，這一細節(jié)對于估算空間消耗非常重要（參見圖7）。

至此，我們已經(jīng)描繪了一個使用兩個進程的數(shù)據(jù)庫架構，一個進程用于 OLTP，而另一個用于 OLAP。由于 OLAP 查詢是只讀的，它們可以很容易地在共享相同地址空間的多個線程中并行執(zhí)行。盡管如此，我們可以避免任何同步（鎖定和鎖存）開銷，因為 OLAP 查詢不共享任何可變的數(shù)據(jù)結構。現(xiàn)代多核計算機通常具有十個以上的內核，通過這種查詢間的并行化，肯定可以大幅提高速度。

充分利用多核服務器的另一種可能性是創(chuàng)建多個快照。HyPer 架構允許任意快照。這可以簡單地通過周期性（或按需）派生新的快照并由此啟動新的 OLAP 查詢會話進程來實現(xiàn)。圖7提供了一個示例。圖7中描繪了一個 OLTP 進程的當前數(shù)據(jù)庫狀態(tài)（最上層）和三個活躍的查詢會話進程的快照，按時間順序排列，時間越近，越靠上層。連續(xù)的狀態(tài)變化由數(shù)據(jù)項 a（最老的狀態(tài)）、a′、a′′和a′′′（最新的事務一致狀態(tài)）的四種不同狀態(tài)來突出顯示。顯然，大多數(shù)數(shù)據(jù)項在不同的快照之間不會改變，因為我們預期的快照間隔為幾秒鐘，而不是像當前使用 ETL 數(shù)據(jù)暫存方式的獨立數(shù)據(jù)倉庫解決方案那樣以幾分鐘或幾小時為間隔。原則上，活躍快照的數(shù)量不受限制，因為每個快照都“活在”自己的進程中。通過調整優(yōu)先級，我們可以確保任務關鍵型 OLTP 進程始終分配有一個內核，即使 OLAP 進程數(shù)量眾多和/或利用多線程，從而超過了內核數(shù)量。

會話的最后一個查詢完成后，快照將被刪除。這可以通過簡單地終止正在執(zhí)行查詢會話的進程來完成。另外，快照刪除不需要按照創(chuàng)建時間順序進行。一些快照可能會因為某些特殊原因，比如用于詳細盤點，需要保留更長時間。但是，快照的內存開銷與從創(chuàng)建該快照到下一個快照（如果存在）或當前時間之間執(zhí)行的事務數(shù)量成比例。該圖使用數(shù)據(jù)項 c 說明了這一點，數(shù)據(jù)項 c 被物理復制用于“中年”快照，因此被最老的快照共享和訪問。與我們的直覺有些不太一樣的是，“中年”快照有可能會在早于最老的快照被終止，因為 c 駐留的頁面將被操作系統(tǒng)/處理器自動檢測為通過與物理頁面相關聯(lián)的引用計數(shù)器與最老的快照共享。因此，最老快照在“中年”快照終止后仍然存在——不像 a’所在的頁面那樣，最老快照在“中年”快照進程終止時被釋放。最新的快照訪問了包含在當前 OLTP 進程的地址空間中的狀態(tài) c’。

5. 結果

在本節(jié)中，我們給出了 TPC-CH 的粗略結果。我們使用的測試機使用的是 RHEL 5.4 操作系統(tǒng)，配有兩個四核2.93 GHz Intel R Xeon R 處理器和 64GB 內存。所有數(shù)據(jù)庫都擴展到了12個倉庫，對查詢集共執(zhí)行了5次迭代。

對于 MonetDB，我們評估了一個執(zhí)行純 OLAP 工作負載的基準實例。我們排除了 OLTP，因為 MonetDB 中缺少索引會影響事務處理效率。我們在圖9中展示了處理三個并行 OLAP 會話的結果。由于在這種情況下不涉及對數(shù)據(jù)庫的更新，所以新鮮度和隔離級別參數(shù)無效。將查詢流的數(shù)量增加到5幾乎不會改變吞吐量，但是查詢執(zhí)行時間幾乎增加了一倍。單個查詢會話執(zhí)行將執(zhí)行速度提高了10%到45%，但是吞吐量下降到每秒0.55個查詢。

對于 VoltDB，工作負載僅包括事務。每個倉庫/分區(qū)一個“站點”（即12個站點）在我們的服務器上產(chǎn)生最佳結果。與 TPC-CH 規(guī)范不同，我們允許 VoltDB 只執(zhí)行單分區(qū)事務，如【Vola】中所建議的，并跳過那些涉及多個倉庫的 New-Order 和 Payment 實例。VoltDB 中的隔離級別是可序列化（serializable）。

對于 System X，我們使用了25個 OLTP 會話和3個 OLAP 會話。對于 OLTP 和 OLAP，配置的隔離級別是讀已提交，我們對五個事務的組使用組提交。由于系統(tǒng)針對單個數(shù)據(jù)集進行操作，所以每個查詢都是對最新的數(shù)據(jù)進行操作。圖9顯示了此設置下的測試結果。將 OLAP 會話從3個增加到12個之后，查詢吞吐量從0.38個查詢/秒提高到1.20個查詢/秒，但是這種調整導致查詢執(zhí)行時間增加了20%到30%，且 OLTP 吞吐量下降14%。添加更多的 OLTP 會話也會大大增加查詢執(zhí)行時間。

對于 HyPer，我們混合使用5個 OLTP 會話和3個并行 OLAP 會話來執(zhí)行查詢。我們并沒有像 VoltDB 那樣簡化單分區(qū)事務的運行，而是用3.1節(jié)中指定的跨倉庫事務來挑戰(zhàn) HyPer。在一種設置下，OLAP 會話對最初加載的數(shù)據(jù)進行操作（參見圖9）。在第二種設置下，為每個新的查詢流創(chuàng)建一個新的快照（參見圖9）。查詢與事務通過快照隔離。在 OLTP 端，隔離級別為可序列化。

因為 HyPer 還沒有獨立的客戶端和服務器進程，所以結果是由包含兩個組件的單個驅動程序產(chǎn)生的。因此，HyPer 排除了由進程間通信引起的潛在性能損失，但其他被測系統(tǒng)卻沒有。HyPer 強大的 OLTP 性能源于其能將事務編譯成機器碼。VoltDB 使用 Java 編寫的存儲過程。

圖9顯示了 HyPer 和 VoltDB 的內存消耗。我們在這里沒有提供 MonetDB 結果，因為 MonetDB 數(shù)據(jù)庫大小不會隨著時間的推移而變化。HyPer 對5個 OLTP 會話并發(fā)運行3個查詢會話，并在每次迭代后生成一個新的虛擬機快照。VoltDB 執(zhí)行純 OLTP 工作負載。該圖顯示了初始加載完成后的內存消耗。

6. 小結

本文中，我們展示了一個適用于混合 OLTP 和 OLAP 數(shù)據(jù)庫系統(tǒng)的基準——TPC-CH。這個基準是基于標準化的 TPC-C 和 TPC-H 基準開發(fā)的。它不僅適用于混合 DBMS，還可以用于將混合 DBMS 與 OLTP、OLAP、傳統(tǒng)數(shù)據(jù)庫以及通用數(shù)據(jù)庫進行比較。我們用 TPC-CH 對各類數(shù)據(jù)庫的主流產(chǎn)品進行了測試并證實了上述觀點。

鳴謝

我們非常感謝 Dagstuhl 研討會（Dagstuhl Workshop）在2010年9月進行的關于“穩(wěn)健查詢處理（Robust Query Processing）”研討中，關于該基準卓有成效的探討。另外，感謝 Stefan Krompa? 幫助實現(xiàn)了 System X 基準測試。

考慮篇幅，我們會把完整包含論文的附錄的翻譯文章放到官網(wǎng)上，歡迎大家前往閱覽。

StoneDB 已經(jīng)正式開源，歡迎關注我們https://github.com/stoneatom/stonedb

參考文獻

本文系列責編：李明康

論文解讀僅供知識分享，難免有誤，如有不足，歡迎指正