螞蟻金服自研資料庫 OceanBase 登頂 TPC-C 引起業內廣泛關注，為了更清楚的展示其中的技術細節，我們特意邀請 OceanBase 核心研發人員對本次測試進行技術解讀，共包括五篇：
1）TPC-C基準測試介紹
2）OceanBase如何做TPC-C測試
3）TPC-C基準測試之SQL優化
4）TPC-C基準測試之資料庫事務引擎的挑戰
5）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。
線上壓縮在 shared nothing 架構下，OceanBase 至少需要儲存兩份資料才可以滿足容災的要求，這意味著 OceanBase 需要比傳統資料庫多耗費一倍的儲存空間。為了緩解這個問題，OceanBase TPC-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%。
分層轉儲
在 LSM Tree 中，資料首先被寫入記憶體中的 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 顆 T3 SPARC 處理器，共有 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計算。