數據庫

波尔多液最佳配置法:TPC-C解析系列05_TPC-C基準測試之存儲優化

廣告
廣告

微信掃一掃,分享到朋友圈

TPC-C解析系列05_TPC-C基準測試之存儲優化
0 0

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的存儲系統中,為了解決寫入的性能問題,通?;嶠玈STable分為多層,當一層的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。然而,這個指標只有在相同架構下才有意義。對于存儲??櫚腃PU占用,有如下三點:

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

我還沒有學會寫個人說明!

TPC-C解析系列04_TPC-C基準測試之數據庫事務引擎的挑戰

上一篇

滴滴從KV存儲到NewSQL實戰

下一篇

你也可能喜歡

TPC-C解析系列05_TPC-C基準測試之存儲優化

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃