螞蟻金服自研數據庫 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計算。
作者介紹
趙裕衆，現任螞蟻金服 OceanBase 團隊高級技術專家，2010 年加入支付寶後從事分佈式事務框架的研發，2013 年加入 OceanBase 團隊，目前負責存儲引擎相關的研發工作。