螞蟻金服OceanBase挑戰TPCC | 測試流程解析

螞蟻金服自研數據庫 OceanBase 登頂 TPC-C 引發業內普遍關注，爲了更清楚的展現其中的技術細節，咱們特地邀請 OceanBase 核心研發人員對本次測試進行技術解讀，共包括五篇：

1）TPC-C基準測試介紹
2）OceanBase如何作TPC-C測試
3）TPC-C基準測試之SQL優化
4）TPC-C基準測試之數據庫事務引擎的挑戰
5）TPC-C基準測試之存儲優化

本文爲第二篇，其它文章已同步發佈，詳情請在「螞蟻金服科技」公衆號查看。

---

衆所周知，TPC 組織是當今國際數據庫領域公認最權威的測試和評價組織，它成立的初衷就是構建最好的測試標準以及制定針對這些標準最優的審計和監測流程。數據庫界的天皇巨星 Jim Gray 曾在 1985 年提出了針對事務處理能力的評價標準 DebitCredit，而 1988 年 TPC 組織成立伊始，就基於這個標準提出了 TPC 組織第一個針對 OLTP 應用的測試標準 TPC-A。但隨着時代發展，TPC-A 已經慢慢沒法徹底體現真實應用場景，此時 TPC-C 肩負重任應運而生，接下來也一直是 TPC 組織最核心同時也是關係數據庫領域最頂級的測試標準。TPC-C 標準比 TPC-A 更加複雜，壓力負載模型是 16 位一線工業產業界學者一塊兒參與制定，隨着時間推移測試標準也一直在保持修訂，因此其模擬大型在線商超的測試模型時至今日也仍不過期，愈來愈能找到和當前大型 B2C 電商網站的共通之處。

有機會挑戰 TPC-C 測試相信是全部數據庫內核開發人員的夢想，但 TPC-C 測試標準很是複雜，1992 年 7 月發佈以來到如今已是 v5.11.0 版本，僅 PDF 就 132 頁，若是不是鐵桿粉絲估計不多有人會認真通讀完這個標準。此次 OceanBase 創造 TPC-C 記錄引發了你們的普遍關注，但它也只是這個測試標準裏體現跑分的一個評價項 MQTh(最大有效吞吐量)，隱藏在跑分下面的是 TPC-C 標準對被測數據庫無數細緻入微的測試驗證和評價項，而正是這些才讓這個標準在關係數據庫領域如此權威，同時也是國產數據庫以前很難入場的一大緣由。

因爲這是國產數據庫同時也是分佈式數據庫第一次衝擊這個榜單，爲了完成此次挑戰，OceanBase 團隊先後準備時間超過一年，僅審計認證過程就耗時約半年，除了數據庫自身性能優化同時還有大量的穩定性、合規要求相關工做，6088w tpmC 其實也只是整個測試結果中一小個展現項而已。

前期準備

做爲基於 LSM-Tree、多副本 paxos 強一致的新型分佈式關係數據庫，如何進行 TPC-C 測試，有哪些注意事項，何時該作什麼步驟等等諸多問題，在審計剛啓動時咱們無處諮詢也沒有任何可借鑑的資料。TPC-C 測試首先須要找到官方惟一認證的審計員來對測試進行審計監察，但面對 OceanBase 這樣一個全新架構的關係數據庫時，他們其實也有着諸多和咱們相似的疑惑和問題，所以他們對此次 OceanBase 的審計也至關重視，全世界僅有的三個審計員此次就有兩個參與到測試審計工做中。

兩位審計員其中一位仍是 TPC-C 標準原做者之一,他們對整個測試流程的要求異常細緻和嚴苛，起初對待 OceanBase 還持有很大的懷疑態度，和審計員們漫長的郵件以及現場溝經過程也異常艱辛，但這也幫助咱們始終堅持用規範中最嚴格的標準來針對每一個測試子項，最終也贏得了審計員們充分的信任，審計員甚至在理解了 OceanBase 架構後幫助咱們提出了多個問題解決思路。另外經過此次測試，OceanBase 也給 TPC-C 標準帶來了不少新鮮的概念和測試方案。

• 如何在OceanBase特有的Incremental數據帶上後續的Major Compaction機制下去作數據存儲的審計；
• 如何在所有使用雲服務器的測試系統中進行Durability測試；
• 分佈式數據庫在性能壓測等測試中應當如何去評估和監控checkpoint；

測試系統

目前市面上基本找不到一個可以開箱即用的符合 TPC-C 標準的測試工具。以目前各個廠商 PoC 環境最常遇到的 benchmarksql 爲例，能夠說只是模擬 TPC-C 壓力模型的壓測工具，連最基本的數據導入都不合規，大量的字符串生成未保證全局隨機，缺少壓測階段最基本的 think time、keying time 這些基本配置致使極小的數據量就能跑出很高的 tpmC，最關鍵的是它將測試模型大大簡化爲工具直連 DB 測試，徹底沒有遵照 TPC-C 測試標準規範。

在標準定義中，測試系統能夠分爲 RTE（Remote Terminal Emulator）和 SUT 兩部分，但實際上從角色上看 SUT 能夠進一步拆分爲兩部分：WAS(web application server)和 DB Server。這其中 DB Server 是每一個測試廠商的數據庫服務；RTE 扮演的角色是測試模型中的客戶終端，事務的觸發、RT 的統計等都在這裏完成；標準明確要求每個用戶 terminal 都必須保持一個長鏈接，顯然在海量 Warehouse 時 DB 是沒法承受這麼多鏈接的，WAS 就是 RTE 和 DB 之間橋樑，標準定義可使用鏈接池，在保證對應用透明的狀況下它能夠作全部請求的管理。

這三個角色中，WAS 和 DB 是必須商業化可購買且提供支付服務的，OceanBase 此次是使用了 OpenResty 做爲 WAS 供應商。而 RTE 則通常由各個參測廠商自行根據標準實現，但全部實現代碼必須通過審計的嚴格審計，OceanBase 此次完整的實現了一整套徹底合規的 RTE，而且支持在大規模測試系統中部署。要知道在實際的 TPC-C 測試流程中，不僅是對 DB 端能力的考驗，RTE 端一樣存在極大的資源消耗和壓力。以此次 6088w tpmC 測試結果看，咱們一共在 64 臺 64c128G 的雲服務器上運行了 960 個 RTE 客戶端，來模擬總計 47942400 個用戶 terminal，最後還須要基於這麼多 RTE 統計結果進行一致性和持久化審計驗證。

雖然只是測試客戶端，但 RTE 的中一樣有大量的可能致使最後測試失敗的小細節，好比你們可能注意不到的全部事務都由於用了 web 端模擬終端後須要增長的 100 毫秒 rt，又好比爲了模擬用戶終端輸出顯示的 100 毫秒延時。

測試規劃

TPC-C 歷來都不是一個簡單的測試，它很科學並無給出強制的軟硬件配置，只是給出測試規範和各類審計檢查限制標準，全部數據庫廠商能夠根據本身的特性充分調優來拿到一個最好的性能或性價比。但這同時也對全部參測廠商提出了一個巨大的難題，如何對已有的資源進行合理規劃來保證順利完成一次對 TPC-C 榜單的衝擊。

1. 硬件選型，這裏不只要對數據庫服務器選型，還須要對 RTE 以及 WAS 服務器選型。這以前須要先期進行大量的測試和調優，來摸出在保證性價比的前提下每一個角色服務器的資源配置是多少恰好。此次 OceanBase 測試最大的優點就是所有使用了雲化資源，咱們不須要再關注最底層機房、機櫃、佈線這些細節，只須要經過快速的規格調整來拿到咱們須要的機型。
2. 參數選擇，如何選擇合適的配置參數是一個很是使人頭疼的問題。舉個例子，一個最典型的問題就是咱們最終要跑多少個 Warehouse，每一個數據庫服務器上承載多少 Warehouse。TPC-C 標準爲了儘量模擬真實業務場景，經過每一個事務限定不一樣的 think time 和 keying time 保證了一個 warehouse 的數據最多可以提供 12.86tpmC 值，所以數據庫廠商想要拿到更高的成績就必須裝載更多的 warehouse，可是另外一方面單機的存儲空間又有預計 80%（經驗值）須要預留給 60 天增量存儲。在分佈式數據庫架構下，爲了能讓每一個數據庫服務器跑滿又能充分利用本地存儲空間，讓每一個服務器的 CPU、內存、IO 能力、存儲空間的資源最大化利用，咱們先後調整優化了近一個月時間。

性能壓測

最受關注的性能壓測部分在 TPC-C 標準中規定了如下三個狀態：

1. Ramp-up，標準容許每一個數據庫進行必定時間的預熱來達到穩定狀態，可是 ramp-up 階段的全部配置必須和最終報告配置保持一致。
2. Steady state，保證 ACID 及可串行化隔離級別前提下，數據庫須要可以以最終報告 tpmC 值在穩定狀態無任何人工干預前提下保持運行 8 小時以上，每隔半小時須要完成一次 checkpoint。
3. Measurement Interval，標準規定了須要可以支持 8 小時穩定運行，但性能採集階段只須要保設置 2 小時以上便可。這個階段還須要保證累計 tpmC 波動不能超過 2%，而且必須完成至少 4 個以上的 checkpoint。

因此以前通常數據庫進行性能壓測通常是如下的流程，先進行一段時間的預熱到達穩態，等待穩定運行一段時間並完成一個 checkpoint 後開始進入 2 小時的性能採集階段。

而 OceanBase 此次是使用了 TPC-C 測試迄今以來最嚴苛的一個流程來完成這個性能測試的，咱們首先使用了 10 分鐘進行預熱，而後在 6088w tpmC 穩態保持運行 25 分鐘並完成一個檢查點，再繼續跑了完整的 8 小時性能壓測採集階段，總耗時超過 8 個半小時，中間性能最大波動不到 0.5%，最終結果也讓審計員異常興奮。

整個性能測試先後，審計員還須要進行數據及事務隨機分佈檢查，簡單說來就是大量全表掃描和統計 sql，最大的一條 sql 須要訪問超過萬億行的 order_line 表結果，能夠算是 TPC-C 裏的「TPC-H 測試」。現場審計第一次遇到這些 sql 時咱們也大量的出現 sql 執行超時狀況，但後續基於 OceanBase2.2 版本最新的並行執行框架咱們仍是很快搞定了這些大 sql，因此要順利完成 TPC-C 測試並不能只是一個偏科生，保持自身沒有短板纔是真正意義上的通用關係數據庫，從這點上說 Oracle 還是 OceanBase 學習的榜樣。

ACID

1. A 測試，經過提交和回滾 payment 事務來確認數據庫對原子性支持，和 I 測試同樣，OceanBase 的 A 測試跑了兩遍，分別應對分佈式事務和本地事務。
2. C 測試，標準裏的 C 測試一共包含 12 個 case，前四個是必需要完成驗證的，每一個 case 其實均可以認爲是一個複雜的大 sql，而對於分佈式數據庫來講重點是須要始終保證全局一致。
3. I 測試，標準要求 TPC-C 模型裏 5 個事務除了 StockLevel 事務都須要知足最高的可串行化隔離級別，並構造了 9 個 case 來驗證隔離性。對於分佈式數據庫而言，這個要求並無那麼容易實現，所幸 OceanBase 在 2.x 版本中提供了全局時間戳的支持，因此的 I 測試都在審計員的特別要求下跑完了全本地和全分佈式兩種模式的兩輪測試，這也應該是 TPC-C 測試中首次有數據庫廠商須要作兩輪 I 測試跑 18 個 case 的，也許在不久後 TPC-C 標準定義也會由於 OceanBase 的此次測試而帶來針對分佈式數據庫的相關更新。
4. D 測試，OceanBase 在這個場景其實相對傳統數據庫是有較大天生優點的，OceanBase 每一個 Warehouse 數據有兩份數據三份日誌，經過 paxos 強同步，保證 RPO=0 的前提下只有秒級 RTO。面對 D 測試標準中最嚴格的一項-部分存儲介質永久故障，OceanBase 還使用了最嚴苛的測試場景，在使用超出標準要求的全量 6000W tpmC 壓力下，咱們強行銷燬了一個雲服務器節點，總體 tpmC 在兩分鐘內恢復到 6000w 並持續跑到測試時間結束，這些表現都是遠遠超過 TPC-C 規範要求的，相比較而言其它傳統數據庫基本面對有日誌的存儲介質故障 D 測試場景都是依賴磁盤 RAID 來恢復，OceanBase 應該算是首個沒有 raid 徹底依賴數據庫自身恢復機制完成所有 D 測試的數據庫廠商了。同時咱們在 D 測試中是連續殺掉了兩臺服務器節點，首先殺掉一個數據節點，等待 tpmC 恢復且穩定 5 分鐘後，再次殺掉了 rootserver leader 節點，tpmC 仍然快速恢復。

做者介紹

曹暉，現任螞蟻金服 OceanBase 團隊技術專家，2017 年加入 OceanBase 團隊，現從事存儲引擎開發工做。