數據庫

农药波尔多液的主要成分:TPC-C解析系列02_OceanBase如何做TPC-C測試

廣告
廣告

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

TPC-C解析系列02_OceanBase如何做TPC-C測試
0 0

導語:

螞蟻金服自研數據庫OceanBase登頂TPC-C引起業內廣泛關注,為了更清楚的展示其中的技術細節,我們特意邀請OceanBase核心研發人員對本次測試進行技術解讀,共包括五篇:

1)TPC-C基準測試介紹
2)OceanBase如何做TPC-C測試
3)TPC-C基準測試之SQL優化
4)TPC-C基準測試之數據庫事務引擎的挑戰
5)TPC-C基準測試之存儲優化

本文為第二篇,其它文章已同步發布,詳情請在“螞蟻金服科技”公眾號查看。

正文:

眾所周知,TPC組織是當今國際數據庫領域公認最權威的測試和評價組織,它成立的初衷就是構建最好的測試標準以及制定針對這些標準最優的審計和監測流程。數據庫界的天皇巨星Jim Gray曾在1985年提出了針對事務處理能力的評價標準DebitCredit,而1988年TPC組織成立伊始,就基于這個標準提出了TPC組織第一個針對OLTP應用的測試標準TPC-A。但隨著時代發展,TPC-A已經慢慢無法完全體現真實應用場景,此時TPC-C肩負重任應運而生,接下來也一直是TPC組織最核心同時也是關系數據庫領域最頂級的測試標準。TPC-C標準比TPC-A更加復雜,壓力負載模型是16位一線工業產業界學者一起參與制定,隨著時間推移測試標準也一直在保持修訂,所以其模擬大型在線商超的測試模型時至今日也仍不過時,越來越能找到和當前大型B2C電商網站的共通之處。

有機會挑戰TPC-C測試相信是所有數據庫內核開發人員的夢想,但TPC-C測試標準非常復雜,1992年7月發布以來到現在已經是v5.11.0版本,僅PDF就132頁,如果不是鐵桿粉絲估計很少有人會認真通讀完這個標準。這次OceanBase創造TPC-C記錄引起了大家的廣泛關注,但它也只是這個測試標準里體現跑分的一個評價項MQTh(最大有效吞吐量),隱藏在跑分下面的是TPC-C標準對被測數據庫無數細致入微的測試驗證和評價項,而正是這些才讓這個標準在關系數據庫領域如此權威,同時也是國產數據庫之前很難入場的一大原因。

由于這是國產數據庫同時也是分布式數據庫第一次沖擊這個榜單,為了完成這次挑戰,OceanBase團隊前后準備時間超過一年,僅審計認證過程就耗時約半年,除了數據庫自身性能優化同時還有大量的穩定性、合規要求相關工作,6088w tpmC其實也只是整個測試結果中一小個展示項而已。

前期準備

作為基于LSM-Tree、多副本paxos強一致的新型分布式關系數據庫,如何進行TPC-C測試,有哪些注意事項,什么時候該做什么步驟等等諸多問題,在審計剛啟動時我們無處咨詢也沒有任何可借鑒的資料。TPC-C測試首先需要找到官方唯一認證的審計員來對測試進行審計監察,但面對OceanBase這樣一個全新架構的關系數據庫時,他們其實也有著諸多和我們類似的疑惑和問題,因此他們對這次OceanBase的審計也相當重視,全世界僅有的三個審計員這次就有兩個參與到測試審計工作中。

兩位審計員其中一位還是TPC-C標準原作者之一,他們對整個測試流程的要求異常細致和嚴苛,起初對待OceanBase還持有很大的懷疑態度,和審計員們漫長的郵件以及現場溝通過程也異常艱辛,但這也幫助我們始終堅持用規范中最嚴格的標準來針對每個測試子項,最終也贏得了審計員們充分的信任,審計員甚至在理解了OceanBase架構后幫助我們提出了多個問題解決思路。另外通過這次測試,OceanBase也給TPC-C標準帶來了很多新鮮的概念和測試方案

  • 如何在OceanBase特有的Incremental數據帶上后續的Major Compaction機制下去做數據存儲的審計
  • 如何在全部使用云服務器的測試系統中進行Durability測試
  • 分布式數據庫在性能壓測等測試中應當如何去評估和監控checkpoint

測試系統

目前市面上基本找不到一個能夠開箱即用的符合TPC-C標準的測試工具。以目前各個廠商PoC環境最常遇到的benchmarksql為例,可以說只是模擬TPC-C壓力模型的壓測工具,連最基本的數據導入都不合規,大量的字符串生成未保證全局隨機,缺乏壓測階段最基本的think time、keying time這些基本配置導致極小的數據量就能跑出很高的tpmC,最關鍵的是它將測試模型大大簡化為工具直連DB測試,完全沒有遵守TPC-C測試標準規范。

在標準定義中,測試系統可以分為RTE(Remote Terminal Emulator)和SUT兩部分,但實際上從角色上看SUT可以進一步拆分為兩部分:WAS(web application server)和DB Server。這其中DB Server是每個測試廠商的數據庫服務;RTE扮演的角色是測試模型中的客戶終端,事務的觸發、RT的統計等都在這里完成;標準明確要求每一個用戶terminal都必須保持一個長連接,顯然在海量Warehouse時DB是無法承受這么多連接的,WAS就是RTE和DB之間橋梁,標準定義可以使用連接池,在保證對應用透明的情況下它可以做所有請求的管理。

這三個角色中,WAS和DB是必須商業化可購買且提供支付服務的,OceanBase這次是使用了OpenResty作為WAS供應商。而RTE則一般有各個參測廠商自行根據標準實現,但所有實現代碼必須經過審計的嚴格審計,OceanBase這次完整的實現了一整套完全合規的RTE,并且支持在大規模測試系統中部署。要知道在實際的TPC-C測試流程中,不只是對DB端能力的考驗,RTE端同樣存在極大的資源消耗和壓力。以這次6088w tpmC測試結果看,我們一共在64臺64c128G的云服務器上運行了960個RTE客戶端,來模擬總計47942400個用戶terminal,最后還需要基于這么多RTE統計結果進行一致性和持久化審計驗證。

雖然只是測試客戶端,但RTE的中同樣有大量的可能導致最后測試失敗的小細節,比如大家可能注意不到的所有事務都因為用了web端模擬終端后需要增加的100毫秒rt,又比如為了模擬用戶終端輸出顯示的100毫秒延時。

測試規劃

TPC-C從來都不是一個簡單的測試,它很科學并沒有給出強制的軟硬件配置,只是給出測試規范和各種審計檢查限制標準,所有數據庫廠商可以根據自己的特性充分調優來拿到一個最好的性能或性價比。但這同時也對所有參測廠商提出了一個巨大的難題,如何對已有的資源進行合理規劃來保證順利完成一次對TPC-C榜單的沖擊。

  1. 硬件選型,這里不僅要對數據庫服務器選型,還需要對RTE以及WAS服務器選型。這之前需要先期進行大量的測試和調優,來摸出在保證性價比的前提下每個角色服務器的資源配置是多少剛好。這次OceanBase測試最大的優勢就是全部使用了云化資源,我們不需要再關注最底層機房、機柜、布線這些細節,只需要通過快速的規格調整來拿到我們需要的機型。
  2. 參數選擇,如何選擇合適的配置參數是一個非常令人頭疼的問題。舉個例子,一個最典型的問題就是我們最終要跑多少個Warehouse,每個數據庫服務器上承載多少Warehouse。TPC-C標準為了盡可能模擬真實業務場景,通過每個事務限定不同的think time和keying time保證了一個warehouse的數據最多能夠提供12.86tpmC值,因此數據庫廠商想要拿到更高的成績就必須裝載更多的warehouse,但是另一方面單機的存儲空間又有預計80%(經驗值)需要預留給60天增量存儲。在分布式數據庫架構下,為了能讓每個數據庫服務器跑滿又能充分利用本地存儲空間,讓每個服務器的CPU、內存、IO能力、存儲空間的資源最大化利用,我們前后調整優化了近一個月時間。

性能壓測

最受關注的性能壓測部分在TPC-C標準中規定了以下三個狀態:

  1. Ramp-up,標準允許每個數據庫進行一定時間的預熱來達到穩定狀態,但是ramp-up階段的所有配置必須和最終報告配置保持一致。
  2. Steady state,保證ACID及可串行化隔離級別前提下,數據庫需要能夠以最終報告tpmC值在穩定狀態無任何人工干預前提下保持運行8小時以上,每隔半小時需要完成一次checkpoint
  3. Measurement Interval,標準規定了需要能夠支持8小時穩定運行,但性能采集階段只需要保設置2小時以上即可。這個階段還需要保證累計tpmC波動不能超過2%,并且必須完成至少4個以上的checkpoint。

所以之前一般數據庫進行性能壓測一般是以下的流程,先進行一段時間的預熱到達穩態,等待穩定運行一段時間并完成一個checkpoint后開始進入2小時的性能采集階段。

而OceanBase這次是使用了TPC-C測試迄今以來最嚴苛的一個流程來完成這個性能測試的,我們首先使用了10分鐘進行預熱,然后在6088w tpmC穩態保持運行25分鐘并完成一個檢查點,再繼續跑了完整的8小時性能壓測采集階段,總耗時超過8個半小時,中間性能最大波動不到0.5%,最終結果也讓審計員異常興奮。

整個性能測試前后,審計員還需要進行數據及事務隨機分布檢查,簡單說來就是大量全表掃描和統計sql,最大的一條sql需要訪問超過萬億行的order_line表結果,可以算是TPC-C里的“TPC-H測試”。現場審計第一次遇到這些sql時我們也大量的出現sql執行超時情況,但后續基于OceanBase2.2版本最新的并行執行框架我們還是很快搞定了這些大sql,所以要順利完成TPC-C測試并不能只是一個偏科生,保持自身沒有短板才是真正意義上的通用關系數據庫,從這點上說Oracle仍是OceanBase學習的榜樣。

ACID

  1. A測試,通過提交和回滾payment事務來確認數據庫對原子性支持,和I測試一樣,OceanBase的A測試跑了兩遍,分別應對分布式事務和本地事務。
  2. C測試,標準里的C測試一共包含12個case,前四個是必須要完成驗證的,每個case其實都可以認為是一個復雜的大sql,而對于分布式數據庫來說重點是需要始終保證全局一致。
  3. I測試,標準要求TPC-C模型里5個事務除了StockLevel事務都需要滿足最高的可串行化隔離級別,并構造了9個case來驗證隔離性。對于分布式數據庫而言,這個要求并沒有那么容易實現,所幸OceanBase在2.x版本中提供了全局時間戳的支持,所以的I測試都在審計員的特別要求下跑完了全本地和全分布式兩種模式的兩輪測試,這也應該是TPC-C測試中首次有數據庫廠商需要做兩輪I測試跑18個case的,也許在不久后TPC-C標準定義也會因為OceanBase的這次測試而帶來針對分布式數據庫的相關更新
  4. D測試,OceanBase在這個場景其實相對傳統數據庫是有較大天生優勢的,OceanBase每個Warehouse數據有兩份數據三份日志,通過paxos強同步,保證RPO=0的前提下只有秒級RTO。面對D測試標準中最嚴格的一項-部分存儲介質永久故障,OceanBase還使用了最嚴苛的測試場景,在使用超出標準要求的全量6000W tpmC壓力下,我們強行銷毀了一個云服務器節點,整體tpmC在兩分鐘內恢復到6000w并持續跑到測試時間結束,這些表現都是遠遠超過TPC-C規范要求的,相比較而言其它傳統數據庫基本面對有日志的存儲介質故障D測試場景都是依賴磁盤RAID來恢復,OceanBase應該算是首個沒有raid完全依賴數據庫自身恢復機制完成全部D測試的數據庫廠商了。同時我們再D測試中是連續殺掉了兩臺服務器節點,首先殺掉一個數據節點,等待tpmC恢復且穩定5分鐘后,再次殺掉了rootserver leader節點,tpmC仍然快速恢復。

作者介紹:

曹暉,現任螞蟻金服OceanBase團隊技術專家,2017年加入OceanBase團隊,現從事存儲引擎開發工作

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

TPC-C解析系列01_TPC-C benchmark測試介紹

上一篇

TPC-C解析系列03_TPC-C基準測試之SQL優化

下一篇

你也可能喜歡

TPC-C解析系列02_OceanBase如何做TPC-C測試

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

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


微信掃一掃

微信掃一掃