螞蟻金服OceanBase挑戰TPCC | TPC-C基準測試之存儲優化

螞蟻金服自研數據庫 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 榜首的數據庫，在存儲架構上有以下關鍵點：

1. 爲了保證可靠性，OceanBase 存儲了兩個數據副本和三個日誌副本，而傳統的集中式數據庫測試 TPC-C 只存儲一份數據；
2. 因爲 OceanBase 存儲兩個數據副本，再加上 OceanBase TPC-C 測試採用了和生產系統徹底同樣的阿里雲服務器 i2 機型，SSD 硬盤的存儲容量成爲瓶頸。OceanBase 採用在線壓縮的方式緩解這個問題，進一步增長了 CPU 使用；相應地，集中式數據庫測試存儲一份數據，不須要打開壓縮；
3. 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 佔用，有以下三點：

1. 對於集中式架構，除了數據庫使用 CPU 以外，專用存儲設備也須要使用 CPU。例如，第二名 Oracle 3000多萬 tpmC 的測試中，數據庫使用了 108 顆 T3 SPARC 處理器，共有 1728 個物理核心和 13824 個執行線程，同時存儲設備使用的是 Intel 服務器做爲機頭，總共使用了 97 臺服務器，194 顆 Intel X5670 CPU，2328 個物理核心；
2. 集中式數據庫使用高可靠硬件，只須要存儲一個副本，而 OceanBase 經過軟件層面容錯，雖然硬件成本更低但須要兩個數據副本和三個日誌副本，維護多個副本須要耗費大量 CPU；
3. 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 團隊，目前負責存儲引擎相關的研發工做。

 

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。