TPC-C是TPC組織(國際事務性能委員會)制定的關于商品銷售的訂單創(chuàng)建和訂單支付等的基準測試標準，是數(shù)據(jù)庫聯(lián)機交易處理系統(tǒng)的權(quán)威基準測試標準。

[[278493]]

螞蟻金服自研的分布式關系數(shù)據(jù)庫OceanBase獲得TPC-C測試第一名后，引起了大量關注，今天，我們邀請了OceanBase的核心研發(fā)人員對本次測試做專業(yè)的技術解讀。

一、OceanBase如何做TPC-C測試

有機會挑戰(zhàn)TPC-C測試相信是所有數(shù)據(jù)庫內(nèi)核開發(fā)人員的夢想，但TPC-C測試標準非常復雜。由于這是國產(chǎn)數(shù)據(jù)庫同時也是分布式數(shù)據(jù)庫第一次沖擊這個榜單，為了完成這次挑戰(zhàn)，OceanBase團隊前后準備時間超過一年。

前期準備

TPC-C測試首先需要找到官方唯一認證的審計員來對測試進行審計監(jiān)察，他們對這次OceanBase的審計也相當重視，全世界僅有的三個審計員這次就有兩個參與到測試審計工作中。

測試系統(tǒng)

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

在標準定義中，測試系統(tǒng)可以分為RTE(Remote Terminal Emulator)和SUT兩部分，但實際上從角色上看SUT可以進一步拆分為兩部分：WAS(web application server)和DB Server。

這其中DB Server是每個測試廠商的數(shù)據(jù)庫服務;RTE扮演的角色是測試模型中的客戶終端，事務的觸發(fā)、RT的統(tǒng)計等都在這里完成;標準明確要求每一個用戶terminal都必須保持一個長連接，顯然在海量Warehouse時DB是無法承受這么多連接的，WAS就是RTE和DB之間橋梁，標準定義可以使用連接池，在保證對應用透明的情況下它可以做所有請求的管理。

這三個角色中，WAS和DB是必須商業(yè)化可購買且提供支付服務的，OceanBase這次是使用了OpenResty作為WAS供應商。而RTE則一般由各個參測廠商自行根據(jù)標準實現(xiàn)，但所有實現(xiàn)代碼必須經(jīng)過審計的嚴格審計，OceanBase這次完整的實現(xiàn)了一整套完全合規(guī)的RTE，并且支持在大規(guī)模測試系統(tǒng)中部署。要知道在實際的TPC-C測試流程中，不只是對DB端能力的考驗，RTE端同樣存在極大的資源消耗和壓力。以這次6088w tpmC測試結(jié)果看，我們一共在64臺64c128G的云服務器上運行了960個RTE客戶端，來模擬總計47942400個用戶terminal，最后還需要基于這么多RTE統(tǒng)計結(jié)果進行一致性和持久化審計驗證。

雖然只是測試客戶端，但RTE的中同樣有大量的可能導致最后測試失敗的小細節(jié)，比如大家可能注意不到的所有事務都因為用了web端模擬終端后需要增加的100毫秒rt，又比如為了模擬用戶終端輸出顯示的100毫秒延時。

測試規(guī)劃

TPC-C從來都不是一個簡單的測試，它很科學并沒有給出強制的軟硬件配置，只是給出測試規(guī)范和各種審計檢查限制標準，所有數(shù)據(jù)庫廠商可以根據(jù)自己的特性充分調(diào)優(yōu)來拿到一個最好的性能或性價比。但這同時也對所有參測廠商提出了一個巨大的難題，如何對已有的資源進行合理規(guī)劃來保證順利完成一次對TPC-C榜單的沖擊。

1. 硬件選型，這里不僅要對數(shù)據(jù)庫服務器選型，還需要對RTE以及WAS服務器選型。這之前需要先期進行大量的測試和調(diào)優(yōu)，來摸出在保證性價比的前提下每個角色服務器的資源配置是多少剛好。這次OceanBase測試最大的優(yōu)勢就是全部使用了云化資源，我們不需要再關注最底層機房、機柜、布線這些細節(jié)，只需要通過快速的規(guī)格調(diào)整來拿到我們需要的機型。

2. 參數(shù)選擇，如何選擇合適的配置參數(shù)是一個非常令人頭疼的問題。舉個例子，一個最典型的問題就是我們最終要跑多少個Warehouse，每個數(shù)據(jù)庫服務器上承載多少Warehouse。TPC-C標準為了盡可能模擬真實業(yè)務場景，通過每個事務限定不同的think time和keying time保證了一個warehouse的數(shù)據(jù)最多能夠提供12.86tpmC值，因此數(shù)據(jù)庫廠商想要拿到更高的成績就必須裝載更多的warehouse，但是另一方面單機的存儲空間又有預計80%(經(jīng)驗值)需要預留給60天增量存儲。在分布式數(shù)據(jù)庫架構(gòu)下，為了能讓每個數(shù)據(jù)庫服務器跑滿又能充分利用本地存儲空間，讓每個服務器的CPU、內(nèi)存、IO能力、存儲空間的資源最大化利用，我們前后調(diào)整優(yōu)化了近一個月時間。

性能壓測

最受關注的性能壓測部分在TPC-C標準中規(guī)定了以下三個狀態(tài)：

1. Ramp-up，標準允許每個數(shù)據(jù)庫進行一定時間的預熱來達到穩(wěn)定狀態(tài)，但是ramp-up階段的所有配置必須和最終報告配置保持一致。

2. Steady state，保證ACID及可串行化隔離級別前提下，數(shù)據(jù)庫需要能夠以最終報告tpmC值在穩(wěn)定狀態(tài)無任何人工干預前提下保持運行8小時以上，每隔半小時需要完成一次checkpoint。

3. Measurement Interval，標準規(guī)定了需要能夠支持8小時穩(wěn)定運行，但性能采集階段只需要保設置2小時以上即可。這個階段還需要保證累計tpmC波動不能超過2%，并且必須完成至少4個以上的checkpoint。

所以之前一般數(shù)據(jù)庫進行性能壓測一般是以下的流程，先進行一段時間的預熱到達穩(wěn)態(tài)，等待穩(wěn)定運行一段時間并完成一個checkpoint后開始進入2小時的性能采集階段。

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

整個性能測試前后，審計員還需要進行數(shù)據(jù)及事務隨機分布檢查，簡單說來就是大量全表掃描和統(tǒng)計sql，最大的一條sql需要訪問超過萬億行的order_line表結(jié)果，可以算是TPC-C里的“TPC-H測試”?，F(xiàn)場審計第一次遇到這些sql時我們也大量的出現(xiàn)sql執(zhí)行超時情況，但后續(xù)基于OceanBase2.2版本最新的并行執(zhí)行框架我們還是很快搞定了這些大sql，所以要順利完成TPC-C測試并不能只是一個偏科生，保持自身沒有短板才是真正意義上的通用關系數(shù)據(jù)庫，從這點上說Oracle仍是OceanBase學習的榜樣。

ACID

1. A測試，通過提交和回滾payment事務來確認數(shù)據(jù)庫對原子性支持，和I測試一樣，OceanBase的A測試跑了兩遍，分別應對分布式事務和本地事務。

2. C測試，標準里的C測試一共包含12個case，前四個是必須要完成驗證的，每個case其實都可以認為是一個復雜的大sql，而對于分布式數(shù)據(jù)庫來說重點是需要始終保證全局一致。

3. I測試，標準要求TPC-C模型里5個事務除了StockLevel事務都需要滿足最高的可串行化隔離級別，并構(gòu)造了9個case來驗證隔離性。對于分布式數(shù)據(jù)庫而言，這個要求并沒有那么容易實現(xiàn)，所幸OceanBase在2.x版本中提供了全局時間戳的支持，所以的I測試都在審計員的特別要求下跑完了全本地和全分布式兩種模式的兩輪測試，這也應該是TPC-C測試中首次有數(shù)據(jù)庫廠商需要做兩輪I測試跑18個case的，也許在不久后TPC-C標準定義也會因為OceanBase的這次測試而帶來針對分布式數(shù)據(jù)庫的相關更新。

4. D測試，OceanBase在這個場景其實相對傳統(tǒng)數(shù)據(jù)庫是有較大天生優(yōu)勢的，OceanBase每個Warehouse數(shù)據(jù)有兩份數(shù)據(jù)三份日志，通過paxos強同步，保證RPO=0的前提下只有秒級RTO。

面對D測試標準中最嚴格的一項-部分存儲介質(zhì)永久故障，OceanBase還使用了最嚴苛的測試場景，在使用超出標準要求的全量6000W tpmC壓力下，我們強行銷毀了一個云服務器節(jié)點，整體tpmC在兩分鐘內(nèi)恢復到6000w并持續(xù)跑到測試時間結(jié)束，這些表現(xiàn)都是遠遠超過TPC-C規(guī)范要求的，相比較而言其它傳統(tǒng)數(shù)據(jù)庫基本面對有日志的存儲介質(zhì)故障D測試場景都是依賴磁盤RAID來恢復，OceanBase應該算是首個沒有raid完全依賴數(shù)據(jù)庫自身恢復機制完成全部D測試的數(shù)據(jù)庫廠商了。

同時我們在D測試中是連續(xù)殺掉了兩臺服務器節(jié)點，首先殺掉一個數(shù)據(jù)節(jié)點，等待tpmC恢復且穩(wěn)定5分鐘后，再次殺掉了rootserver leader節(jié)點，tpmC仍然快速恢復。

二、TPC-C基準測試之SQL優(yōu)化

對TPC-C有所了解人都知道，TPC-C是一個典型的OLTP (On-Line Transaction Processing) 場景測試，考察的是數(shù)據(jù)庫在高并發(fā)壓力場景下的事務處理能力，最終的性能指標以tpmC(transaction per minute，也即每分鐘系統(tǒng)處理TPC-C模型中的new order事務的數(shù)量)和平均到每tpmC的系統(tǒng)成本作為衡量標準。在OLTP場景中，每條請求的響應時間都是極短的。因此，各個數(shù)據(jù)庫廠商在進行TPC-C測試時，都會盡一切可能將每一個操作時間壓縮到最短，不夸張的說，在TPC-C的測試中，一些關鍵操作的優(yōu)化往往需要細化到CPU指令級。

在進入我們的主題前，我們先來談談TPC-C中的事務模型，主要分為五種事務，訂單創(chuàng)建、訂單支付、訂單查詢、訂單發(fā)貨以及庫存查詢，這五種事務按照一定的比例發(fā)生，測試最終衡量的是每分鐘訂單創(chuàng)建事務的執(zhí)行個數(shù)。大家知道，每一個數(shù)據(jù)庫的事務，其實就是由一定邏輯關系關聯(lián)的若干條SQL語句組成，他們在一個事務中，要么全部成功，要么全部失敗，這個在數(shù)據(jù)庫中稱為“原子性”，也就是ACID中的“A”。那么TPC-C中的一個事務的耗時大約是多久呢?看一下報告就很清楚了——只有十幾個毫秒?？紤]到一個事務由多條SQL構(gòu)成，那么每一條SQL的平均耗時都不到1毫秒!

在C/S(client-server)模型中，一條SQL語句從發(fā)起到執(zhí)行完成需要經(jīng)歷從客戶端輸入、網(wǎng)絡傳輸、SQL優(yōu)化、執(zhí)行、結(jié)果返回到客戶端這樣一個流程。而具體每一條SQL的執(zhí)行可能只是做一個字段的更新，所需要的執(zhí)行時間是非常短暫的，從整個鏈路的角度來看，大量的時間會花費在與客戶端的交互過程中，造成資源的浪費和耗時的增加。那么如何解決這個問題的呢?

答案就是使用存儲過程。

存儲過程 所謂“存儲過程”就是數(shù)據(jù)庫為用戶提供的一種面向過程的編程語言?；谶@種語言，用戶可以將應用程序的邏輯封裝為一個可調(diào)用的過程(procedure)存放在數(shù)據(jù)庫中并隨時進行調(diào)用。通過這種方式，用戶可以將本來需要與數(shù)據(jù)庫進行多次交互才能完成的工作通過一次交互完成，省去了中間網(wǎng)絡的傳輸和等待時間(參見圖1)。假如一條事務的網(wǎng)絡開銷平均是30%，也就是說30%的CPU都花在了網(wǎng)絡的收發(fā)和解析上。那么在6千萬規(guī)模tpmC測試中節(jié)省下來30%的CPU資源換算成系統(tǒng)處理能力是驚人的。使用存儲過程還可以帶來事務響應時間的下降，導致數(shù)據(jù)庫內(nèi)核中事務鎖的臨界區(qū)縮短，間接的提升了系統(tǒng)CPU利用率，整個吞吐量也隨之提高。存儲過程在縮短應用端的等待耗時上同樣有很大作用。

圖1 傳統(tǒng)的C/S模型與使用存儲過程的執(zhí)行方式對比

在TPC-C中，存儲過程對于整個系統(tǒng)的執(zhí)行效率提升是至關重要的。OceanBase 的2.2版本不僅全面支持了存儲過程，而且對存儲過程的執(zhí)行效率做了大量極致的優(yōu)化。

編譯執(zhí)行

存儲過程作為一種面向過程的高級語言，需要轉(zhuǎn)換成機器碼才能夠執(zhí)行。這個過程一般可以分為“編譯執(zhí)行”和“解釋執(zhí)行”兩種，一般來說，編譯執(zhí)行相比解釋執(zhí)行有代碼優(yōu)化充分、執(zhí)行效率高等特點。OceanBase利用近兩年逐漸成熟的LLVM編譯器框架實現(xiàn)了一個支持存儲過程的編譯器，通過動態(tài)編譯(Just-in-Time Compilation)的方式將存儲過程翻譯成高效的二進制可執(zhí)行代碼，在執(zhí)行效率上獲得了數(shù)量級的提升。同時，過程中LLVM框架將存儲過程轉(zhuǎn)換為與機器無關的中間代碼，使得存儲過程也自然而然地獲得了跨平臺的編譯執(zhí)行能力，LLVM內(nèi)置的優(yōu)化過程確保我們在各種不同的硬件平臺上都可以獲得正確、高效的可執(zhí)行代碼。

Array Binding

另外一個在TPC-C測試中發(fā)揮了重要作用的功能就是對DML語句進行批量處理的能力，在Oracle中該功能也稱為“Array Binding”。一條SQL在數(shù)據(jù)庫中的執(zhí)行過程大致上可以分為“計劃生成”和“執(zhí)行”兩個階段。盡管我們對SQL的執(zhí)行計劃做了高速緩存，但找到一個合適的執(zhí)行計劃在整個執(zhí)行過程中仍然是比較耗時的一個部分。那有沒有辦法省去這個時間呢?當一組SQL的執(zhí)行計劃完全一樣而只有執(zhí)行參數(shù)不同時，在存儲過程中我們可以通過特定的語法將他們的執(zhí)行做成一個批量處理的過程，此時“計劃生成”只需要做一次即可，這就是所謂的“Array Binding”。

在Array Binding中，數(shù)據(jù)庫會首先找到需要使用的計劃，然后執(zhí)行該計劃，并在每次執(zhí)行完畢后，重新執(zhí)行參數(shù)綁定(binding)的過程。打個比方，這就像是在一個C語言的for循環(huán)中，反復賦值而不是重新定義一個數(shù)據(jù)結(jié)構(gòu)。Array Binding的使用受用戶控制，需要在存儲過程中使用FORALL關鍵字來觸發(fā)這一功能，在TPC-C的測試過程中，我們多次使用了Array Binding來提升系統(tǒng)的處理能力，效果非常明顯。

Prepared Statement與執(zhí)行計劃緩存

Prepared Statement是一種二進制的請求交互協(xié)議，可以大大降低系統(tǒng)的交互成本。OceanBase不僅支持用戶程序與數(shù)據(jù)庫間使用Prepared Statement, 也支持在存儲過程引擎調(diào)用SQL引擎執(zhí)行時使用這種交互方式。存儲過程在對SQL進行一次Prepare操作并獲取唯一id后, 后續(xù)的每次執(zhí)行僅需要傳入該id和對應的參數(shù),系統(tǒng)可以通過高速緩存找到對應的存儲過程或SQL計劃開始執(zhí)行。該過程相比使用SQL文本的交互方式，省去了大量請求文本解析的CPU開銷。

OceanBase內(nèi)部實現(xiàn)了高速緩存來緩存存儲過程的可執(zhí)行代碼及SQL執(zhí)行計劃,不同參數(shù)的存儲過程和SQL可以通過這一高速緩存快速獲取需要的執(zhí)行對象, 耗時一般在幾十微秒以內(nèi), 有效避免了重新編譯帶來的毫秒級的延遲和CPU消耗。

可更新視圖

在OLTP場景中，通過減少應用與數(shù)據(jù)庫的交互次數(shù)來實現(xiàn)性能提升的例子很多，可更新視圖就是其中之一。我們常見的數(shù)據(jù)庫視圖通常是只讀的，通過定義視圖，用戶可以定義自己感興趣的數(shù)據(jù)以及其獲取接口，但視圖同時也可以作為更新操作的入口，比如在TPC-C的new order創(chuàng)建場景中，應用需要得到商品信息，更新庫存并得到更新后的值。一般可以通過兩條SQL實現(xiàn)這一過程：

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 ...; 

這樣就省去了一條語句的交互，并且更新邏輯更加直觀?？筛乱晥D允許用戶可以像普通表一樣操作視圖，但不是所有視圖都可以定義為可更新視圖。比如帶distinct, group by的視圖，具體更新哪些行語義是不明確的，因此不能允許更新。具體到上面的stock_item兩表join的視圖，需要滿足所更新表的unique key在join之后保持unique(key-preserved table)，即item.i_id必須是唯一的這個前提。

需要強調(diào)，TPC-C規(guī)范禁止使用物化視圖，而可更新視圖并沒有改變底層數(shù)據(jù)表格的存儲形式，是符合規(guī)范的。

因為TPC-C的設計原則是盡可能的“真實”反應一個OLTP系統(tǒng)的運行場景，我們所做的很多優(yōu)化都具有廣泛的適用性。例如，對于一個高并發(fā)的OLTP系統(tǒng)來說，大部分的SQL請求的耗時是非常短的，采用純粹的C/S交互模型的后果必然使系統(tǒng)的時間浪費在應用與數(shù)據(jù)庫的頻繁交互中，而使用存儲過程可以大大緩解這種交互的耗時，并且增強系統(tǒng)對于網(wǎng)絡抖動的免疫力，這種核心能力對于一個分布式OLTP數(shù)據(jù)庫是不可或缺的。

在這次的TPC-C測試中，我們采用了OceanBase 2.0版本開始支持的Oracle兼容模式，存儲過程和SQL全部使用了兼容Oracle的數(shù)據(jù)類型和語法，這樣做也是為了在追求極致優(yōu)化的同時，確保產(chǎn)品迭代可以沿著通用和正規(guī)的方向發(fā)展。

三、TPC-C基準測試之數(shù)據(jù)庫事務引擎的挑戰(zhàn)

OceanBase這次TPC-C測試與榜單上Oracle和DB2等其他數(shù)據(jù)庫在硬件使用上有非常大的不同，OceanBase的數(shù)據(jù)庫服務器使用的是204+3臺型號是ecs.i2.16xlarge阿里云ECS服務器，其中204臺作為data node，還有3臺作為root node，每位讀者都可以在阿里云網(wǎng)站上輕松按需購買。如果讀者翻看Oracle和DB2的TPC-C測試報告會發(fā)現(xiàn)，這些數(shù)據(jù)庫都會使用專用的存儲設備，例如前最高記錄保持者Oracle在2010年的測試，使用了97臺COMSTAR專用的存儲設備，其中28臺用來存儲數(shù)據(jù)庫的重做日志(Redo Log)。

硬件的差異給軟件架構(gòu)提出了完全不同的挑戰(zhàn)，專用的存儲設備其內(nèi)部通過硬件冗余實現(xiàn)了設備自身的可靠保證，數(shù)據(jù)庫軟件在使用這樣的存儲設備時就天然的預設了數(shù)據(jù)不會丟失。但是，這種方式帶來了成本的極大消耗，專用的存儲設備的價格都是特別昂貴的。

OceanBase使用通用的ECS服務器提供數(shù)據(jù)庫服務，并且只使用ECS機器自帶的本地硬盤做數(shù)據(jù)存儲，這是最通用的硬件條件。但是這種方式對軟件架構(gòu)提出了很大的挑戰(zhàn)，因為單個ECS服務器的不如專用的存儲設備可靠性高。這也對OceanBase的事務引擎提出了很大的挑戰(zhàn)，OceanBase是在普通的ECS服務器上就可以實現(xiàn)ACID特性。

TPC-C測試是對事務ACID特性有完整并且嚴格的要求。下面分別介紹OceanBase針對事務ACID的特性的解決方案。

Paxos日志同步保證持久性(Durability)

OceanBase數(shù)據(jù)庫的事務持久性(Durability)保證是依賴事務重做日志(Redo Log)的持久性來達成的。所有的 Redo Log 會實時強同步到另外兩臺數(shù)據(jù)庫服務機器上，包含產(chǎn)生 Redo Log 的機器在內(nèi)，總共會有三臺機器在硬盤中持久化 Redo Log。

OceanBase 采用了 Paxos 一致性同步協(xié)議來協(xié)調(diào)這三臺機器上 Redo Log 的持久化，Paxos協(xié)議采用超過半數(shù)(也叫“多數(shù)派”)成功即算成功的算法(三個副本時，兩個成功即超過半數(shù))，當其中兩臺機器完成持久化后，事務即可完成提交，剩下的一臺機器的 Redo Log 在通常情況下，也是立即就持久化完成了。但如果這臺機器碰巧出現(xiàn)異常，也不會影響事務的提交，系統(tǒng)會在其恢復后自動補齊所缺失的 Redo Log。如果機器永久故障，系統(tǒng)會將故障機器所應負責同步的數(shù)據(jù)分散給集群內(nèi)的其他機器，這些機器會自動補齊所缺失內(nèi)容，并跟上最新的 Redo Log 寫入。

使用Paxos一致性協(xié)議的最大優(yōu)勢是數(shù)據(jù)持久化和數(shù)據(jù)庫服務可用性的完美平衡。當使用三個副本時，任何時候壞掉一個副本時至少還有另一個副本有數(shù)據(jù)，并且寫入還可以持續(xù)，因為還剩下兩個副本，后續(xù)的寫入也不受影響。

所以，OceanBase 在保證了事務持久性的同時，也大大提升了數(shù)據(jù)庫的連續(xù)服務能力。TPC組織的審計員在現(xiàn)場審計OceanBase持久性能力時，在客戶端持續(xù)產(chǎn)生壓力的情況下，從OceanBase集群中隨意挑選了一臺機器做了強制斷電操作，發(fā)現(xiàn)數(shù)據(jù)庫的數(shù)據(jù)不僅沒丟，數(shù)據(jù)庫不需要任何人工干預還能持續(xù)的提供服務，審計員們都很吃驚，并且對OceanBase大為贊賞。

依靠自動兩階段提交解決原子性(Atomicity)

TPC-C測試模型的五種事務中的“訂單創(chuàng)建”和“訂單支付”兩個事務分別會對很多數(shù)據(jù)做修改，是其中相對復雜的兩個事務。TPC-C標準對事務的原子性(Atomicity)是強制性的要求，要求一個事務內(nèi)部對倉庫、訂單、用戶等表格的修改一定要原子的生效，不允許出現(xiàn)只有一半成功的情況。

OceanBase的數(shù)據(jù)是按照倉庫ID(Warehouse_ID)拆分到多臺機器上的，如果所有的事務都是發(fā)生在同一個倉庫內(nèi)部，那么無論數(shù)據(jù)量有多大，事務的修改都只會涉及一臺機器的數(shù)據(jù)，也就是在一臺機器上完成事務提交，這是一種完美的線形擴展的場景。但是這不符合實際的業(yè)務場景，大多數(shù)的實際業(yè)務都會有很多不同維度之間的數(shù)據(jù)交互。TPC-C測試標準也是對此認真考慮，所以對于事務操作數(shù)據(jù)的隨機性規(guī)則提出了要求，最終要保證產(chǎn)生10%的“訂單創(chuàng)建”事務和15%的“訂單支付”事務要操作兩個及以上的倉庫。在OceanBase數(shù)據(jù)庫內(nèi)，這樣就產(chǎn)生了跨機器的事務操作，而這必須使用兩階段提交協(xié)議來保證原子性。

OceanBase會自動跟蹤一個事務內(nèi)所有SQL語句操作的數(shù)據(jù)，根據(jù)實際數(shù)據(jù)修改的位置自動確定兩階段提交的參與者，事務開始提交時，OceanBase自動選擇第一個參與者作為協(xié)調(diào)者，協(xié)調(diào)者會給所有參與者發(fā)送Prepare消息，每個參與者都需要寫各自的Redo Log和Prepare Log(也意味著每個參與者各自做自己的Paxos同步)，等協(xié)調(diào)者確認所有參與者的Redo Log和Prepare Log完成后，然后再給所有參與者發(fā)送Commit消息，再等所有參與者的Commit工作完成。整個協(xié)議是在事務提交過程中自動完成，對用戶完全透明。OceanBase為每一個兩階段提交事務自動選擇一個協(xié)調(diào)者，整個系統(tǒng)任何機器都可以分擔協(xié)調(diào)者工作，所以OceanBase可以將事務處理能力進行線形擴展。

多版本并發(fā)控制保證事務的隔離性(Isolation)

TPC-C標準里要求“訂單創(chuàng)建”、“訂單支付”、“訂單配送”、“訂單支付”事務之間都是串行化隔離級別(Serializable)。OceanBase采用的方法是基于多版本的并發(fā)控制機制。事務提交時會申請一個事務的提交時間戳，事務內(nèi)的修改以新的版本寫入存儲引擎，并且保證之前版本的數(shù)據(jù)不受影響。事務開始時會獲取一個讀取時間戳，整個事務內(nèi)數(shù)據(jù)的讀取操作只會看到基于讀取時間戳的已提交數(shù)據(jù)。所以，事務的讀取不會遇到臟數(shù)據(jù)、不可重復讀數(shù)據(jù)以及幻讀數(shù)據(jù)。同時，事務的修改會在修改的數(shù)據(jù)行上持有行鎖，保證兩個并發(fā)的修改相同行的事務會互斥。

OceanBase的全局時間戳生成器也是由多副本組成，可以獨立部署在三臺機器上，也可以像這次TPC-C評測中一樣部署在root node機器上，與root node共享資源。全局時間戳的三副本是一種極高可用的架構(gòu)，任何一次時間戳的獲取操作都至少在三臺機器上的兩臺獲得了確認，所以任意一臺機器出現(xiàn)故障，獲取時間戳的操作不會有一點影響。

按照TPC-C標準，OceanBase準備了9種不同的場景測試有讀-讀、讀-寫沖突時事務的隔離性，最終都完美通過了審計員的審計。

一致性保證(Consistency)

在有了上述的事務能力后，OceanBase可以完美的保證各種數(shù)據(jù)的一致性的約束。TPC-C標準里提出了12種不同的一致性測試場景在各種測試運行前后對數(shù)據(jù)庫內(nèi)的數(shù)據(jù)進行一致性校驗。因為OceanBase此次測試數(shù)據(jù)規(guī)模龐大，一致性校驗的SQL需要核對大量的數(shù)據(jù)，所以一致性校驗的挑戰(zhàn)在于校驗的SQL本身運行的效率?；贠ceanBase的并行查詢能力，發(fā)揮整個集群所有的計算資源，校驗SQL的運行時間均縮短了幾個數(shù)量級，很好的完成一致性功能的審計工作。

復制表

TPC-C測試模型中有一張商品(ITEM)表，這張表的內(nèi)容是測試所模擬的銷售公司所有售賣的商品信息，包含了商品的名字、價格等信息。“訂單創(chuàng)建”事務執(zhí)行中需要請求這張表內(nèi)的數(shù)據(jù)來確定訂單的價格信息，如果商品表的數(shù)據(jù)只存放在一臺機器上，那么所有機器上發(fā)生的“訂單創(chuàng)建”事務都會請求包含商品表的機器，這臺機器就會成為瓶頸。OceanBase支持復制表功能，將商品表設置為復制表后，商品表的數(shù)據(jù)會自動復制到集群中的每一臺機器上。

TPC-C標準不限制數(shù)據(jù)的副本數(shù)，但是不管數(shù)據(jù)的組織形式，標準里要求事務的ACID一定要保證。OceanBase使用特殊的廣播協(xié)議保證復制表的所有副本的ACID特性，當復制表發(fā)生修改時，所有的副本會同時修改。并且，當有機器出現(xiàn)故障時，復制表的邏輯會自動剔除無效的副本，保證數(shù)據(jù)修改過程中不會因為機器故障出現(xiàn)無謂的等待。復制表在很多業(yè)務場景中都有使用，例如很多業(yè)務中存儲關鍵信息的字典表，還有金融業(yè)務中存儲匯率信息的表。

四、TPC-C基準測試之存儲優(yōu)化

TPC-C規(guī)范要求被測數(shù)據(jù)庫的性能(tpmC)與數(shù)據(jù)量成正比。TPC-C的基本數(shù)據(jù)單元是倉庫(warehouse)，每個倉庫的數(shù)據(jù)量通常在70MB左右(與具體實現(xiàn)有關)。TPC-C規(guī)定每個倉庫所獲得的tpmC上限是12.86(假設數(shù)據(jù)庫響應時間為0)。

假設某系統(tǒng)獲得150萬tpmC，大約對應12萬個倉庫，按照70MB/倉庫計算，數(shù)據(jù)量約為8.4TB。某些廠商采用修改過的不符合審計要求的TPC-C測試，不限制單個warehouse的tpmC上限，測試幾百到幾千個warehouse全部裝載到內(nèi)存的性能，這是沒有意義的，也不可能通過審計。在真實的TPC-C測試中，存儲的消耗占了很大一部分。OceanBase作為第一款基于shared nothing架構(gòu)登上TPC-C榜首的數(shù)據(jù)庫，同時也作為第一款使用LSM Tree存儲引擎架構(gòu)登上TPC-C榜首的數(shù)據(jù)庫，在存儲架構(gòu)上有如下關鍵點：

1. 為了保證可靠性，OceanBase存儲了兩個數(shù)據(jù)副本和三個日志副本，而傳統(tǒng)的集中式數(shù)據(jù)庫測試TPC-C只存儲一份數(shù)據(jù);

2. 由于OceanBase存儲兩個數(shù)據(jù)副本，再加上OceanBase TPC-C測試采用了和生產(chǎn)系統(tǒng)完全一樣的阿里云服務器i2機型，SSD硬盤的存儲容量成為瓶頸。OceanBase采用在線壓縮的方式緩解這個問題，進一步增加了CPU使用;相應地，集中式數(shù)據(jù)庫測試存儲一份數(shù)據(jù)，不需要打開壓縮;

3. OceanBase LSM引擎定期需要在后臺做compaction操作，而TPC-C要求測試至少運行8小時且2小時之內(nèi)抖動小于2%，因此，OceanBase存儲需要解決LSM引擎后臺操作導致的抖動問題

兩份數(shù)據(jù)

為了保證可靠性和不丟數(shù)據(jù)(RPO=0)，有兩種不同的方案：一種方案是在硬件層面容錯，另一種方案是在軟件層面容錯。OceanBase選擇在軟件層面容錯，優(yōu)勢是硬件成本更低，帶來的問題是需要冗余存儲多個副本的數(shù)據(jù)。OceanBase使用Paxos協(xié)議保證在單機故障下數(shù)據(jù)的強一致。在Paxos協(xié)議中，一份數(shù)據(jù)需要被同步到多數(shù)派(超過一半)，才被認為是寫入成功，所以一般來說副本個數(shù)總是奇數(shù)，出于成本考慮最常見的部署規(guī)格是三副本。

三副本帶來的首要問題就是存儲成本的上升，之前商業(yè)數(shù)據(jù)庫的TPC-C測試大多基于磁盤陣列，而TPC-C規(guī)范中明確對磁盤陣列不做容災要求，使用相對于傳統(tǒng)數(shù)據(jù)庫三倍的存儲空間進行TPC-C測試顯然難以接受。

我們注意到這樣一個事實，通過Paxos協(xié)議同步的只是日志，日志需要寫三份，但數(shù)據(jù)不是，數(shù)據(jù)只需要有兩份就可以完成單機故障的容災了，當一份數(shù)據(jù)由于服務器宕機不可用時，另一份數(shù)據(jù)只要通過日志把數(shù)據(jù)補齊，就可以繼續(xù)對外提供訪問。

和數(shù)據(jù)存儲相比，日志的存儲量比較小。我們將數(shù)據(jù)與日志分開，定義了三種不同的副本類型：F副本既包含數(shù)據(jù)又同步日志，并對外提供讀寫服務;D副本既包含數(shù)據(jù)又同步日志，但對外不提供讀寫服務;L副本只同步日志，不存儲數(shù)據(jù)。當F副本出現(xiàn)故障時，D副本可以轉(zhuǎn)換為F副本，補齊數(shù)據(jù)后對外提供服務。在TPC-C測試中我們使用FDL模式進行部署(一個F副本，一個D副本，一個L副本)，使用了兩倍數(shù)據(jù)副本的存儲空間。無論是D副本還是L副本，都需要回放日志，D副本還需要同步數(shù)據(jù)，這些都是都會消耗網(wǎng)絡和CPU。

在線壓縮

在sharednothing架構(gòu)下，OceanBase至少需要存儲兩份數(shù)據(jù)才可以滿足容災的要求，這意味著OceanBase需要比傳統(tǒng)數(shù)據(jù)庫多耗費一倍的存儲空間。

為了緩解這個問題，OceanBaseTPC-C測試選擇對數(shù)據(jù)進行在線壓縮，Oracle數(shù)據(jù)庫中一個warehouse的存儲容量接近70MB，而OceanBase壓縮后存儲容量只有50MB左右，大幅降低了存儲空間。TPC-C規(guī)范要求磁盤空間能夠滿足60天數(shù)據(jù)量的存儲，對于OceanBase，由于需要保存兩份數(shù)據(jù)，雖然可靠性更好，但需要保存相當于120天的數(shù)據(jù)量，這些存儲成本都要計入總體價格。

OceanBase使用了204臺ECS i2云服務器存儲數(shù)據(jù)，服務器規(guī)格和線上真實業(yè)務應用保持一致。每臺服務器的日志盤1TB，數(shù)據(jù)盤接近13TB。計算兩份壓縮后的數(shù)據(jù)60天的存儲空間之后，服務器的數(shù)據(jù)盤基本沒有太多余量,從服務器的資源成本消耗來看，已經(jīng)達到了比較好的平衡。如果OceanBase的單機性能tpmC進一步提升，磁盤容量將成為瓶頸。OceanBase LSM引擎是append-only的，它的優(yōu)勢是沒有隨機修改，能夠在線壓縮。無論是TPC-C測試，還是最核心的OLTP生產(chǎn)系統(tǒng)(例如支付寶交易支付)，OceanBase都會打開在線壓縮，通過CPU換存儲空間。

存儲性能

平滑 TPC-C測試很大的挑戰(zhàn)在于在整個壓測過程中性能曲線要求是絕對平滑的，曲線上的波動幅度不能超過2%，這對于傳統(tǒng)數(shù)據(jù)庫來說都是一件困難的事情，因為這要求對于所有后臺任務的精細控制，不能由于某個后臺任務的資源過度使用導致前臺請求的阻塞積壓。而對于OceanBase而言，事情變得更為困難，因為OceanBase的存儲引擎是基于LSM Tree的，在LSM Tree要定期執(zhí)行compaction操作。Compaction是個非常重的后臺操作，會占用大量CPU和磁盤IO資源，這對前臺的用戶查詢和寫入天然就會造成影響。我們做了一些優(yōu)化，來平滑后臺任務對性能的影響，從最終的測試結(jié)果來看，性能曲線在整個8小時壓測過程中的抖動小于0.5%。

分層轉(zhuǎn)儲

在LSMTree中，數(shù)據(jù)首先被寫入內(nèi)存中的MemTable，在一定時候為了釋放內(nèi)存，MemTable中的數(shù)據(jù)需要與磁盤中的SSTable進行合并，這個過程被稱為compaction。在很多基于LSM Tree的存儲系統(tǒng)中，為了解決寫入的性能問題，通常會將SSTable分為多層，當一層的SSTable個數(shù)或者大小達到某個閾值時，合并入下一層SSTable。多層SSTable解決了寫入的問題，但是SSTable的個數(shù)過多，會極大拖慢查詢的性能。OceanBase同樣借鑒了分層的思路，但同時使用了更加靈活的compaction策略，確保SSTable總數(shù)不會太多，從而在讀取和寫入性能之間做了更好的平衡。

資源隔離

Compaction等后臺任務需要消耗大量的服務器資源，為了減少后臺任務對用戶查詢和寫入的影響，我們在CPU、內(nèi)存、磁盤IO和網(wǎng)絡IO四個方面對前后臺任務做了資源隔離。在CPU方面，我們將后臺任務和用戶請求分為不同的線程池，并按照CPU親和性做了隔離。在內(nèi)存方面，對前后臺請求做了不同的內(nèi)存管理。在磁盤IO方面，我們控制后臺任務IO請求的IOPS，使用deadline算法進行流控。在網(wǎng)絡IO方面，我們將后臺任務RPC和用戶請求RPC分為不同隊列，并對后臺任務RPC的帶寬使用進行流控。

存儲CPU占用 TPC-C基準測試主要考察整體性能tpmC，很多人也會關注單核的tpmC。然而，這個指標只有在相同架構(gòu)下才有意義。對于存儲模塊的CPU占用，有如下三點：

1. 對于集中式架構(gòu)，除了數(shù)據(jù)庫使用CPU之外，專用存儲設備也需要使用CPU。例如，第二名Oracle 3000多萬tpmC的測試中，數(shù)據(jù)庫使用了108顆T3SPARC處理器，共有1728個物理核心和13824個執(zhí)行線程，同時存儲設備使用的是Intel服務器作為機頭，總共使用了97臺服務器，194顆Intel X5670 CPU，2328個物理核心。

2. 集中式數(shù)據(jù)庫使用高可靠硬件，只需要存儲一個副本，而OceanBase通過軟件層面容錯，雖然硬件成本更低但需要兩個數(shù)據(jù)副本和三個日志副本，維護多個副本需要耗費大量CPU;

3. OceanBase在TPC-C測試和生產(chǎn)系統(tǒng)中都打開了在線壓縮，進一步增加了CPU使用; 因此，簡單地對比OceanBase和Oracle的CPU核是不科學的，還需要算上共享存儲設備的CPU核，以及OceanBase存儲多副本和在線壓縮帶來的CPU開銷。TPC-C推薦的方案是不關注具體的軟件架構(gòu)和硬件架構(gòu)，關注硬件總體成本。在OceanBase的測試中，硬件成本只占整體成本的18%左右，只考慮硬件的性價比大幅優(yōu)于集中式數(shù)據(jù)庫。

后續(xù)發(fā)展

OceanBase的優(yōu)勢在于采用分布式架構(gòu)，硬件成本更低，可用性更好且能夠做到線性擴展，但是，OceanBase單機的性能離Oracle、DB2還有不小的差距，后續(xù)需要重點優(yōu)化單機存儲性能。另外，OceanBase的定位是在同一套引擎同時支持OLTP業(yè)務和OLAP業(yè)務，而目前OceanBase的OLAP處理能力還不如Oracle，后續(xù)需要加強存儲模塊對大查詢的處理能力，支持將OLAP算子下壓到存儲層甚至在壓縮后的數(shù)據(jù)上直接做OLAP計算。

作者：陽振坤(OceanBase創(chuàng)始人)曹暉(OceanBase技術專家)陳萌萌(OceanBase資深技術專家)潘毅(OceanBase資深技術專家)韓富晟(OceanBase資深技術專家)趙裕眾(OceanBase高級技術專家)

【責任編輯：武曉燕 TEL：（010）68476606】