自從螞蟻金服自研數據庫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/information/about/history.asp ）：
定義了被測系統的功能要求而不是軟件硬件本身
規定了被測系統的擴展準則，即性能與數據量相匹配
規定被測系統的事務需要在指定時間內完成（比如95%事務在1s內完成）
把被測系統的整體成本納入性能benchmark
DebitCredit爲數據庫的聯機交易處理系統性能建立了統一的、科學的衡量標準，後續相關的benchmark基本都以此爲基礎發展而來。然而一些廠商卻刪掉DebitCredit標準中的一些關鍵要求後進行測試以便獲得更好的性能值（這種做法現在也被一些國內數據庫廠商用在TPC-C benchmark測試上），這導致數據庫的聯機交易處理系統性能的衡量標準並沒有真正統一：如果說Jim Gray等人爲數據庫的聯機交易處理系統benchmark制定的一個法律（DebitCredit），但卻沒有執法隊伍來保障法律的執行。1988年TPC組織的創始人Omri Serlin（ http://www.tpc.org/information/who/serlin.asp ）成功地說服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虛擬機，這不僅使得擴容/縮容輕而易舉，還可按需租賃而極大降低實際測試成本。