數(shù)據(jù)庫OceanBase創(chuàng)始人陽振坤：通關TPC-C到底有多

自從螞蟻金服自研數(shù)據(jù)庫OceanBase獲得TPC-C測試第一名后，引起了行業(yè)內外大量關注，我們衷心的感謝大家對OceanBase的支持與厚愛，也虛心聽取外界的意見和建議。為了讓大家更好的了解測試的技術細節(jié)，我們特意邀請了OceanBase的核心研發(fā)人員對本次測試做專業(yè)的技術解讀，本文為第一篇，后續(xù)文章也將于近日對外發(fā)布。

OceanBase于2010年立項，九年來，研發(fā)人員一步一個腳印，不斷的對OceanBase做出改進以及增加新的功能。OceanBase也從服務于支付寶開始，逐漸對外開放，為廣大的各行業(yè)客戶提供服務。在這個過程中，我們希望外界對OceanBase的實力有更直觀的了解，讓客戶對我們的產品更有信心，TPC-C測試為我們提供了一個絕佳的舞臺。

通過本次測試，我們發(fā)現(xiàn)了OceanBase的一些不足之處，比如，之前的單機數(shù)據(jù)庫只能通過增加CPU、內存等來提高處理能力，OceanBase通過分布式架構，可以讓大量的普通硬件設備像一臺電腦一樣處理數(shù)據(jù)，想提高性能只需增加設備即可，但是，OceanBase在每臺設備上的性能還有不少提升空間；另外，OceanBase支持的功能、易用性、數(shù)據(jù)庫生態(tài)相比業(yè)界標桿還有一些差距。

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

后續(xù)，我們還將開源本次TPC-C測試工具，希望與業(yè)界同行多多交流，共同探討數(shù)據(jù)庫技術的發(fā)展與未來。

正文

網(wǎng)絡上有很多介紹TPC-C benchmark的文章，而且某些數(shù)據(jù)庫廠商還聲稱自己進行了TPC-C測試，還獲得了單機百萬級tpmC、分布式千萬級tpmC等等。真實情況究竟是怎樣呢？

就像很多人知道的，國際事務性能委員會（TPC）組織是數(shù)十家會員公司創(chuàng)建的非盈利組織，TPC-C是TPC組織制定的關于商品銷售的訂單創(chuàng)建和訂單支付等的基準測試標準，是數(shù)據(jù)庫聯(lián)機交易處理系統(tǒng)（OLTP）的權威基準測試標準。TPC-C有5種事務，每種事務有規(guī)定的比例，分別訂單支付不低于43%，訂單查詢、訂單發(fā)貨和庫存查詢各不低于4%，其余則為訂單創(chuàng)建(不高于45%)，tpmC值是訂單創(chuàng)建事務每分鐘執(zhí)行的數(shù)量。

TPC-C benchmark測試必須通過TPC組織的審計（準確地講是TPC-C組織認可的審計員的審計），通過審計的TPC-C的結果，其完整詳實的測試報告（包括測試廠家、數(shù)據(jù)庫版本、詳細的軟硬件配置、測試過程等）將公布在TPC組織的網(wǎng)站（?www.tpc.org?）上。沒有通過TPC的審計而擅自聲稱自己通過了TPC-C測試、獲得XXX tpmC，不僅是侵權，也是不合法的。除了OceanBase，目前在TPC網(wǎng)站上還沒有看到任何一個國產數(shù)據(jù)庫的TPC-C benchmark的測試報告，無論是完全自主研發(fā)的，還是在開源基礎上修改的。

為什么TPC-C benchmark測試必須要通過TPC組織的審計呢？這還得從TPC組織的誕生說起。1980年代數(shù)據(jù)庫聯(lián)機交易處理系統(tǒng)即OLTP（Online Transactional Processing）出現(xiàn)后，極大地推動了諸如自動提款機（Automated teller transaction，ATM）等聯(lián)機交易處理系統(tǒng)的發(fā)展。每個數(shù)據(jù)庫廠商都試圖向客戶證明自己的系統(tǒng)性能最好、處理能力最強，但由于沒有統(tǒng)一的性能測試標準，更沒有誰來監(jiān)督性能測試的執(zhí)行和結果發(fā)布，一方面客戶無法在不同系統(tǒng)之間進行比較，另一方面數(shù)據(jù)庫廠商各自的性能測試數(shù)據(jù)也沒有足夠的說服力。

1985年初，Jim Gray聯(lián)合24位來自學術界和工業(yè)界的同仁發(fā)表了名為“A Measure of Transaction Processing Power”的文章，提出了一種在線事務處理能力的測試方法DebitCredit。DebitCredit定義了數(shù)據(jù)庫性能benchmark的一些關鍵特征（?http://www.tpc.org/information/about/history.asp?）：

• 定義了被測系統(tǒng)的功能要求而不是軟件硬件本身

• 規(guī)定了被測系統(tǒng)的擴展準則，即性能與數(shù)據(jù)量相匹配

• 規(guī)定被測系統(tǒng)的事務需要在指定時間內完成（比如95%事務在1s內完成）

• 把被測系統(tǒng)的整體成本納入性能benchmark

DebitCredit為數(shù)據(jù)庫的聯(lián)機交易處理系統(tǒng)性能建立了統(tǒng)一的、科學的衡量標準，后續(xù)相關的benchmark基本都以此為基礎發(fā)展而來。然而一些廠商卻刪掉DebitCredit標準中的一些關鍵要求后進行測試以便獲得更好的性能值（這種做法現(xiàn)在也被一些國內數(shù)據(jù)庫廠商用在TPC-C benchmark測試上），這導致數(shù)據(jù)庫的聯(lián)機交易處理系統(tǒng)性能的衡量標準并沒有真正統(tǒng)一：如果說Jim Gray等人為數(shù)據(jù)庫的聯(lián)機交易處理系統(tǒng)benchmark制定的一個法律（DebitCredit），但卻沒有執(zhí)法隊伍來保障法律的執(zhí)行。1988年TPC組織的創(chuàng)始人Omri Serlin（?http://www.tpc.org/information/who/serlin.asp?）成功地說服8家公司成立了非盈利的TPC組織，統(tǒng)一制定和發(fā)布benchmark標準并監(jiān)督和審計數(shù)據(jù)庫benchmark測試，情況才發(fā)生了根本的改變。

經(jīng)過三十多年的發(fā)展，TPC組織的成員超過了20個，誕生和完善了數(shù)據(jù)庫性能的多個benchmark標準，并被全世界接受。比如TPC-C的第一個版本是在1992年發(fā)布的，之后經(jīng)歷了多次修訂，以適應需求和技術的變化。為了防止廠商按自己的意愿篡改TPC-C標準進行測試以得到更高的性能值，TPC組織要求所有的TPC測試結果都要經(jīng)過TPC組織認可的審計員的審計，審計員對測試的過程和結果進行詳細的審核，審計通過后，審計結果連同完整的測試報告提交給TPC組織的Technical Advisory Board（TAB），TAB審核無異議后還將進行60天的公示，公示期間如有異議廠商需要證明自己的測試符合相應的TPC標準（必要時還需要再次運行benchmark測試程序）。

TPC-C是對商品銷售支付等實際業(yè)務系統(tǒng)很好的抽象。在準備TPC-C測試的過程中，我們發(fā)現(xiàn)了OceanBase許多性能不優(yōu)的地方，在對這些地方進行了優(yōu)化和完善后，我們發(fā)現(xiàn)OceanBase已經(jīng)達到了今年（2019年）雙11的性能優(yōu)化目標：事實上，TPC-C五種事務中，占比最高的兩種，訂單創(chuàng)建（new order，占比45%）和訂單支付（payment，占比43%），其實就對應了生產系統(tǒng)中的訂單創(chuàng)建和訂單支付。因此TPC-C模型看起來很簡單，恰恰是這個模型對實際的聯(lián)機交易處理做了非常好的抽象。

作為一個廣泛接受的標準，TPC-C非常嚴謹，極大地杜絕了作弊：

首先，作為一個OLTP聯(lián)機交易處理系統(tǒng)的benchmark，TPC-C要求被測數(shù)據(jù)庫必須滿足數(shù)據(jù)庫事務的ACID，即原子性、一致性、隔離性和持久性，其中隔離性為可串行化隔離級別，持久性要求能夠抵御任何單點故障等。很顯然，這是對一個OLTP數(shù)據(jù)庫的基本要求。在分布式環(huán)境下，TPC-C的兩種主要事務，訂單創(chuàng)建（new order）和訂單支付（payment），分別有10%和15%的分布式事務（最多可能分布在15個節(jié)點上），事務的ACID對于分布式數(shù)據(jù)庫是很大的挑戰(zhàn)，尤其是可串行化的隔離級別，這也是至今鮮少分布式數(shù)據(jù)庫通過TPC-C測試的主要原因之一。國內有些廠商混淆分布式數(shù)據(jù)庫的概念，把多個單機數(shù)據(jù)庫堆在一起而號稱分布式數(shù)據(jù)庫，事實上，盡管每個單機數(shù)據(jù)庫都滿足ACID，但這些堆放在一起的多個單機數(shù)據(jù)庫作為一個整體并不滿足ACID。

其次，TPC-C規(guī)定被測數(shù)據(jù)庫的性能（tpmC）與數(shù)據(jù)量成正比，事實上真實業(yè)務場景也是如此。TPC-C的基本數(shù)據(jù)單元是倉庫（warehouse），每個倉庫的數(shù)據(jù)量通常在70MB左右（與具體實現(xiàn)相關），TPC-C要求終端用戶在選擇事務類型時，需要按照規(guī)定的比例選擇五種事務，終端用戶每個事務都有一定的輸入時間（對每種事務分別固定）和一定范圍的隨機的思考時間（一個對數(shù)函數(shù)），根據(jù)這些要求，每個倉庫所能獲得的tpmC上限是12.86（假設數(shù)據(jù)庫的響應時間為0）。假設某系統(tǒng)獲得150萬tpmC，大約對應12萬個倉庫，按70MB/倉庫計算，數(shù)據(jù)量約8.4TB，而TPC-C同時要求系統(tǒng)具備60天、每天壓測8小時的存儲容量，因此系統(tǒng)的存儲容量可能要30TB或更多，而某些廠商用幾百或幾千個倉庫全部裝入內存，無視單個倉庫的最大tpmC上限，然后號稱獲得百萬tpmC，不僅不符合大多數(shù)真實業(yè)務場景，而且明顯違反了TPC-C規(guī)范，就像當年TPC組織成立之前一些公司的所作所為一樣。

第三，TPC-C要求被測數(shù)據(jù)庫能夠以平穩(wěn)的性能長期地運行。測試時，去掉啟動預熱（ramp up）和結束降速（ramp down）時間后，被測數(shù)據(jù)庫至少要性能平穩(wěn)地（steady state）運行8小時，其中性能采集時段（不少于2小時）內的性能累積波動不得超過2%。眾所周知，各種計算機系統(tǒng)在極限壓力下性能會產生較大的波動并可能被壓垮而崩潰，為了避免被壓垮，實際生產環(huán)境從來不會讓系統(tǒng)處于極限壓力，TPC-C這個規(guī)定正是從實際生產需求出發(fā)的。此外，TPC-C要求被測數(shù)據(jù)庫長時間運行，同樣是實際生產系統(tǒng)的要求。某些數(shù)據(jù)庫廠商讓數(shù)據(jù)庫在很短時間內沖擊性能的一個尖峰值，既沒有保證數(shù)據(jù)庫在較長時間內穩(wěn)定運行，更談不上性能波動不超過2%，但卻聲稱自己的數(shù)據(jù)庫達到了這個尖峰性能。本次benchmark測試中，OceanBase做到了8小時性能波動低于0.5%。

第四，TPC-C要求被測數(shù)據(jù)庫的寫事務的結果必須在一定時間內數(shù)據(jù)落盤（指數(shù)據(jù)庫數(shù)據(jù)，不是日志，事實上redo log在事務提交前就落盤了），對于具備checkpoint功能的數(shù)據(jù)庫，checkpoint的間隔不得超過30分鐘，checkpoint數(shù)據(jù)持久化的時間不得超過checkpoint間隔。我們理解這是為了保證數(shù)據(jù)庫系統(tǒng)在掉電等異常情況下有較短的故障恢復時間。傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)以數(shù)據(jù)塊(例如4KB/8KB的page/block)為基本單位，做到這個是把臟頁刷盤。但OceanBase并非如此，這是因為，第一OceanBase是多副本（本次測試是3副本）的跨機器部署，單機器異常的情況下都能夠立即恢復（RTO=30s）且數(shù)據(jù)無損（RPO=0），并不依賴于寫事務的數(shù)據(jù)落盤；第二個原因：OceanBase是“基線數(shù)據(jù)在硬盤+修改增量數(shù)據(jù)在內存”的結構，設計上是修改增量數(shù)據(jù)一天落盤一次（即每日合并，可根據(jù)業(yè)務量的增加而自動增加每日合并次數(shù)），實際生產系統(tǒng)不需要也不依賴數(shù)據(jù)在較短時間（比如30分鐘）內落盤。在TPC-C benchmark測試中，OceanBase設置了checkpointing，保證所有checkpoint的間隔小于30分鐘，并使得checkpoint數(shù)據(jù)持久化的時間小于checkpoint間隔，以符合TPC-C規(guī)范。

第五，業(yè)務定向優(yōu)化（profile-directed optimization，PDO）可以提升軟件的性能，TPC-C也允許使用PDO，但有一些限制，比如采用PDO優(yōu)化的版本需要在客戶使用，數(shù)據(jù)庫廠家需要對PDO優(yōu)化的版本提供技術支持等。為了避免可能出現(xiàn)的異議，OceanBase沒有使用PDO。

最后，TPC-C規(guī)范雖然十分嚴格，但依然鼓勵新技術和新方法的使用，比如本次OceanBase的TPC-C benchmark測試，就沒有像之前的TPC-C benchmark一樣購買物理服務器和存儲，而是租用了阿里云公有云的ECS虛擬機，這不僅使得擴容/縮容輕而易舉，還可按需租賃而極大降低實際測試成本。