數據庫OceanBase創始人陽振坤：通關TPC-C到底有多難？

自從螞蟻金服自研數據庫OceanBase得到TPC-C測試第一名後，引發了行業內外大量關注，咱們衷心的感謝你們對OceanBase的支持與厚愛，也虛心聽取外界的意見和建議。爲了讓你們更好的瞭解測試的技術細節，咱們特地邀請了OceanBase的核心研發人員對本次測試作專業的技術解讀，本文爲第一篇，後續文章也將於近日對外發布。

OceanBase於2010年立項，九年來，研發人員一步一個腳印，不斷的對OceanBase作出改進以及增長新的功能。OceanBase也從服務於支付寶開始，逐漸對外開放，爲廣大的各行業客戶提供服務。在這個過程當中，咱們但願外界對OceanBase的實力有更直觀的瞭解，讓客戶對咱們的產品更有信心，TPC-C測試爲咱們提供了一個絕佳的舞臺。

經過本次測試，咱們發現了OceanBase的一些不足之處，好比，以前的單機數據庫只能經過增長CPU、內存等來提升處理能力，OceanBase經過分佈式架構，可讓大量的普通硬件設備像一臺電腦同樣處理數據，想提升性能只需增長設備便可，可是，OceanBase在每臺設備上的性能還有很多提高空間；另外，OceanBase支持的功能、易用性、數據庫生態相比業界標杆還有一些差距。

接下來，OceanBase將在兩個重點方向上發力，一個是兼容Oracle數據庫提供的各類功能，方便客戶切換使用不一樣的數據庫，另外一個是提高OLAP處理能力，也就是數據分析挖掘等方面的能力，用同一套引擎同時支持OLAP與OLTP，完善OceanBase在大數據處理方面的能力。

後續，咱們還將開源本次TPC-C測試工具，但願與業界同行多多交流，共同探討數據庫技術的發展與將來。

正文

網絡上有不少介紹TPC-C benchmark的文章，並且某些數據庫廠商還聲稱本身進行了TPC-C測試，還得到了單機百萬級tpmC、分佈式千萬級tpmC等等。真實狀況到底是怎樣呢？

就像不少人知道的，國際事務性能委員會（TPC）組織是數十家會員公司建立的非盈利組織，TPC-C是TPC組織制定的關於商品銷售的訂單建立和訂單支付等的基準測試標準，是數據庫聯機交易處理系統（OLTP）的權威基準測試標準。TPC-C有5種事務，每種事務有規定的比例，分別訂單支付不低於43%，訂單查詢、訂單發貨和庫存查詢各不低於4%，其他則爲訂單建立(不高於45%)，tpmC值是訂單建立事務每分鐘執行的數量。

TPC-C benchmark測試必須經過TPC組織的審計（準確地講是TPC-C組織承認的審計員的審計），經過審計的TPC-C的結果，其完整詳實的測試報告（包括測試廠家、數據庫版本、詳細的軟硬件配置、測試過程等）將公佈在TPC組織的網站（ www.tpc.org ）上。沒有經過TPC的審計而擅自聲稱本身經過了TPC-C測試、得到XXX tpmC，不只是侵權，也是不合法的。除了OceanBase，目前在TPC網站上尚未看到任何一個國產數據庫的TPC-C benchmark的測試報告，不管是徹底自主研發的，仍是在開源基礎上修改的。

爲何TPC-C benchmark測試必需要經過TPC組織的審計呢？這還得從TPC組織的誕生提及。1980年代數據庫聯機交易處理系統即OLTP（Online Transactional Processing）出現後，極大地推進了諸如自動提款機（Automated teller transaction，ATM）等聯機交易處理系統的發展。每一個數據庫廠商都試圖向客戶證實本身的系統性能最好、處理能力最強，但因爲沒有統一的性能測試標準，更沒有誰來監督性能測試的執行和結果發佈，一方面客戶沒法在不一樣系統之間進行比較，另外一方面數據庫廠商各自的性能測試數據也沒有足夠的說服力。

1985年初，Jim Gray聯合24位來自學術界和工業界的同仁發表了名爲「A Measure of Transaction Processing Power」的文章，提出了一種在線事務處理能力的測試方法DebitCredit。DebitCredit定義了數據庫性能benchmark的一些關鍵特徵（ http://www.tpc.org/informatio... ）：

• 定義了被測系統的功能要求而不是軟件硬件自己
• 規定了被測系統的擴展準則，即性能與數據量相匹配
• 規定被測系統的事務須要在指定時間內完成（好比95%事務在1s內完成）
• 把被測系統的總體成本歸入性能benchmark

DebitCredit爲數據庫的聯機交易處理系統性能創建了統一的、科學的衡量標準，後續相關的benchmark基本都以此爲基礎發展而來。然而一些廠商卻刪掉DebitCredit標準中的一些關鍵要求後進行測試以便得到更好的性能值（這種作法如今也被一些國內數據庫廠商用在TPC-C benchmark測試上），這致使數據庫的聯機交易處理系統性能的衡量標準並無真正統一：若是說Jim Gray等人爲數據庫的聯機交易處理系統benchmark制定的一個法律（DebitCredit），但卻沒有執法隊伍來保障法律的執行。1988年TPC組織的創始人Omri Serlin（ http://www.tpc.org/informatio... ）成功地說服8家公司成立了非盈利的TPC組織，統一制定和發佈benchmark標準並監督和審計數據庫benchmark測試，狀況才發生了根本的改變。

通過三十多年的發展，TPC組織的成員超過了20個，誕生和完善了數據庫性能的多個benchmark標準，並被全世界接受。好比TPC-C的第一個版本是在1992年發佈的，以後經歷了屢次修訂，以適應需求和技術的變化。爲了防止廠商按本身的意願篡改TPC-C標準進行測試以獲得更高的性能值，TPC組織要求全部的TPC測試結果都要通過TPC組織承認的審計員的審計，審計員對測試的過程和結果進行詳細的審覈，審計經過後，審計結果連同完整的測試報告提交給TPC組織的Technical Advisory Board（TAB），TAB審覈無異議後還將進行60天的公示，公示期間若有異議廠商須要證實本身的測試符合相應的TPC標準（必要時還須要再次運行benchmark測試程序）。

TPC-C是對商品銷售支付等實際業務系統很好的抽象。在準備TPC-C測試的過程當中，咱們發現了OceanBase許多性能不優的地方，在對這些地方進行了優化和完善後，咱們發現OceanBase已經達到了今年（2019年）雙11的性能優化目標：事實上，TPC-C五種事務中，佔比最高的兩種，訂單建立（new order，佔比45%）和訂單支付（payment，佔比43%），其實就對應了生產系統中的訂單建立和訂單支付。所以TPC-C模型看起來很簡單，偏偏是這個模型對實際的聯機交易處理作了很是好的抽象。

做爲一個普遍接受的標準，TPC-C很是嚴謹，極大地杜絕了做弊：

首先，做爲一個OLTP聯機交易處理系統的benchmark，TPC-C要求被測數據庫必須知足數據庫事務的ACID，即原子性、一致性、隔離性和持久性，其中隔離性爲可串行化隔離級別，持久性要求可以抵禦任何單點故障等。很顯然，這是對一個OLTP數據庫的基本要求。在分佈式環境下，TPC-C的兩種主要事務，訂單建立（new order）和訂單支付（payment），分別有10%和15%的分佈式事務（最多可能分佈在15個節點上），事務的ACID對於分佈式數據庫是很大的挑戰，尤爲是可串行化的隔離級別，這也是至今鮮少分佈式數據庫經過TPC-C測試的主要緣由之一。國內有些廠商混淆分佈式數據庫的概念，把多個單機數據庫堆在一塊兒而號稱分佈式數據庫，事實上，儘管每一個單機數據庫都知足ACID，但這些堆放在一塊兒的多個單機數據庫做爲一個總體並不知足ACID。

其次，TPC-C規定被測數據庫的性能（tpmC）與數據量成正比，事實上真實業務場景也是如此。TPC-C的基本數據單元是倉庫（warehouse），每一個倉庫的數據量一般在70MB左右（與具體實現相關），TPC-C要求終端用戶在選擇事務類型時，須要按照規定的比例選擇五種事務，終端用戶每一個事務都有必定的輸入時間（對每種事務分別固定）和必定範圍的隨機的思考時間（一個對數函數），根據這些要求，每一個倉庫所能得到的tpmC上限是12.86（假設數據庫的響應時間爲0）。假設某系統得到150萬tpmC，大約對應12萬個倉庫，按70MB/倉庫計算，數據量約8.4TB，而TPC-C同時要求系統具有60天、天天壓測8小時的存儲容量，所以系統的存儲容量可能要30TB或更多，而某些廠商用幾百或幾千個倉庫所有裝入內存，無視單個倉庫的最大tpmC上限，而後號稱得到百萬tpmC，不只不符合大多數真實業務場景，並且明顯違反了TPC-C規範，就像當年TPC組織成立以前一些公司的所做所爲同樣。

第三，TPC-C要求被測數據庫可以以平穩的性能長期地運行。測試時，去掉啓動預熱（ramp up）和結束降速（ramp down）時間後，被測數據庫至少要性能平穩地（steady state）運行8小時，其中性能採集時段（很多於2小時）內的性能累積波動不得超過2%。衆所周知，各類計算機系統在極限壓力下性能會產生較大的波動並可能被壓垮而崩潰，爲了不被壓垮，實際生產環境歷來不會讓系統處於極限壓力，TPC-C這個規定正是從實際生產需求出發的。此外，TPC-C要求被測數據庫長時間運行，一樣是實際生產系統的要求。某些數據庫廠商讓數據庫在很短期內衝擊性能的一個尖峯值，既沒有保證數據庫在較長時間內穩定運行，更談不上性能波動不超過2%，但卻聲稱本身的數據庫達到了這個尖峯性能。本次benchmark測試中，OceanBase作到了8小時性能波動低於0.5%。

第四，TPC-C要求被測數據庫的寫事務的結果必須在必定時間內數據落盤（指數據庫數據，不是日誌，事實上redo log在事務提交前就落盤了），對於具有checkpoint功能的數據庫，checkpoint的間隔不得超過30分鐘，checkpoint數據持久化的時間不得超過checkpoint間隔。咱們理解這是爲了保證數據庫系統在掉電等異常狀況下有較短的故障恢復時間。傳統數據庫的數據以數據塊(例如4KB/8KB的page/block)爲基本單位，作到這個是把髒頁刷盤。但OceanBase並不是如此，這是由於，第一OceanBase是多副本（本次測試是3副本）的跨機器部署，單機器異常的狀況下都可以當即恢復（RTO=30s）且數據無損（RPO=0），並不依賴於寫事務的數據落盤；第二個緣由：OceanBase是「基線數據在硬盤+修改增量數據在內存」的結構，設計上是修改增量數據一天落盤一次（即每日合併，可根據業務量的增長而自動增長每日合併次數），實際生產系統不須要也不依賴數據在較短期（好比30分鐘）內落盤。在TPC-C benchmark測試中，OceanBase設置了checkpointing，保證全部checkpoint的間隔小於30分鐘，並使得checkpoint數據持久化的時間小於checkpoint間隔，以符合TPC-C規範。

第五，業務定向優化（profile-directed optimization，PDO）能夠提高軟件的性能，TPC-C也容許使用PDO，但有一些限制，好比採用PDO優化的版本須要在客戶使用，數據庫廠家須要對PDO優化的版本提供技術支持等。爲了不可能出現的異議，OceanBase沒有使用PDO。

最後，TPC-C規範雖然十分嚴格，但依然鼓勵新技術和新方法的使用，好比本次OceanBase的TPC-C benchmark測試，就沒有像以前的TPC-C benchmark同樣購買物理服務器和存儲，而是租用了阿里雲公有云的ECS虛擬機，這不只使得擴容/縮容垂手可得，還可按需租賃而極大下降實際測試成本。