螞蟻金服自研數(shù)據(jù)庫 OceanBase 登頂 TPC-C 引起業(yè)內(nèi)廣泛關(guān)注，為了更清楚的展示其中的技術(shù)細(xì)節(jié)，我們特意邀請(qǐng) OceanBase 核心研發(fā)人員對(duì)本次測試進(jìn)行技術(shù)解讀，共包括五篇：

1）TPC-C基準(zhǔn)測試介紹
2）OceanBase如何做TPC-C測試
3）TPC-C基準(zhǔn)測試之SQL優(yōu)化
4）TPC-C基準(zhǔn)測試之?dāng)?shù)據(jù)庫事務(wù)引擎的挑戰(zhàn)
5）TPC-C基準(zhǔn)測試之存儲(chǔ)優(yōu)化

---

TPC-C 規(guī)范要求被測數(shù)據(jù)庫的性能（tpmC）與數(shù)據(jù)量成正比。TPC-C 的基本數(shù)據(jù)單元是倉庫（warehouse），每個(gè)倉庫的數(shù)據(jù)量通常在 70MB 左右（與具體實(shí)現(xiàn)有關(guān)）。TPC-C 規(guī)定每個(gè)倉庫所獲得的 tpmC 上限是 12.86（假設(shè)數(shù)據(jù)庫響應(yīng)時(shí)間為0）。假設(shè)某系統(tǒng)獲得 150萬 tpmC，大約對(duì)應(yīng) 12萬個(gè)倉庫，按照 70MB/倉庫計(jì)算，數(shù)據(jù)量約為 8.4TB。某些廠商采用修改過的不符合審計(jì)要求的 TPC-C 測試，不限制單個(gè) warehouse 的 tpmC 上限，測試幾百到幾千個(gè) warehouse 全部裝載到內(nèi)存的性能，這是沒有意義的，也不可能通過審計(jì)。在真實(shí)的 TPC-C 測試中，存儲(chǔ)的消耗占了很大一部分。OceanBase 作為第一款基于 shared nothing 架構(gòu)登上 TPC-C 榜首的數(shù)據(jù)庫，同時(shí)也作為第一款使用 LSM Tree 存儲(chǔ)引擎架構(gòu)登上 TPC-C 榜首的數(shù)據(jù)庫，在存儲(chǔ)架構(gòu)上有如下關(guān)鍵點(diǎn)：

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

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

OceanBase LSM 引擎定期需要在后臺(tái)做 compaction 操作，而 TPC-C 要求測試至少運(yùn)行 8 小時(shí)且 2 小時(shí)之內(nèi)抖動(dòng)小于 2%，因此，OceanBase 存儲(chǔ)需要解決 LSM 引擎后臺(tái)操作導(dǎo)致的抖動(dòng)問題；

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

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

三副本帶來的首要問題就是存儲(chǔ)成本的上升，之前商業(yè)數(shù)據(jù)庫的 TPC-C 測試大多基于磁盤陣列，而 TPC-C 規(guī)范中明確對(duì)磁盤陣列不做容災(zāi)要求，使用相對(duì)于傳統(tǒng)數(shù)據(jù)庫三倍的存儲(chǔ)空間進(jìn)行 TPC-C 測試顯然難以接受。我們注意到這樣一個(gè)事實(shí)，通過 Paxos 協(xié)議同步的只是日志，日志需要寫三份，但數(shù)據(jù)不是，數(shù)據(jù)只需要有兩份就可以完成單機(jī)故障的容災(zāi)了，當(dāng)一份數(shù)據(jù)由于服務(wù)器宕機(jī)不可用時(shí)，另一份數(shù)據(jù)只要通過日志把數(shù)據(jù)補(bǔ)齊，就可以繼續(xù)對(duì)外提供訪問。和數(shù)據(jù)存儲(chǔ)相比，日志的存儲(chǔ)量比較小。我們將數(shù)據(jù)與日志分開，定義了三種不同的副本類型：F 副本既包含數(shù)據(jù)又同步日志，并對(duì)外提供讀寫服務(wù)；D 副本既包含數(shù)據(jù)又同步日志，但對(duì)外不提供讀寫服務(wù)；L 副本只同步日志，不存儲(chǔ)數(shù)據(jù)。當(dāng) F 副本出現(xiàn)故障時(shí)，D 副本可以轉(zhuǎn)換為 F 副本，補(bǔ)齊數(shù)據(jù)后對(duì)外提供服務(wù)。在 TPC-C 測試中我們使用 FDL 模式進(jìn)行部署（一個(gè) F 副本，一個(gè) D 副本，一個(gè) L 副本），使用了兩倍數(shù)據(jù)副本的存儲(chǔ)空間。無論是 D 副本還是 L 副本，都需要回放日志，D 副本還需要同步數(shù)據(jù)，這些都是都會(huì)消耗網(wǎng)絡(luò)和 CPU。

在線壓縮

在 shared nothing 架構(gòu)下，OceanBase 至少需要存儲(chǔ)兩份數(shù)據(jù)才可以滿足容災(zāi)的要求，這意味著 OceanBase 需要比傳統(tǒng)數(shù)據(jù)庫多耗費(fèi)一倍的存儲(chǔ)空間。為了緩解這個(gè)問題，OceanBase TPC-C 測試選擇對(duì)數(shù)據(jù)進(jìn)行在線壓縮，Oracle 數(shù)據(jù)庫中一個(gè) warehouse 的存儲(chǔ)容量接近 70MB，而 OceanBase 壓縮后存儲(chǔ)容量只有 50MB 左右，大幅降低了存儲(chǔ)空間。TPC-C 規(guī)范要求磁盤空間能夠滿足 60 天數(shù)據(jù)量的存儲(chǔ)，對(duì)于 OceanBase，由于需要保存兩份數(shù)據(jù)，雖然可靠性更好，但需要保存相當(dāng)于 120 天的數(shù)據(jù)量，這些存儲(chǔ)成本都要計(jì)入總體價(jià)格。OceanBase 使用了 204 臺(tái) ECS i2 云服務(wù)器存儲(chǔ)數(shù)據(jù)，服務(wù)器規(guī)格和線上真實(shí)業(yè)務(wù)應(yīng)用保持一致。每臺(tái)服務(wù)器的日志盤 1TB，數(shù)據(jù)盤接近 13TB。計(jì)算兩份壓縮后的數(shù)據(jù) 60 天的存儲(chǔ)空間之后，服務(wù)器的數(shù)據(jù)盤基本沒有太多余量,從服務(wù)器的資源成本消耗來看，已經(jīng)達(dá)到了比較好的平衡。如果 OceanBase 的單機(jī)性能 tpmC 進(jìn)一步提升，磁盤容量將成為瓶頸。OceanBase LSM 引擎是 append-only 的，它的優(yōu)勢是沒有隨機(jī)修改，能夠在線壓縮。無論是 TPC-C 測試，還是最核心的 OLTP 生產(chǎn)系統(tǒng)（例如支付寶交易支付），OceanBase 都會(huì)打開在線壓縮，通過 CPU 換存儲(chǔ)空間。

存儲(chǔ)性能平滑

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

分層轉(zhuǎn)儲(chǔ)

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

資源隔離

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

存儲(chǔ)CPU占用

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

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

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

OceanBase 在 TPC-C 測試和生產(chǎn)系統(tǒng)中都打開了在線壓縮，進(jìn)一步增加了 CPU 使用；

因此，簡單地對(duì)比OceanBase和Oracle的CPU核是不科學(xué)的，還需要算上共享存儲(chǔ)設(shè)備的CPU核，以及OceanBase存儲(chǔ)多副本和在線壓縮帶來的CPU開銷。TPC-C推薦的方案是不關(guān)注具體的軟件架構(gòu)和硬件架構(gòu)，關(guān)注硬件總體成本。在OceanBase的測試中，硬件成本只占整體成本的18%左右，只考慮硬件的性價(jià)比大幅優(yōu)于集中式數(shù)據(jù)庫。

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

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

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的蚂蚁金服OceanBase挑战TPCC | TPC-C基准测试之存储优化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。