阿裡妹導讀：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使用率，整個吞吐量也随之提高。存儲過程在縮短應用端的等待耗時上同樣有很大作用。
圖1 傳統的C/S模型與使用存儲過程的執行方式對比
在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進階技術專家）
原文釋出時間為：2019-10-9
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。