阿里妹導讀：TPC-C是TPC組織（國際事務性能委員會）制定的關於商品銷售的訂單創建和訂單支付等的基準測試標準，是數據庫聯機交易處理系統的權威基準測試標準。
螞蟻金服自研的分佈式關係數據庫OceanBase獲得TPC-C測試第一名後，引起了大量關注，今天，我們邀請了OceanBase的核心研發人員對本次測試做專業的技術解讀。
一、OceanBase如何做TPC-C測試
有機會挑戰TPC-C測試相信是所有數據庫內核開發人員的夢想，但TPC-C測試標準非常複雜。由於這是國產數據庫同時也是分佈式數據庫第一次衝擊這個榜單，爲了完成這次挑戰，OceanBase團隊前後準備時間超過一年。
前期準備
TPC-C測試首先需要找到官方唯一認證的審計員來對測試進行審計監察，他們對這次OceanBase的審計也相當重視，全世界僅有的三個審計員這次就有兩個參與到測試審計工作中。
測試系統
目前市面上基本找不到一個能夠開箱即用的符合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榜單的衝擊。
- 硬件選型，這裏不僅要對數據庫服務器選型，還需要對RTE以及WAS服務器選型。這之前需要先期進行大量的測試和調優，來摸出在保證性價比的前提下每個角色服務器的資源配置是多少剛好。這次OceanBase測試最大的優勢就是全部使用了雲化資源，我們不需要再關注最底層機房、機櫃、佈線這些細節，只需要通過快速的規格調整來拿到我們需要的機型。
- 參數選擇，如何選擇合適的配置參數是一個非常令人頭疼的問題。舉個例子，一個最典型的問題就是我們最終要跑多少個Warehouse，每個數據庫服務器上承載多少Warehouse。TPC-C標準爲了儘可能模擬真實業務場景，通過每個事務限定不同的think time和keying time保證了一個warehouse的數據最多能夠提供12.86tpmC值，因此數據庫廠商想要拿到更高的成績就必須裝載更多的warehouse，但是另一方面單機的存儲空間又有預計80%（經驗值）需要預留給60天增量存儲。在分佈式數據庫架構下，爲了能讓每個數據庫服務器跑滿又能充分利用本地存儲空間，讓每個服務器的CPU、內存、IO能力、存儲空間的資源最大化利用，我們前後調整優化了近一個月時間。
性能壓測
最受關注的性能壓測部分在TPC-C標準中規定了以下三個狀態：
- Ramp-up，標準允許每個數據庫進行一定時間的預熱來達到穩定狀態，但是ramp-up階段的所有配置必須和最終報告配置保持一致。
- Steady state，保證ACID及可串行化隔離級別前提下，數據庫需要能夠以最終報告tpmC值在穩定狀態無任何人工干預前提下保持運行8小時以上，每隔半小時需要完成一次checkpoint。
- 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
- A測試，通過提交和回滾payment事務來確認數據庫對原子性支持，和I測試一樣，OceanBase的A測試跑了兩遍，分別應對分佈式事務和本地事務。
- C測試，標準裏的C測試一共包含12個case，前四個是必須要完成驗證的，每個case其實都可以認爲是一個複雜的大sql，而對於分佈式數據庫來說重點是需要始終保證全局一致。
- I測試，標準要求TPC-C模型裏5個事務除了StockLevel事務都需要滿足最高的可串行化隔離級別，並構造了9個case來驗證隔離性。對於分佈式數據庫而言，這個要求並沒有那麼容易實現，所幸OceanBase在2.x版本中提供了全局時間戳的支持，所以的I測試都在審計員的特別要求下跑完了全本地和全分佈式兩種模式的兩輪測試，這也應該是TPC-C測試中首次有數據庫廠商需要做兩輪I測試跑18個case的，也許在不久後TPC-C標準定義也會因爲OceanBase的這次測試而帶來針對分佈式數據庫的相關更新。
- 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仍然快速恢復。
二、TPC-C基準測試之SQL優化
對TPC-C有所瞭解人都知道，TPC-C是一個典型的OLTP (On-Line Transaction Processing) 場景測試，考察的是數據庫在高併發壓力場景下的事務處理能力，最終的性能指標以tpmC(transaction per minute，也即每分鐘系統處理TPC-C模型中的new order事務的數量)和平均到每tpmC的系統成本作爲衡量標準。在OLTP場景中，每條請求的響應時間都是極短的。因此，各個數據庫廠商在進行TPC-C測試時，都會盡一切可能將每一個操作時間壓縮到最短，不誇張的說，在TPC-C的測試中，一些關鍵操作的優化往往需要細化到CPU指令級。
在進入我們的主題前，我們先來談談TPC-C中的事務模型，主要分爲五種事務，訂單創建、訂單支付、訂單查詢、訂單發貨以及庫存查詢，這五種事務按照一定的比例發生，測試最終衡量的是每分鐘訂單創建事務的執行個數。大家知道，每一個數據庫的事務，其實就是由一定邏輯關係關聯的若干條SQL語句組成，他們在一個事務中，要麼全部成功，要麼全部失敗，這個在數據庫中稱爲“原子性”，也就是ACID中的“A”。那麼TPC-C中的一個事務的耗時大約是多久呢？看一下報告就很清楚了——只有十幾個毫秒。考慮到一個事務由多條SQL構成，那麼每一條SQL的平均耗時都不到1毫秒！
在C/S（client-server）模型中，一條SQL語句從發起到執行完成需要經歷從客戶端輸入、網絡傳輸、SQL優化、執行、結果返回到客戶端這樣一個流程。而具體每一條SQL的執行可能只是做一個字段的更新，所需要的執行時間是非常短暫的，從整個鏈路的角度來看，大量的時間會花費在與客戶端的交互過程中，造成資源的浪費和耗時的增加。那麼如何解決這個問題的呢？答案就是使用存儲過程。
存儲過程
所謂“存儲過程”就是數據庫爲用戶提供的一種面向過程的編程語言。基於這種語言，用戶可以將應用程序的邏輯封裝爲一個可調用的過程（procedure）存放在數據庫中並隨時進行調用。通過這種方式，用戶可以將本來需要與數據庫進行多次交互才能完成的工作通過一次交互完成，省去了中間網絡的傳輸和等待時間（參見圖1）。假如一條事務的網絡開銷平均是30%，也就是說30%的CPU都花在了網絡的收發和解析上。那麼在6千萬規模tpmC測試中節省下來30%的CPU資源換算成系統處理能力是驚人的。使用存儲過程還可以帶來事務響應時間的下降，導致數據庫內核中事務鎖的臨界區縮短，間接的提升了系統CPU利用率，整個吞吐量也隨之提高。存儲過程在縮短應用端的等待耗時上同樣有很大作用。
在TPC-C中，存儲過程對於整個系統的執行效率提升是至關重要的。OceanBase 的2.2版本不僅全面支持了存儲過程，而且對存儲過程的執行效率做了大量極致的優化。
編譯執行
存儲過程作爲一種面向過程的高級語言，需要轉換成機器碼才能夠執行。這個過程一般可以分爲“編譯執行”和“解釋執行”兩種，一般來說，編譯執行相比解釋執行有代碼優化充分、執行效率高等特點。OceanBase利用近兩年逐漸成熟的LLVM編譯器框架實現了一個支持存儲過程的編譯器，通過動態編譯（Just-in-Time Compilation）的方式將存儲過程翻譯成高效的二進制可執行代碼，在執行效率上獲得了數量級的提升。同時，過程中LLVM框架將存儲過程轉換爲與機器無關的中間代碼，使得存儲過程也自然而然地獲得了跨平臺的編譯執行能力，LLVM內置的優化過程確保我們在各種不同的硬件平臺上都可以獲得正確、高效的可執行代碼。
Array Binding
另外一個在TPC-C測試中發揮了重要作用的功能就是對DML語句進行批量處理的能力，在Oracle中該功能也稱爲“Array Binding”。一條SQL在數據庫中的執行過程大致上可以分爲“計劃生成”和“執行”兩個階段。儘管我們對SQL的執行計劃做了高速緩存，但找到一個合適的執行計劃在整個執行過程中仍然是比較耗時的一個部分。那有沒有辦法省去這個時間呢？當一組SQL的執行計劃完全一樣而只有執行參數不同時，在存儲過程中我們可以通過特定的語法將他們的執行做成一個批量處理的過程，此時“計劃生成”只需要做一次即可，這就是所謂的“Array Binding”。
在Array Binding中，數據庫會首先找到需要使用的計劃，然後執行該計劃，並在每次執行完畢後，重新執行參數綁定（binding）的過程。打個比方，這就像是在一個C語言的for循環中，反覆賦值而不是重新定義一個數據結構。Array Binding的使用受用戶控制，需要在存儲過程中使用FORALL關鍵字來觸發這一功能，在TPC-C的測試過程中，我們多次使用了Array Binding來提升系統的處理能力，效果非常明顯。
Prepared Statement與執行計劃緩存
Prepared Statement是一種二進制的請求交互協議，可以大大降低系統的交互成本。OceanBase不僅支持用戶程序與數據庫間使用Prepared Statement, 也支持在存儲過程引擎調用SQL引擎執行時使用這種交互方式。存儲過程在對SQL進行一次Prepare操作並獲取唯一id後, 後續的每次執行僅需要傳入該id和對應的參數,系統可以通過高速緩存找到對應的存儲過程或SQL計劃開始執行。該過程相比使用SQL文本的交互方式，省去了大量請求文本解析的CPU開銷。
OceanBase內部實現了高速緩存來緩存存儲過程的可執行代碼及SQL執行計劃,不同參數的存儲過程和SQL可以通過這一高速緩存快速獲取需要的執行對象, 耗時一般在幾十微秒以內, 有效避免了重新編譯帶來的毫秒級的延遲和CPU消耗。
可更新視圖
在OLTP場景中，通過減少應用與數據庫的交互次數來實現性能提升的例子很多，可更新視圖就是其中之一。我們常見的數據庫視圖通常是隻讀的，通過定義視圖，用戶可以定義自己感興趣的數據以及其獲取接口，但視圖同時也可以作爲更新操作的入口，比如在TPC-C的new order創建場景中，應用需要得到商品信息，更新庫存並得到更新後的值。一般可以通過兩條SQL實現這一過程：
select i_price,i_name, i_data from item where i_id = ?;
UPDATE stock
SET s_order_cnt = s_order_cnt + 1,
s_ytd = s_ytd + ?,
s_remote_cnt = s_remote_cnt + ?,
s_quantity = (CASE WHEN s_quantity< ? + 10 THEN s_quantity + 91 ELSE s_quantity END) - ?
WHERE s_i_id = ?
AND s_w_id = ?
RETURNING s_quantity, s_dist_01,
CASE WHEN i_data NOT LIKE'%ORIGINAL%' THEN 'G' ELSE (CASE WHEN s_data NOT LIKE '%ORIGINAL%' THEN 'G'ELSE 'B' END) END
BULK COLLECT INTO ...;但通過建立一個可更新視圖：
CREATE VIEW stock_item AS
SELECT i_price, i_name, i_data, s_i_id,s_w_id, s_order_cnt, s_ytd, s_remote_cnt, s_quantity, s_data, s_dist_01
FROM stock s, item i WHERE s.s_i_id =i.i_id;我們就可以通過一條語句更新庫存並得到商品和庫存信息：
UPDATE stock_item
SET s_order_cnt = s_order_cnt + 1,
s_ytd = s_ytd + ?,
s_remote_cnt = s_remote_cnt + ?,
s_quantity = (CASE WHEN s_quantity< ? + 10 THEN s_quantity + 91 ELSE s_quantity END) - ?
WHERE s_i_id = ?
AND s_w_id = ?
RETURNING i_price, i_name, s_quantity,s_dist_01,
CASE WHEN i_data NOT LIKE'%ORIGINAL%' THEN 'G' ELSE (CASE WHEN s_data NOT LIKE '%ORIGINAL%' THEN 'G'ELSE 'B' END) END
BULK COLLECT INTO ...;這樣就省去了一條語句的交互，並且更新邏輯更加直觀。可更新視圖允許用戶可以像普通表一樣操作視圖，但不是所有視圖都可以定義爲可更新視圖。比如帶distinct, group by的視圖，具體更新哪些行語義是不明確的，因此不能允許更新。具體到上面的stock_item兩表join的視圖，需要滿足所更新表的unique key在join之後保持unique(key-preserved table)，即item.i_id必須是唯一的這個前提。
需要強調，TPC-C規範禁止使用物化視圖，而可更新視圖並沒有改變底層數據表格的存儲形式，是符合規範的。
因爲TPC-C的設計原則是儘可能的“真實”反應一個OLTP系統的運行場景，我們所做的很多優化都具有廣泛的適用性。例如，對於一個高併發的OLTP系統來說，大部分的SQL請求的耗時是非常短的，採用純粹的C/S交互模型的後果必然使系統的時間浪費在應用與數據庫的頻繁交互中，而使用存儲過程可以大大緩解這種交互的耗時，並且增強系統對於網絡抖動的免疫力，這種核心能力對於一個分佈式OLTP數據庫是不可或缺的。
在這次的TPC-C測試中，我們採用了OceanBase 2.0版本開始支持的Oracle兼容模式，存儲過程和SQL全部使用了兼容Oracle的數據類型和語法，這樣做也是爲了在追求極致優化的同時，確保產品迭代可以沿着通用和正規的方向發展。
三、TPC-C基準測試之數據庫事務引擎的挑戰
OceanBase這次TPC-C測試與榜單上Oracle和DB2等其他數據庫在硬件使用上有非常大的不同，OceanBase的數據庫服務器使用的是204+3臺型號是ecs.i2.16xlarge阿里雲ECS服務器，其中204臺作爲data node，還有3臺作爲root node，每位讀者都可以在阿里雲網站上輕鬆按需購買。如果讀者翻看Oracle和DB2的TPC-C測試報告會發現，這些數據庫都會使用專用的存儲設備，例如前最高記錄保持者Oracle在2010年的測試，使用了97臺COMSTAR專用的存儲設備，其中28臺用來存儲數據庫的重做日誌（Redo Log）。
硬件的差異給軟件架構提出了完全不同的挑戰，專用的存儲設備其內部通過硬件冗餘實現了設備自身的可靠保證，數據庫軟件在使用這樣的存儲設備時就天然的預設了數據不會丟失。但是，這種方式帶來了成本的極大消耗，專用的存儲設備的價格都是特別昂貴的。
OceanBase使用通用的ECS服務器提供數據庫服務，並且只使用ECS機器自帶的本地硬盤做數據存儲，這是最通用的硬件條件。但是這種方式對軟件架構提出了很大的挑戰，因爲單個ECS服務器的不如專用的存儲設備可靠性高。這也對OceanBase的事務引擎提出了很大的挑戰，OceanBase是在普通的ECS服務器上就可以實現ACID特性。
TPC-C測試是對事務ACID特性有完整並且嚴格的要求。下面分別介紹OceanBase針對事務ACID的特性的解決方案。
Paxos日誌同步保證持久性（Durability）
OceanBase數據庫的事務持久性（Durability）保證是依賴事務重做日誌（Redo Log）的持久性來達成的。所有的 Redo Log 會實時強同步到另外兩臺數據庫服務機器上，包含產生 Redo Log 的機器在內，總共會有三臺機器在硬盤中持久化 Redo Log。
OceanBase 採用了 Paxos 一致性同步協議來協調這三臺機器上 Redo Log 的持久化，Paxos協議採用超過半數（也叫“多數派”）成功即算成功的算法（三個副本時，兩個成功即超過半數），當其中兩臺機器完成持久化後，事務即可完成提交，剩下的一臺機器的 Redo Log 在通常情況下，也是立即就持久化完成了。但如果這臺機器碰巧出現異常，也不會影響事務的提交，系統會在其恢復後自動補齊所缺失的 Redo Log。如果機器永久故障，系統會將故障機器所應負責同步的數據分散給集羣內的其他機器，這些機器會自動補齊所缺失內容，並跟上最新的 Redo Log 寫入。
使用Paxos一致性協議的最大優勢是數據持久化和數據庫服務可用性的完美平衡。當使用三個副本時，任何時候壞掉一個副本時至少還有另一個副本有數據，並且寫入還可以持續，因爲還剩下兩個副本，後續的寫入也不受影響。
所以，OceanBase 在保證了事務持久性的同時，也大大提升了數據庫的連續服務能力。TPC組織的審計員在現場審計OceanBase持久性能力時，在客戶端持續產生壓力的情況下，從OceanBase集羣中隨意挑選了一臺機器做了強制斷電操作，發現數據庫的數據不僅沒丟，數據庫不需要任何人工干預還能持續的提供服務，審計員們都很吃驚，並且對OceanBase大爲讚賞。
依靠自動兩階段提交解決原子性（Atomicity）
TPC-C測試模型的五種事務中的“訂單創建”和“訂單支付”兩個事務分別會對很多數據做修改，是其中相對複雜的兩個事務。TPC-C標準對事務的原子性（Atomicity）是強制性的要求，要求一個事務內部對倉庫、訂單、用戶等表格的修改一定要原子的生效，不允許出現只有一半成功的情況。
OceanBase的數據是按照倉庫ID（Warehouse_ID）拆分到多臺機器上的，如果所有的事務都是發生在同一個倉庫內部，那麼無論數據量有多大，事務的修改都只會涉及一臺機器的數據，也就是在一臺機器上完成事務提交，這是一種完美的線形擴展的場景。但是這不符合實際的業務場景，大多數的實際業務都會有很多不同維度之間的數據交互。TPC-C測試標準也是對此認真考慮，所以對於事務操作數據的隨機性規則提出了要求，最終要保證產生10%的“訂單創建”事務和15%的“訂單支付”事務要操作兩個及以上的倉庫。在OceanBase數據庫內，這樣就產生了跨機器的事務操作，而這必須使用兩階段提交協議來保證原子性。
OceanBase會自動跟蹤一個事務內所有SQL語句操作的數據，根據實際數據修改的位置自動確定兩階段提交的參與者，事務開始提交時，OceanBase自動選擇第一個參與者作爲協調者，協調者會給所有參與者發送Prepare消息，每個參與者都需要寫各自的Redo Log和Prepare Log（也意味着每個參與者各自做自己的Paxos同步），等協調者確認所有參與者的Redo Log和Prepare Log完成後，然後再給所有參與者發送Commit消息，再等所有參與者的Commit工作完成。整個協議是在事務提交過程中自動完成，對用戶完全透明。OceanBase爲每一個兩階段提交事務自動選擇一個協調者，整個系統任何機器都可以分擔協調者工作，所以OceanBase可以將事務處理能力進行線形擴展。
多版本併發控制保證事務的隔離性（Isolation）
TPC-C標準裏要求“訂單創建”、“訂單支付”、“訂單配送”、“訂單支付”事務之間都是串行化隔離級別（Serializable）。OceanBase採用的方法是基於多版本的併發控制機制。事務提交時會申請一個事務的提交時間戳，事務內的修改以新的版本寫入存儲引擎，並且保證之前版本的數據不受影響。事務開始時會獲取一個讀取時間戳，整個事務內數據的讀取操作只會看到基於讀取時間戳的已提交數據。所以，事務的讀取不會遇到髒數據、不可重複讀數據以及幻讀數據。同時，事務的修改會在修改的數據行上持有行鎖，保證兩個併發的修改相同行的事務會互斥。
OceanBase的全局時間戳生成器也是由多副本組成，可以獨立部署在三臺機器上，也可以像這次TPC-C評測中一樣部署在root node機器上，與root node共享資源。全局時間戳的三副本是一種極高可用的架構，任何一次時間戳的獲取操作都至少在三臺機器上的兩臺獲得了確認，所以任意一臺機器出現故障，獲取時間戳的操作不會有一點影響。
按照TPC-C標準，OceanBase準備了9種不同的場景測試有讀-讀、讀-寫衝突時事務的隔離性，最終都完美通過了審計員的審計。
一致性保證（Consistency）
在有了上述的事務能力後，OceanBase可以完美的保證各種數據的一致性的約束。TPC-C標準裏提出了12種不同的一致性測試場景在各種測試運行前後對數據庫內的數據進行一致性校驗。因爲OceanBase此次測試數據規模龐大，一致性校驗的SQL需要覈對大量的數據，所以一致性校驗的挑戰在於校驗的SQL本身運行的效率。基於OceanBase的並行查詢能力，發揮整個集羣所有的計算資源，校驗SQL的運行時間均縮短了幾個數量級，很好的完成一致性功能的審計工作。
複製表
TPC-C測試模型中有一張商品（ITEM）表，這張表的內容是測試所模擬的銷售公司所有售賣的商品信息，包含了商品的名字、價格等信息。“訂單創建”事務執行中需要請求這張表內的數據來確定訂單的價格信息，如果商品表的數據只存放在一臺機器上，那麼所有機器上發生的“訂單創建”事務都會請求包含商品表的機器，這臺機器就會成爲瓶頸。OceanBase支持複製表功能，將商品表設置爲複製表後，商品表的數據會自動複製到集羣中的每一臺機器上。
TPC-C標準不限制數據的副本數，但是不管數據的組織形式，標準裏要求事務的ACID一定要保證。OceanBase使用特殊的廣播協議保證複製表的所有副本的ACID特性，當複製表發生修改時，所有的副本會同時修改。並且，當有機器出現故障時，複製表的邏輯會自動剔除無效的副本，保證數據修改過程中不會因爲機器故障出現無謂的等待。複製表在很多業務場景中都有使用，例如很多業務中存儲關鍵信息的字典表，還有金融業務中存儲匯率信息的表。
四、TPC-C基準測試之存儲優化
TPC-C規範要求被測數據庫的性能（tpmC）與數據量成正比。TPC-C的基本數據單元是倉庫（warehouse），每個倉庫的數據量通常在70MB左右（與具體實現有關）。TPC-C規定每個倉庫所獲得的tpmC上限是12.86（假設數據庫響應時間爲0）。
假設某系統獲得150萬tpmC，大約對應12萬個倉庫，按照70MB/倉庫計算，數據量約爲8.4TB。某些廠商採用修改過的不符合審計要求的TPC-C測試，不限制單個warehouse的tpmC上限，測試幾百到幾千個warehouse全部裝載到內存的性能，這是沒有意義的，也不可能通過審計。在真實的TPC-C測試中，存儲的消耗佔了很大一部分。OceanBase作爲第一款基於shared nothing架構登上TPC-C榜首的數據庫，同時也作爲第一款使用LSM Tree存儲引擎架構登上TPC-C榜首的數據庫，在存儲架構上有如下關鍵點：
- 爲了保證可靠性，OceanBase存儲了兩個數據副本和三個日誌副本，而傳統的集中式數據庫測試TPC-C只存儲一份數據；
- 由於OceanBase存儲兩個數據副本，再加上OceanBase TPC-C測試採用了和生產系統完全一樣的阿里雲服務器i2機型，SSD硬盤的存儲容量成爲瓶頸。OceanBase採用在線壓縮的方式緩解這個問題，進一步增加了CPU使用；相應地，集中式數據庫測試存儲一份數據，不需要打開壓縮；
- OceanBase LSM引擎定期需要在後臺做compaction操作，而TPC-C要求測試至少運行8小時且2小時之內抖動小於2%，因此，OceanBase存儲需要解決LSM引擎後臺操作導致的抖動問題；
兩份數據
爲了保證可靠性和不丟數據（RPO=0），有兩種不同的方案：一種方案是在硬件層面容錯，另一種方案是在軟件層面容錯。OceanBase選擇在軟件層面容錯，優勢是硬件成本更低，帶來的問題是需要冗餘存儲多個副本的數據。OceanBase使用Paxos協議保證在單機故障下數據的強一致。在Paxos協議中，一份數據需要被同步到多數派（超過一半），才被認爲是寫入成功，所以一般來說副本個數總是奇數，出於成本考慮最常見的部署規格是三副本。
三副本帶來的首要問題就是存儲成本的上升，之前商業數據庫的TPC-C測試大多基於磁盤陣列，而TPC-C規範中明確對磁盤陣列不做容災要求，使用相對於傳統數據庫三倍的存儲空間進行TPC-C測試顯然難以接受。
我們注意到這樣一個事實，通過Paxos協議同步的只是日誌，日誌需要寫三份，但數據不是，數據只需要有兩份就可以完成單機故障的容災了，當一份數據由於服務器宕機不可用時，另一份數據只要通過日誌把數據補齊，就可以繼續對外提供訪問。
和數據存儲相比，日誌的存儲量比較小。我們將數據與日誌分開，定義了三種不同的副本類型：F副本既包含數據又同步日誌，並對外提供讀寫服務；D副本既包含數據又同步日誌，但對外不提供讀寫服務；L副本只同步日誌，不存儲數據。當F副本出現故障時，D副本可以轉換爲F副本，補齊數據後對外提供服務。在TPC-C測試中我們使用FDL模式進行部署（一個F副本，一個D副本，一個L副本），使用了兩倍數據副本的存儲空間。無論是D副本還是L副本，都需要回放日誌，D副本還需要同步數據，這些都是都會消耗網絡和CPU。
在線壓縮
在sharednothing架構下，OceanBase至少需要存儲兩份數據纔可以滿足容災的要求，這意味着OceanBase需要比傳統數據庫多耗費一倍的存儲空間。
爲了緩解這個問題，OceanBaseTPC-C測試選擇對數據進行在線壓縮，Oracle數據庫中一個warehouse的存儲容量接近70MB，而OceanBase壓縮後存儲容量只有50MB左右，大幅降低了存儲空間。TPC-C規範要求磁盤空間能夠滿足60天數據量的存儲，對於OceanBase，由於需要保存兩份數據，雖然可靠性更好，但需要保存相當於120天的數據量，這些存儲成本都要計入總體價格。
OceanBase使用了204臺ECS i2雲服務器存儲數據，服務器規格和線上真實業務應用保持一致。每臺服務器的日誌盤1TB，數據盤接近13TB。計算兩份壓縮後的數據60天的存儲空間之後，服務器的數據盤基本沒有太多餘量,從服務器的資源成本消耗來看，已經達到了比較好的平衡。如果OceanBase的單機性能tpmC進一步提升，磁盤容量將成爲瓶頸。OceanBase LSM引擎是append-only的，它的優勢是沒有隨機修改，能夠在線壓縮。無論是TPC-C測試，還是最核心的OLTP生產系統（例如支付寶交易支付），OceanBase都會打開在線壓縮，通過CPU換存儲空間。
存儲性能平滑
TPC-C測試很大的挑戰在於在整個壓測過程中性能曲線要求是絕對平滑的，曲線上的波動幅度不能超過2%，這對於傳統數據庫來說都是一件困難的事情，因爲這要求對於所有後臺任務的精細控制，不能由於某個後臺任務的資源過度使用導致前臺請求的阻塞積壓。而對於OceanBase而言，事情變得更爲困難，因爲OceanBase的存儲引擎是基於LSM Tree的，在LSM Tree要定期執行compaction操作。Compaction是個非常重的後臺操作，會佔用大量CPU和磁盤IO資源，這對前臺的用戶查詢和寫入天然就會造成影響。我們做了一些優化，來平滑後臺任務對性能的影響，從最終的測試結果來看，性能曲線在整個8小時壓測過程中的抖動小於0.5%。
- 分層轉儲
在LSMTree中，數據首先被寫入內存中的MemTable，在一定時候爲了釋放內存，MemTable中的數據需要與磁盤中的SSTable進行合併，這個過程被稱爲compaction。在很多基於LSM Tree的存儲系統中，爲了解決寫入的性能問題，通常會將SSTable分爲多層，當一層的SSTable個數或者大小達到某個閾值時，合併入下一層SSTable。多層SSTable解決了寫入的問題，但是SSTable的個數過多，會極大拖慢查詢的性能。OceanBase同樣借鑑了分層的思路，但同時使用了更加靈活的compaction策略，確保SSTable總數不會太多，從而在讀取和寫入性能之間做了更好的平衡。
- 資源隔離
Compaction等後臺任務需要消耗大量的服務器資源，爲了減少後臺任務對用戶查詢和寫入的影響，我們在CPU、內存、磁盤IO和網絡IO四個方面對前後臺任務做了資源隔離。在CPU方面，我們將後臺任務和用戶請求分爲不同的線程池，並按照CPU親和性做了隔離。在內存方面，對前後臺請求做了不同的內存管理。在磁盤IO方面，我們控制後臺任務IO請求的IOPS，使用deadline算法進行流控。在網絡IO方面，我們將後臺任務RPC和用戶請求RPC分爲不同隊列，並對後臺任務RPC的帶寬使用進行流控。
存儲CPU佔用
TPC-C基準測試主要考察整體性能tpmC，很多人也會關注單核的tpmC。然而，這個指標只有在相同架構下才有意義。對於存儲模塊的CPU佔用，有如下三點：
- 對於集中式架構，除了數據庫使用CPU之外，專用存儲設備也需要使用CPU。例如，第二名Oracle 3000多萬tpmC的測試中，數據庫使用了108顆T3SPARC處理器，共有1728個物理核心和13824個執行線程，同時存儲設備使用的是Intel服務器作爲機頭，總共使用了97臺服務器，194顆Intel X5670 CPU，2328個物理核心。
- 集中式數據庫使用高可靠硬件，只需要存儲一個副本，而OceanBase通過軟件層面容錯，雖然硬件成本更低但需要兩個數據副本和三個日誌副本，維護多個副本需要耗費大量CPU；
- OceanBase在TPC-C測試和生產系統中都打開了在線壓縮，進一步增加了CPU使用；
因此，簡單地對比OceanBase和Oracle的CPU核是不科學的，還需要算上共享存儲設備的CPU核，以及OceanBase存儲多副本和在線壓縮帶來的CPU開銷。TPC-C推薦的方案是不關注具體的軟件架構和硬件架構，關注硬件總體成本。在OceanBase的測試中，硬件成本只佔整體成本的18%左右，只考慮硬件的性價比大幅優於集中式數據庫。
後續發展
OceanBase的優勢在於採用分佈式架構，硬件成本更低，可用性更好且能夠做到線性擴展，但是，OceanBase單機的性能離Oracle、DB2還有不小的差距，後續需要重點優化單機存儲性能。另外，OceanBase的定位是在同一套引擎同時支持OLTP業務和OLAP業務，而目前OceanBase的OLAP處理能力還不如Oracle，後續需要加強存儲模塊對大查詢的處理能力，支持將OLAP算子下壓到存儲層甚至在壓縮後的數據上直接做OLAP計算。
本文作者：陽振坤（OceanBase創始人）、曹暉（OceanBase技術專家）、陳萌萌（OceanBase資深技術專家）、潘毅（OceanBase資深技術專家）、韓富晟（OceanBase資深技術專家）、趙裕衆（OceanBase高級技術專家）
本文來自雲棲社區合作伙伴“阿里技術”，如需轉載請聯繫原作者。