螞蟻金服自研數據庫 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 臺服務器，97顆 Intel X5670 CPU，583 個物理核心；

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 團隊，目前負責存儲引擎相關的研發工作。

>>>>

歡迎查看以下?OceanBase 創始人陽振坤采訪視頻，了解國產自研分布式數據庫這十年的歷程：

總結

以上是生活随笔為你收集整理的db2 删除存储过程_蚂蚁金服OceanBase挑战TPCC | TPCC基准测试之存储优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。