OceanBase如何獲得TPC-C測(cè)試第1名？
TPC-C是TPC組織(國際事務(wù)性能委員會(huì))制定的關(guān)于商品銷售的訂單創(chuàng)建和訂單支付等的基準(zhǔn)測(cè)試標(biāo)準(zhǔn)，是數(shù)據(jù)庫聯(lián)機(jī)交易處理系統(tǒng)的權(quán)威基準(zhǔn)測(cè)試標(biāo)準(zhǔn)。
螞蟻金服自研的分布式關(guān)系數(shù)據(jù)庫OceanBase獲得TPC-C測(cè)試第一名后，引起了大量關(guān)注，今天，我們邀請(qǐng)了OceanBase的核心研發(fā)人員對(duì)本次測(cè)試做專業(yè)的技術(shù)解讀。
一、OceanBase如何做TPC-C測(cè)試
有機(jī)會(huì)挑戰(zhàn)TPC-C測(cè)試相信是所有數(shù)據(jù)庫內(nèi)核開發(fā)人員的夢(mèng)想，但TPC-C測(cè)試標(biāo)準(zhǔn)非常復(fù)雜。由于這是國產(chǎn)數(shù)據(jù)庫同時(shí)也是分布式數(shù)據(jù)庫第一次沖擊這個(gè)榜單，為了完成這次挑戰(zhàn)，OceanBase團(tuán)隊(duì)前后準(zhǔn)備時(shí)間超過一年。
前期準(zhǔn)備
TPC-C測(cè)試首先需要找到官方唯一認(rèn)證的審計(jì)員來對(duì)測(cè)試進(jìn)行審計(jì)監(jiān)察，他們對(duì)這次OceanBase的審計(jì)也相當(dāng)重視，全世界僅有的三個(gè)審計(jì)員這次就有兩個(gè)參與到測(cè)試審計(jì)工作中。
測(cè)試系統(tǒng)
目前市面上基本找不到一個(gè)能夠開箱即用的符合TPC-C標(biāo)準(zhǔn)的測(cè)試工具。以目前各個(gè)廠商PoC環(huán)境最常遇到的benchmarksql為例，可以說只是模擬TPC-C壓力模型的壓測(cè)工具，連最基本的數(shù)據(jù)導(dǎo)入都不合規(guī)，大量的字符串生成未保證全局隨機(jī)，缺乏壓測(cè)階段最基本的think time、keying time這些基本配置導(dǎo)致極小的數(shù)據(jù)量就能跑出很高的tpmC，最關(guān)鍵的是它將測(cè)試模型大大簡化為工具直連DB測(cè)試，完全沒有遵守TPC-C測(cè)試標(biāo)準(zhǔn)規(guī)范。
在標(biāo)準(zhǔn)定義中，測(cè)試系統(tǒng)可以分為RTE(Remote Terminal Emulator)和SUT兩部分，但實(shí)際上從角色上看SUT可以進(jìn)一步拆分為兩部分：WAS(web application server)和DB Server。
這其中DB Server是每個(gè)測(cè)試廠商的數(shù)據(jù)庫服務(wù);RTE扮演的角色是測(cè)試模型中的客戶終端，事務(wù)的觸發(fā)、RT的統(tǒng)計(jì)等都在這里完成;標(biāo)準(zhǔn)明確要求每一個(gè)用戶terminal都必須保持一個(gè)長連接，顯然在海量Warehouse時(shí)DB是無法承受這么多連接的，WAS就是RTE和DB之間橋梁，標(biāo)準(zhǔn)定義可以使用連接池，在保證對(duì)應(yīng)用透明的情況下它可以做所有請(qǐng)求的管理。
這三個(gè)角色中，WAS和DB是必須商業(yè)化可購買且提供支付服務(wù)的，OceanBase這次是使用了OpenResty作為WAS供應(yīng)商。而RTE則一般由各個(gè)參測(cè)廠商自行根據(jù)標(biāo)準(zhǔn)實(shí)現(xiàn)，但所有實(shí)現(xiàn)代碼必須經(jīng)過審計(jì)的嚴(yán)格審計(jì)，OceanBase這次完整的實(shí)現(xiàn)了一整套完全合規(guī)的RTE，并且支持在大規(guī)模測(cè)試系統(tǒng)中部署。要知道在實(shí)際的TPC-C測(cè)試流程中，不只是對(duì)DB端能力的考驗(yàn)，RTE端同樣存在極大的資源消耗和壓力。以這次6088w tpmC測(cè)試結(jié)果看，我們一共在64臺(tái)64c128G的云服務(wù)器上運(yùn)行了960個(gè)RTE客戶端，來模擬總計(jì)47942400個(gè)用戶terminal，最后還需要基于這么多RTE統(tǒng)計(jì)結(jié)果進(jìn)行一致性和持久化審計(jì)驗(yàn)證。
雖然只是測(cè)試客戶端，但RTE的中同樣有大量的可能導(dǎo)致最后測(cè)試失敗的小細(xì)節(jié)，比如大家可能注意不到的所有事務(wù)都因?yàn)橛昧藈eb端模擬終端后需要增加的100毫秒rt，又比如為了模擬用戶終端輸出顯示的100毫秒延時(shí)。
測(cè)試規(guī)劃
TPC-C從來都不是一個(gè)簡單的測(cè)試，它很科學(xué)并沒有給出強(qiáng)制的軟硬件配置，只是給出測(cè)試規(guī)范和各種審計(jì)檢查限制標(biāo)準(zhǔn)，所有數(shù)據(jù)庫廠商可以根據(jù)自己的特性充分調(diào)優(yōu)來拿到一個(gè)最好的性能或性價(jià)比。但這同時(shí)也對(duì)所有參測(cè)廠商提出了一個(gè)巨大的難題，如何對(duì)已有的資源進(jìn)行合理規(guī)劃來保證順利完成一次對(duì)TPC-C榜單的沖擊。
1. 硬件選型，這里不僅要對(duì)數(shù)據(jù)庫服務(wù)器選型，還需要對(duì)RTE以及WAS服務(wù)器選型。這之前需要先期進(jìn)行大量的測(cè)試和調(diào)優(yōu)，來摸出在保證性價(jià)比的前提下每個(gè)角色服務(wù)器的資源配置是多少剛好。這次OceanBase測(cè)試最大的優(yōu)勢(shì)就是全部使用了云化資源，我們不需要再關(guān)注最底層機(jī)房、機(jī)柜、布線這些細(xì)節(jié)，只需要通過快速的規(guī)格調(diào)整來拿到我們需要的機(jī)型。
2. 參數(shù)選擇，如何選擇合適的配置參數(shù)是一個(gè)非常令人頭疼的問題。舉個(gè)例子，一個(gè)最典型的問題就是我們最終要跑多少個(gè)Warehouse，每個(gè)數(shù)據(jù)庫服務(wù)器上承載多少Warehouse。TPC-C標(biāo)準(zhǔn)為了盡可能模擬真實(shí)業(yè)務(wù)場(chǎng)景，通過每個(gè)事務(wù)限定不同的think time和keying time保證了一個(gè)warehouse的數(shù)據(jù)最多能夠提供12.86tpmC值，因此數(shù)據(jù)庫廠商想要拿到更高的成績就必須裝載更多的warehouse，但是另一方面單機(jī)的存儲(chǔ)空間又有預(yù)計(jì)80%(經(jīng)驗(yàn)值)需要預(yù)留給60天增量存儲(chǔ)。在分布式數(shù)據(jù)庫架構(gòu)下，為了能讓每個(gè)數(shù)據(jù)庫服務(wù)器跑滿又能充分利用本地存儲(chǔ)空間，讓每個(gè)服務(wù)器的CPU、內(nèi)存、IO能力、存儲(chǔ)空間的資源最大化利用，我們前后調(diào)整優(yōu)化了近一個(gè)月時(shí)間。
性能壓測(cè)
最受關(guān)注的性能壓測(cè)部分在TPC-C標(biāo)準(zhǔn)中規(guī)定了以下三個(gè)狀態(tài)：
1. Ramp-up，標(biāo)準(zhǔn)允許每個(gè)數(shù)據(jù)庫進(jìn)行一定時(shí)間的預(yù)熱來達(dá)到穩(wěn)定狀態(tài)，但是ramp-up階段的所有配置必須和最終報(bào)告配置保持一致。
2. Steady state，保證ACID及可串行化隔離級(jí)別前提下，數(shù)據(jù)庫需要能夠以最終報(bào)告tpmC值在穩(wěn)定狀態(tài)無任何人工干預(yù)前提下保持運(yùn)行8小時(shí)以上，每隔半小時(shí)需要完成一次checkpoint。
3. Measurement Interval，標(biāo)準(zhǔn)規(guī)定了需要能夠支持8小時(shí)穩(wěn)定運(yùn)行，但性能采集階段只需要保設(shè)置2小時(shí)以上即可。這個(gè)階段還需要保證累計(jì)tpmC波動(dòng)不能超過2%，并且必須完成至少4個(gè)以上的checkpoint。
所以之前一般數(shù)據(jù)庫進(jìn)行性能壓測(cè)一般是以下的流程，先進(jìn)行一段時(shí)間的預(yù)熱到達(dá)穩(wěn)態(tài)，等待穩(wěn)定運(yùn)行一段時(shí)間并完成一個(gè)checkpoint后開始進(jìn)入2小時(shí)的性能采集階段。
而OceanBase這次是使用了TPC-C測(cè)試迄今以來最嚴(yán)苛的一個(gè)流程來完成這個(gè)性能測(cè)試的，我們首先使用了10分鐘進(jìn)行預(yù)熱，然后在6088w tpmC穩(wěn)態(tài)保持運(yùn)行25分鐘并完成一個(gè)檢查點(diǎn)，再繼續(xù)跑了完整的8小時(shí)性能壓測(cè)采集階段，總耗時(shí)超過8個(gè)半小時(shí)，中間性能最大波動(dòng)不到0.5%，最終結(jié)果也讓審計(jì)員異常興奮。
整個(gè)性能測(cè)試前后，審計(jì)員還需要進(jìn)行數(shù)據(jù)及事務(wù)隨機(jī)分布檢查，簡單說來就是大量全表掃描和統(tǒng)計(jì)sql，最大的一條sql需要訪問超過萬億行的order_line表結(jié)果，可以算是TPC-C里的“TPC-H測(cè)試”。現(xiàn)場(chǎng)審計(jì)第一次遇到這些sql時(shí)我們也大量的出現(xiàn)sql執(zhí)行超時(shí)情況，但后續(xù)基于OceanBase2.2版本最新的并行執(zhí)行框架我們還是很快搞定了這些大sql，所以要順利完成TPC-C測(cè)試并不能只是一個(gè)偏科生，保持自身沒有短板才是真正意義上的通用關(guān)系數(shù)據(jù)庫，從這點(diǎn)上說Oracle仍是OceanBase學(xué)習(xí)的榜樣。
ACID
1. A測(cè)試，通過提交和回滾payment事務(wù)來確認(rèn)數(shù)據(jù)庫對(duì)原子性支持，和I測(cè)試一樣，OceanBase的A測(cè)試跑了兩遍，分別應(yīng)對(duì)分布式事務(wù)和本地事務(wù)。
2. C測(cè)試，標(biāo)準(zhǔn)里的C測(cè)試一共包含12個(gè)case，前四個(gè)是必須要完成驗(yàn)證的，每個(gè)case其實(shí)都可以認(rèn)為是一個(gè)復(fù)雜的大sql，而對(duì)于分布式數(shù)據(jù)庫來說重點(diǎn)是需要始終保證全局一致。
3. I測(cè)試，標(biāo)準(zhǔn)要求TPC-C模型里5個(gè)事務(wù)除了StockLevel事務(wù)都需要滿足最高的可串行化隔離級(jí)別，并構(gòu)造了9個(gè)case來驗(yàn)證隔離性。對(duì)于分布式數(shù)據(jù)庫而言，這個(gè)要求并沒有那么容易實(shí)現(xiàn)，所幸OceanBase在2.x版本中提供了全局時(shí)間戳的支持，所以的I測(cè)試都在審計(jì)員的特別要求下跑完了全本地和全分布式兩種模式的兩輪測(cè)試，這也應(yīng)該是TPC-C測(cè)試中首次有數(shù)據(jù)庫廠商需要做兩輪I測(cè)試跑18個(gè)case的，也許在不久后TPC-C標(biāo)準(zhǔn)定義也會(huì)因?yàn)镺ceanBase的這次測(cè)試而帶來針對(duì)分布式數(shù)據(jù)庫的相關(guān)更新。
4. D測(cè)試，OceanBase在這個(gè)場(chǎng)景其實(shí)相對(duì)傳統(tǒng)數(shù)據(jù)庫是有較大天生優(yōu)勢(shì)的，OceanBase每個(gè)Warehouse數(shù)據(jù)有兩份數(shù)據(jù)三份日志，通過paxos強(qiáng)同步，保證RPO=0的前提下只有秒級(jí)RTO。
面對(duì)D測(cè)試標(biāo)準(zhǔn)中最嚴(yán)格的一項(xiàng)-部分存儲(chǔ)介質(zhì)永久故障，OceanBase還使用了最嚴(yán)苛的測(cè)試場(chǎng)景，在使用超出標(biāo)準(zhǔn)要求的全量6000W tpmC壓力下，我們強(qiáng)行銷毀了一個(gè)云服務(wù)器節(jié)點(diǎn)，整體tpmC在兩分鐘內(nèi)恢復(fù)到6000w并持續(xù)跑到測(cè)試時(shí)間結(jié)束，這些表現(xiàn)都是遠(yuǎn)遠(yuǎn)超過TPC-C規(guī)范要求的，相比較而言其它傳統(tǒng)數(shù)據(jù)庫基本面對(duì)有日志的存儲(chǔ)介質(zhì)故障D測(cè)試場(chǎng)景都是依賴磁盤RAID來恢復(fù)，OceanBase應(yīng)該算是首個(gè)沒有raid完全依賴數(shù)據(jù)庫自身恢復(fù)機(jī)制完成全部D測(cè)試的數(shù)據(jù)庫廠商了。
同時(shí)我們?cè)贒測(cè)試中是連續(xù)殺掉了兩臺(tái)服務(wù)器節(jié)點(diǎn)，首先殺掉一個(gè)數(shù)據(jù)節(jié)點(diǎn)，等待tpmC恢復(fù)且穩(wěn)定5分鐘后，再次殺掉了rootserver leader節(jié)點(diǎn)，tpmC仍然快速恢復(fù)。
二、TPC-C基準(zhǔn)測(cè)試之SQL優(yōu)化
對(duì)TPC-C有所了解人都知道，TPC-C是一個(gè)典型的OLTP (On-Line Transaction Processing) 場(chǎng)景測(cè)試，考察的是數(shù)據(jù)庫在高并發(fā)壓力場(chǎng)景下的事務(wù)處理能力，最終的性能指標(biāo)以tpmC(transaction per minute，也即每分鐘系統(tǒng)處理TPC-C模型中的new order事務(wù)的數(shù)量)和平均到每tpmC的系統(tǒng)成本作為衡量標(biāo)準(zhǔn)。在OLTP場(chǎng)景中，每條請(qǐng)求的響應(yīng)時(shí)間都是極短的。因此，各個(gè)數(shù)據(jù)庫廠商在進(jìn)行TPC-C測(cè)試時(shí)，都會(huì)盡一切可能將每一個(gè)操作時(shí)間壓縮到最短，不夸張的說，在TPC-C的測(cè)試中，一些關(guān)鍵操作的優(yōu)化往往需要細(xì)化到CPU指令級(jí)。
在進(jìn)入我們的主題前，我們先來談?wù)凾PC-C中的事務(wù)模型，主要分為五種事務(wù)，訂單創(chuàng)建、訂單支付、訂單查詢、訂單發(fā)貨以及庫存查詢，這五種事務(wù)按照一定的比例發(fā)生，測(cè)試最終衡量的是每分鐘訂單創(chuàng)建事務(wù)的執(zhí)行個(gè)數(shù)。大家知道，每一個(gè)數(shù)據(jù)庫的事務(wù)，其實(shí)就是由一定邏輯關(guān)系關(guān)聯(lián)的若干條SQL語句組成，他們?cè)谝粋€(gè)事務(wù)中，要么全部成功，要么全部失敗，這個(gè)在數(shù)據(jù)庫中稱為“原子性”，也就是ACID中的“A”。那么TPC-C中的一個(gè)事務(wù)的耗時(shí)大約是多久呢?看一下報(bào)告就很清楚了——只有十幾個(gè)毫秒。考慮到一個(gè)事務(wù)由多條SQL構(gòu)成，那么每一條SQL的平均耗時(shí)都不到1毫秒!
在C/S(client-server)模型中，一條SQL語句從發(fā)起到執(zhí)行完成需要經(jīng)歷從客戶端輸入、網(wǎng)絡(luò)傳輸、SQL優(yōu)化、執(zhí)行、結(jié)果返回到客戶端這樣一個(gè)流程。而具體每一條SQL的執(zhí)行可能只是做一個(gè)字段的更新，所需要的執(zhí)行時(shí)間是非常短暫的，從整個(gè)鏈路的角度來看，大量的時(shí)間會(huì)花費(fèi)在與客戶端的交互過程中，造成資源的浪費(fèi)和耗時(shí)的增加。那么如何解決這個(gè)問題的呢?
答案就是使用存儲(chǔ)過程。
存儲(chǔ)過程 所謂“存儲(chǔ)過程”就是數(shù)據(jù)庫為用戶提供的一種面向過程的編程語言。基于這種語言，用戶可以將應(yīng)用程序的邏輯封裝為一個(gè)可調(diào)用的過程(procedure)存放在數(shù)據(jù)庫中并隨時(shí)進(jìn)行調(diào)用。通過這種方式，用戶可以將本來需要與數(shù)據(jù)庫進(jìn)行多次交互才能完成的工作通過一次交互完成，省去了中間網(wǎng)絡(luò)的傳輸和等待時(shí)間(參見圖1)。假如一條事務(wù)的網(wǎng)絡(luò)開銷平均是30%，也就是說30%的CPU都花在了網(wǎng)絡(luò)的收發(fā)和解析上。那么在6千萬規(guī)模tpmC測(cè)試中節(jié)省下來30%的CPU資源換算成系統(tǒng)處理能力是驚人的。使用存儲(chǔ)過程還可以帶來事務(wù)響應(yīng)時(shí)間的下降，導(dǎo)致數(shù)據(jù)庫內(nèi)核中事務(wù)鎖的臨界區(qū)縮短，間接的提升了系統(tǒng)CPU利用率，整個(gè)吞吐量也隨之提高。存儲(chǔ)過程在縮短應(yīng)用端的等待耗時(shí)上同樣有很大作用。
圖1 傳統(tǒng)的C/S模型與使用存儲(chǔ)過程的執(zhí)行方式對(duì)比
在TPC-C中，存儲(chǔ)過程對(duì)于整個(gè)系統(tǒng)的執(zhí)行效率提升是至關(guān)重要的。OceanBase 的2.2版本不僅全面支持了存儲(chǔ)過程，而且對(duì)存儲(chǔ)過程的執(zhí)行效率做了大量極致的優(yōu)化。
編譯執(zhí)行
存儲(chǔ)過程作為一種面向過程的高級(jí)語言，需要轉(zhuǎn)換成機(jī)器碼才能夠執(zhí)行。這個(gè)過程一般可以分為“編譯執(zhí)行”和“解釋執(zhí)行”兩種，一般來說，編譯執(zhí)行相比解釋執(zhí)行有代碼優(yōu)化充分、執(zhí)行效率高等特點(diǎn)。OceanBase利用近兩年逐漸成熟的LLVM編譯器框架實(shí)現(xiàn)了一個(gè)支持存儲(chǔ)過程的編譯器，通過動(dòng)態(tài)編譯(Just-in-Time Compilation)的方式將存儲(chǔ)過程翻譯成高效的二進(jìn)制可執(zhí)行代碼，在執(zhí)行效率上獲得了數(shù)量級(jí)的提升。同時(shí)，過程中LLVM框架將存儲(chǔ)過程轉(zhuǎn)換為與機(jī)器無關(guān)的中間代碼，使得存儲(chǔ)過程也自然而然地獲得了跨平臺(tái)的編譯執(zhí)行能力，LLVM內(nèi)置的優(yōu)化過程確保我們?cè)诟鞣N不同的硬件平臺(tái)上都可以獲得正確、高效的可執(zhí)行代碼。
Array Binding
另外一個(gè)在TPC-C測(cè)試中發(fā)揮了重要作用的功能就是對(duì)DML語句進(jìn)行批量處理的能力，在Oracle中該功能也稱為“Array Binding”。一條SQL在數(shù)據(jù)庫中的執(zhí)行過程大致上可以分為“計(jì)劃生成”和“執(zhí)行”兩個(gè)階段。盡管我們對(duì)SQL的執(zhí)行計(jì)劃做了高速緩存，但找到一個(gè)合適的執(zhí)行計(jì)劃在整個(gè)執(zhí)行過程中仍然是比較耗時(shí)的一個(gè)部分。那有沒有辦法省去這個(gè)時(shí)間呢?當(dāng)一組SQL的執(zhí)行計(jì)劃完全一樣而只有執(zhí)行參數(shù)不同時(shí)，在存儲(chǔ)過程中我們可以通過特定的語法將他們的執(zhí)行做成一個(gè)批量處理的過程，此時(shí)“計(jì)劃生成”只需要做一次即可，這就是所謂的“Array Binding”。
在Array Binding中，數(shù)據(jù)庫會(huì)首先找到需要使用的計(jì)劃，然后執(zhí)行該計(jì)劃，并在每次執(zhí)行完畢后，重新執(zhí)行參數(shù)綁定(binding)的過程。打個(gè)比方，這就像是在一個(gè)C語言的for循環(huán)中，反復(fù)賦值而不是重新定義一個(gè)數(shù)據(jù)結(jié)構(gòu)。Array Binding的使用受用戶控制，需要在存儲(chǔ)過程中使用FORALL關(guān)鍵字來觸發(fā)這一功能，在TPC-C的測(cè)試過程中，我們多次使用了Array Binding來提升系統(tǒng)的處理能力，效果非常明顯。
Prepared Statement與執(zhí)行計(jì)劃緩存
Prepared Statement是一種二進(jìn)制的請(qǐng)求交互協(xié)議，可以大大降低系統(tǒng)的交互成本。OceanBase不僅支持用戶程序與數(shù)據(jù)庫間使用Prepared Statement, 也支持在存儲(chǔ)過程引擎調(diào)用SQL引擎執(zhí)行時(shí)使用這種交互方式。存儲(chǔ)過程在對(duì)SQL進(jìn)行一次Prepare操作并獲取唯一id后, 后續(xù)的每次執(zhí)行僅需要傳入該id和對(duì)應(yīng)的參數(shù),系統(tǒng)可以通過高速緩存找到對(duì)應(yīng)的存儲(chǔ)過程或SQL計(jì)劃開始執(zhí)行。該過程相比使用SQL文本的交互方式，省去了大量請(qǐng)求文本解析的CPU開銷。
OceanBase內(nèi)部實(shí)現(xiàn)了高速緩存來緩存存儲(chǔ)過程的可執(zhí)行代碼及SQL執(zhí)行計(jì)劃,不同參數(shù)的存儲(chǔ)過程和SQL可以通過這一高速緩存快速獲取需要的執(zhí)行對(duì)象, 耗時(shí)一般在幾十微秒以內(nèi), 有效避免了重新編譯帶來的毫秒級(jí)的延遲和CPU消耗。
可更新視圖
在OLTP場(chǎng)景中，通過減少應(yīng)用與數(shù)據(jù)庫的交互次數(shù)來實(shí)現(xiàn)性能提升的例子很多，可更新視圖就是其中之一。我們常見的數(shù)據(jù)庫視圖通常是只讀的，通過定義視圖，用戶可以定義自己感興趣的數(shù)據(jù)以及其獲取接口，但視圖同時(shí)也可以作為更新操作的入口，比如在TPC-C的new order創(chuàng)建場(chǎng)景中，應(yīng)用需要得到商品信息，更新庫存并得到更新后的值。一般可以通過兩條SQL實(shí)現(xiàn)這一過程：
select i_price,i_name, i_data from item where i_id = ?;
UPDATE stock
SET s_order_cnt = s_order_cnt + 1,
s_ytd = s_ytd + ?,
s_remote_cnt = s_remote_cnt + ?,
s_quantity = (CASE WHEN s_quantity< ? + 10 THEN s_quantity + 91 ELSE s_quantity END) - ?
WHERE s_i_id = ?
AND s_w_id = ?
RETURNING s_quantity, s_dist_01,
CASE WHEN i_data NOT LIKE'%ORIGINAL%' THEN 'G' ELSE (CASE WHEN s_data NOT LIKE '%ORIGINAL%' THEN 'G'ELSE 'B' END) END
BULK COLLECT INTO ...;
但通過建立一個(gè)可更新視圖：
CREATE VIEW stock_item AS
SELECT i_price, i_name, i_data, s_i_id,s_w_id, s_order_cnt, s_ytd, s_remote_cnt, s_quantity, s_data, s_dist_01
FROM stock s, item i WHERE s.s_i_id =i.i_id;
我們就可以通過一條語句更新庫存并得到商品和庫存信息：
UPDATE stock_item
SET s_order_cnt = s_order_cnt + 1,
s_ytd = s_ytd + ?,
s_remote_cnt = s_remote_cnt + ?,
s_quantity = (CASE WHEN s_quantity< ? + 10 THEN s_quantity + 91 ELSE s_quantity END) - ?
WHERE s_i_id = ?
AND s_w_id = ?
RETURNING i_price, i_name, s_quantity,s_dist_01,
CASE WHEN i_data NOT LIKE'%ORIGINAL%' THEN 'G' ELSE (CASE WHEN s_data NOT LIKE '%ORIGINAL%' THEN 'G'ELSE 'B' END) END
BULK COLLECT INTO ...;
這樣就省去了一條語句的交互，并且更新邏輯更加直觀。可更新視圖允許用戶可以像普通表一樣操作視圖，但不是所有視圖都可以定義為可更新視圖。比如帶distinct, group by的視圖，具體更新哪些行語義是不明確的，因此不能允許更新。具體到上面的stock_item兩表join的視圖，需要滿足所更新表的unique key在join之后保持unique(key-preserved table)，即item.i_id必須是唯一的這個(gè)前提。
需要強(qiáng)調(diào)，TPC-C規(guī)范禁止使用物化視圖，而可更新視圖并沒有改變底層數(shù)據(jù)表格的存儲(chǔ)形式，是符合規(guī)范的。
因?yàn)門PC-C的設(shè)計(jì)原則是盡可能的“真實(shí)”反應(yīng)一個(gè)OLTP系統(tǒng)的運(yùn)行場(chǎng)景，我們所做的很多優(yōu)化都具有廣泛的適用性。例如，對(duì)于一個(gè)高并發(fā)的OLTP系統(tǒng)來說，大部分的SQL請(qǐng)求的耗時(shí)是非常短的，采用純粹的C/S交互模型的后果必然使系統(tǒng)的時(shí)間浪費(fèi)在應(yīng)用與數(shù)據(jù)庫的頻繁交互中，而使用存儲(chǔ)過程可以大大緩解這種交互的耗時(shí)，并且增強(qiáng)系統(tǒng)對(duì)于網(wǎng)絡(luò)抖動(dòng)的免疫力，這種核心能力對(duì)于一個(gè)分布式OLTP數(shù)據(jù)庫是不可或缺的。
在這次的TPC-C測(cè)試中，我們采用了OceanBase 2.0版本開始支持的Oracle兼容模式，存儲(chǔ)過程和SQL全部使用了兼容Oracle的數(shù)據(jù)類型和語法，這樣做也是為了在追求極致優(yōu)化的同時(shí)，確保產(chǎn)品迭代可以沿著通用和正規(guī)的方向發(fā)展。
三、TPC-C基準(zhǔn)測(cè)試之?dāng)?shù)據(jù)庫事務(wù)引擎的挑戰(zhàn)
OceanBase這次TPC-C測(cè)試與榜單上Oracle和DB2等其他數(shù)據(jù)庫在硬件使用上有非常大的不同，OceanBase的數(shù)據(jù)庫服務(wù)器使用的是204+3臺(tái)型號(hào)是ecs.i2.16xlarge阿里云ECS服務(wù)器，其中204臺(tái)作為data node，還有3臺(tái)作為root node，每位讀者都可以在阿里云網(wǎng)站上輕松按需購買。如果讀者翻看Oracle和DB2的TPC-C測(cè)試報(bào)告會(huì)發(fā)現(xiàn)，這些數(shù)據(jù)庫都會(huì)使用專用的存儲(chǔ)設(shè)備，例如前最高記錄保持者Oracle在2010年的測(cè)試，使用了97臺(tái)COMSTAR專用的存儲(chǔ)設(shè)備，其中28臺(tái)用來存儲(chǔ)數(shù)據(jù)庫的重做日志(Redo Log)。
硬件的差異給軟件架構(gòu)提出了完全不同的挑戰(zhàn)，專用的存儲(chǔ)設(shè)備其內(nèi)部通過硬件冗余實(shí)現(xiàn)了設(shè)備自身的可靠保證，數(shù)據(jù)庫軟件在使用這樣的存儲(chǔ)設(shè)備時(shí)就天然的預(yù)設(shè)了數(shù)據(jù)不會(huì)丟失。但是，這種方式帶來了成本的極大消耗，專用的存儲(chǔ)設(shè)備的價(jià)格都是特別昂貴的。
OceanBase使用通用的ECS服務(wù)器提供數(shù)據(jù)庫服務(wù)，并且只使用ECS機(jī)器自帶的本地硬盤做數(shù)據(jù)存儲(chǔ)，這是最通用的硬件條件。但是這種方式對(duì)軟件架構(gòu)提出了很大的挑戰(zhàn)，因?yàn)閱蝹€(gè)ECS服務(wù)器的不如專用的存儲(chǔ)設(shè)備可靠性高。這也對(duì)OceanBase的事務(wù)引擎提出了很大的挑戰(zhàn)，OceanBase是在普通的ECS服務(wù)器上就可以實(shí)現(xiàn)ACID特性。
TPC-C測(cè)試是對(duì)事務(wù)ACID特性有完整并且嚴(yán)格的要求。下面分別介紹OceanBase針對(duì)事務(wù)ACID的特性的解決方案。
Paxos日志同步保證持久性(Durability)
OceanBase數(shù)據(jù)庫的事務(wù)持久性(Durability)保證是依賴事務(wù)重做日志(Redo Log)的持久性來達(dá)成的。所有的 Redo Log 會(huì)實(shí)時(shí)強(qiáng)同步到另外兩臺(tái)數(shù)據(jù)庫服務(wù)機(jī)器上，包含產(chǎn)生 Redo Log 的機(jī)器在內(nèi)，總共會(huì)有三臺(tái)機(jī)器在硬盤中持久化 Redo Log。
OceanBase 采用了 Paxos 一致性同步協(xié)議來協(xié)調(diào)這三臺(tái)機(jī)器上 Redo Log 的持久化，Paxos協(xié)議采用超過半數(shù)(也叫“多數(shù)派”)成功即算成功的算法(三個(gè)副本時(shí)，兩個(gè)成功即超過半數(shù))，當(dāng)其中兩臺(tái)機(jī)器完成持久化后，事務(wù)即可完成提交，剩下的一臺(tái)機(jī)器的 Redo Log 在通常情況下，也是立即就持久化完成了。但如果這臺(tái)機(jī)器碰巧出現(xiàn)異常，也不會(huì)影響事務(wù)的提交，系統(tǒng)會(huì)在其恢復(fù)后自動(dòng)補(bǔ)齊所缺失的 Redo Log。如果機(jī)器永久故障，系統(tǒng)會(huì)將故障機(jī)器所應(yīng)負(fù)責(zé)同步的數(shù)據(jù)分散給集群內(nèi)的其他機(jī)器，這些機(jī)器會(huì)自動(dòng)補(bǔ)齊所缺失內(nèi)容，并跟上最新的 Redo Log 寫入。
使用Paxos一致性協(xié)議的最大優(yōu)勢(shì)是數(shù)據(jù)持久化和數(shù)據(jù)庫服務(wù)可用性的完美平衡。當(dāng)使用三個(gè)副本時(shí)，任何時(shí)候壞掉一個(gè)副本時(shí)至少還有另一個(gè)副本有數(shù)據(jù)，并且寫入還可以持續(xù)，因?yàn)檫€剩下兩個(gè)副本，后續(xù)的寫入也不受影響。
所以，OceanBase 在保證了事務(wù)持久性的同時(shí)，也大大提升了數(shù)據(jù)庫的連續(xù)服務(wù)能力。TPC組織的審計(jì)員在現(xiàn)場(chǎng)審計(jì)OceanBase持久性能力時(shí)，在客戶端持續(xù)產(chǎn)生壓力的情況下，從OceanBase集群中隨意挑選了一臺(tái)機(jī)器做了強(qiáng)制斷電操作，發(fā)現(xiàn)數(shù)據(jù)庫的數(shù)據(jù)不僅沒丟，數(shù)據(jù)庫不需要任何人工干預(yù)還能持續(xù)的提供服務(wù)，審計(jì)員們都很吃驚，并且對(duì)OceanBase大為贊賞。
依靠自動(dòng)兩階段提交解決原子性(Atomicity)
TPC-C測(cè)試模型的五種事務(wù)中的“訂單創(chuàng)建”和“訂單支付”兩個(gè)事務(wù)分別會(huì)對(duì)很多數(shù)據(jù)做修改，是其中相對(duì)復(fù)雜的兩個(gè)事務(wù)。TPC-C標(biāo)準(zhǔn)對(duì)事務(wù)的原子性(Atomicity)是強(qiáng)制性的要求，要求一個(gè)事務(wù)內(nèi)部對(duì)倉庫、訂單、用戶等表格的修改一定要原子的生效，不允許出現(xiàn)只有一半成功的情況。
OceanBase的數(shù)據(jù)是按照倉庫ID(Warehouse_ID)拆分到多臺(tái)機(jī)器上的，如果所有的事務(wù)都是發(fā)生在同一個(gè)倉庫內(nèi)部，那么無論數(shù)據(jù)量有多大，事務(wù)的修改都只會(huì)涉及一臺(tái)機(jī)器的數(shù)據(jù)，也就是在一臺(tái)機(jī)器上完成事務(wù)提交，這是一種完美的線形擴(kuò)展的場(chǎng)景。但是這不符合實(shí)際的業(yè)務(wù)場(chǎng)景，大多數(shù)的實(shí)際業(yè)務(wù)都會(huì)有很多不同維度之間的數(shù)據(jù)交互。TPC-C測(cè)試標(biāo)準(zhǔn)也是對(duì)此認(rèn)真考慮，所以對(duì)于事務(wù)操作數(shù)據(jù)的隨機(jī)性規(guī)則提出了要求，最終要保證產(chǎn)生10%的“訂單創(chuàng)建”事務(wù)和15%的“訂單支付”事務(wù)要操作兩個(gè)及以上的倉庫。在OceanBase數(shù)據(jù)庫內(nèi)，這樣就產(chǎn)生了跨機(jī)器的事務(wù)操作，而這必須使用兩階段提交協(xié)議來保證原子性。
OceanBase會(huì)自動(dòng)跟蹤一個(gè)事務(wù)內(nèi)所有SQL語句操作的數(shù)據(jù)，根據(jù)實(shí)際數(shù)據(jù)修改的位置自動(dòng)確定兩階段提交的參與者，事務(wù)開始提交時(shí)，OceanBase自動(dòng)選擇第一個(gè)參與者作為協(xié)調(diào)者，協(xié)調(diào)者會(huì)給所有參與者發(fā)送Prepare消息，每個(gè)參與者都需要寫各自的Redo Log和Prepare Log(也意味著每個(gè)參與者各自做自己的Paxos同步)，等協(xié)調(diào)者確認(rèn)所有參與者的Redo Log和Prepare Log完成后，然后再給所有參與者發(fā)送Commit消息，再等所有參與者的Commit工作完成。整個(gè)協(xié)議是在事務(wù)提交過程中自動(dòng)完成，對(duì)用戶完全透明。OceanBase為每一個(gè)兩階段提交事務(wù)自動(dòng)選擇一個(gè)協(xié)調(diào)者，整個(gè)系統(tǒng)任何機(jī)器都可以分擔(dān)協(xié)調(diào)者工作，所以O(shè)ceanBase可以將事務(wù)處理能力進(jìn)行線形擴(kuò)展。
多版本并發(fā)控制保證事務(wù)的隔離性(Isolation)
TPC-C標(biāo)準(zhǔn)里要求“訂單創(chuàng)建”、“訂單支付”、“訂單配送”、“訂單支付”事務(wù)之間都是串行化隔離級(jí)別(Serializable)。OceanBase采用的方法是基于多版本的并發(fā)控制機(jī)制。事務(wù)提交時(shí)會(huì)申請(qǐng)一個(gè)事務(wù)的提交時(shí)間戳，事務(wù)內(nèi)的修改以新的版本寫入存儲(chǔ)引擎，并且保證之前版本的數(shù)據(jù)不受影響。事務(wù)開始時(shí)會(huì)獲取一個(gè)讀取時(shí)間戳，整個(gè)事務(wù)內(nèi)數(shù)據(jù)的讀取操作只會(huì)看到基于讀取時(shí)間戳的已提交數(shù)據(jù)。所以，事務(wù)的讀取不會(huì)遇到臟數(shù)據(jù)、不可重復(fù)讀數(shù)據(jù)以及幻讀數(shù)據(jù)。同時(shí)，事務(wù)的修改會(huì)在修改的數(shù)據(jù)行上持有行鎖，保證兩個(gè)并發(fā)的修改相同行的事務(wù)會(huì)互斥。
OceanBase的全局時(shí)間戳生成器也是由多副本組成，可以獨(dú)立部署在三臺(tái)機(jī)器上，也可以像這次TPC-C評(píng)測(cè)中一樣部署在root node機(jī)器上，與root node共享資源。全局時(shí)間戳的三副本是一種極高可用的架構(gòu)，任何一次時(shí)間戳的獲取操作都至少在三臺(tái)機(jī)器上的兩臺(tái)獲得了確認(rèn)，所以任意一臺(tái)機(jī)器出現(xiàn)故障，獲取時(shí)間戳的操作不會(huì)有一點(diǎn)影響。
按照TPC-C標(biāo)準(zhǔn)，OceanBase準(zhǔn)備了9種不同的場(chǎng)景測(cè)試有讀-讀、讀-寫沖突時(shí)事務(wù)的隔離性，最終都完美通過了審計(jì)員的審計(jì)。
一致性保證(Consistency)
在有了上述的事務(wù)能力后，OceanBase可以完美的保證各種數(shù)據(jù)的一致性的約束。TPC-C標(biāo)準(zhǔn)里提出了12種不同的一致性測(cè)試場(chǎng)景在各種測(cè)試運(yùn)行前后對(duì)數(shù)據(jù)庫內(nèi)的數(shù)據(jù)進(jìn)行一致性校驗(yàn)。因?yàn)镺ceanBase此次測(cè)試數(shù)據(jù)規(guī)模龐大，一致性校驗(yàn)的SQL需要核對(duì)大量的數(shù)據(jù)，所以一致性校驗(yàn)的挑戰(zhàn)在于校驗(yàn)的SQL本身運(yùn)行的效率。基于OceanBase的并行查詢能力，發(fā)揮整個(gè)集群所有的計(jì)算資源，校驗(yàn)SQL的運(yùn)行時(shí)間均縮短了幾個(gè)數(shù)量級(jí)，很好的完成一致性功能的審計(jì)工作。
復(fù)制表
TPC-C測(cè)試模型中有一張商品(ITEM)表，這張表的內(nèi)容是測(cè)試所模擬的銷售公司所有售賣的商品信息，包含了商品的名字、價(jià)格等信息。“訂單創(chuàng)建”事務(wù)執(zhí)行中需要請(qǐng)求這張表內(nèi)的數(shù)據(jù)來確定訂單的價(jià)格信息，如果商品表的數(shù)據(jù)只存放在一臺(tái)機(jī)器上，那么所有機(jī)器上發(fā)生的“訂單創(chuàng)建”事務(wù)都會(huì)請(qǐng)求包含商品表的機(jī)器，這臺(tái)機(jī)器就會(huì)成為瓶頸。OceanBase支持復(fù)制表功能，將商品表設(shè)置為復(fù)制表后，商品表的數(shù)據(jù)會(huì)自動(dòng)復(fù)制到集群中的每一臺(tái)機(jī)器上。
TPC-C標(biāo)準(zhǔn)不限制數(shù)據(jù)的副本數(shù)，但是不管數(shù)據(jù)的組織形式，標(biāo)準(zhǔn)里要求事務(wù)的ACID一定要保證。OceanBase使用特殊的廣播協(xié)議保證復(fù)制表的所有副本的ACID特性，當(dāng)復(fù)制表發(fā)生修改時(shí)，所有的副本會(huì)同時(shí)修改。并且，當(dāng)有機(jī)器出現(xiàn)故障時(shí)，復(fù)制表的邏輯會(huì)自動(dòng)剔除無效的副本，保證數(shù)據(jù)修改過程中不會(huì)因?yàn)闄C(jī)器故障出現(xiàn)無謂的等待。復(fù)制表在很多業(yè)務(wù)場(chǎng)景中都有使用，例如很多業(yè)務(wù)中存儲(chǔ)關(guān)鍵信息的字典表，還有金融業(yè)務(wù)中存儲(chǔ)匯率信息的表。
四、TPC-C基準(zhǔn)測(cè)試之存儲(chǔ)優(yōu)化
TPC-C規(guī)范要求被測(cè)數(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測(cè)試，不限制單個(gè)warehouse的tpmC上限，測(cè)試幾百到幾千個(gè)warehouse全部裝載到內(nèi)存的性能，這是沒有意義的，也不可能通過審計(jì)。在真實(shí)的TPC-C測(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)：
1. 為了保證可靠性，OceanBase存儲(chǔ)了兩個(gè)數(shù)據(jù)副本和三個(gè)日志副本，而傳統(tǒng)的集中式數(shù)據(jù)庫測(cè)試TPC-C只存儲(chǔ)一份數(shù)據(jù);
2. 由于OceanBase存儲(chǔ)兩個(gè)數(shù)據(jù)副本，再加上OceanBase TPC-C測(cè)試采用了和生產(chǎn)系統(tǒng)完全一樣的阿里云服務(wù)器i2機(jī)型，SSD硬盤的存儲(chǔ)容量成為瓶頸。OceanBase采用在線壓縮的方式緩解這個(gè)問題，進(jìn)一步增加了CPU使用;相應(yīng)地，集中式數(shù)據(jù)庫測(cè)試存儲(chǔ)一份數(shù)據(jù)，不需要打開壓縮;
3. OceanBase LSM引擎定期需要在后臺(tái)做compaction操作，而TPC-C要求測(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)勢(shì)是硬件成本更低，帶來的問題是需要冗余存儲(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測(cè)試大多基于磁盤陣列，而TPC-C規(guī)范中明確對(duì)磁盤陣列不做容災(zāi)要求，使用相對(duì)于傳統(tǒng)數(shù)據(jù)庫三倍的存儲(chǔ)空間進(jìn)行TPC-C測(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測(cè)試中我們使用FDL模式進(jìn)行部署(一個(gè)F副本，一個(gè)D副本，一個(gè)L副本)，使用了兩倍數(shù)據(jù)副本的存儲(chǔ)空間。無論是D副本還是L副本，都需要回放日志，D副本還需要同步數(shù)據(jù)，這些都是都會(huì)消耗網(wǎng)絡(luò)和CPU。
在線壓縮
在sharednothing架構(gòu)下，OceanBase至少需要存儲(chǔ)兩份數(shù)據(jù)才可以滿足容災(zāi)的要求，這意味著OceanBase需要比傳統(tǒng)數(shù)據(jù)庫多耗費(fèi)一倍的存儲(chǔ)空間。
為了緩解這個(gè)問題，OceanBaseTPC-C測(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)勢(shì)是沒有隨機(jī)修改，能夠在線壓縮。無論是TPC-C測(cè)試，還是最核心的OLTP生產(chǎn)系統(tǒng)(例如支付寶交易支付)，OceanBase都會(huì)打開在線壓縮，通過CPU換存儲(chǔ)空間。
存儲(chǔ)性能
平滑 TPC-C測(cè)試很大的挑戰(zhàn)在于在整個(gè)壓測(cè)過程中性能曲線要求是絕對(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)镺ceanBase的存儲(chǔ)引擎是基于LSM Tree的，在LSM Tree要定期執(zhí)行compaction操作。Compaction是個(gè)非常重的后臺(tái)操作，會(huì)占用大量CPU和磁盤IO資源，這對(duì)前臺(tái)的用戶查詢和寫入天然就會(huì)造成影響。我們做了一些優(yōu)化，來平滑后臺(tái)任務(wù)對(duì)性能的影響，從最終的測(cè)試結(jié)果來看，性能曲線在整個(gè)8小時(shí)壓測(cè)過程中的抖動(dòng)小于0.5%。
分層轉(zhuǎn)儲(chǔ)
在LSMTree中，數(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è)贑PU、內(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)測(cè)試主要考察整體性能tpmC，很多人也會(huì)關(guān)注單核的tpmC。然而，這個(gè)指標(biāo)只有在相同架構(gòu)下才有意義。對(duì)于存儲(chǔ)模塊的CPU占用，有如下三點(diǎn)：
1. 對(duì)于集中式架構(gòu)，除了數(shù)據(jù)庫使用CPU之外，專用存儲(chǔ)設(shè)備也需要使用CPU。例如，第二名Oracle 3000多萬tpmC的測(cè)試中，數(shù)據(jù)庫使用了108顆T3SPARC處理器，共有1728個(gè)物理核心和13824個(gè)執(zhí)行線程，同時(shí)存儲(chǔ)設(shè)備使用的是Intel服務(wù)器作為機(jī)頭，總共使用了97臺(tái)服務(wù)器，194顆Intel X5670 CPU，2328個(gè)物理核心。
2. 集中式數(shù)據(jù)庫使用高可靠硬件，只需要存儲(chǔ)一個(gè)副本，而OceanBase通過軟件層面容錯(cuò)，雖然硬件成本更低但需要兩個(gè)數(shù)據(jù)副本和三個(gè)日志副本，維護(hù)多個(gè)副本需要耗費(fèi)大量CPU;
3. OceanBase在TPC-C測(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的測(cè)試中，硬件成本只占整體成本的18%左右，只考慮硬件的性價(jià)比大幅優(yōu)于集中式數(shù)據(jù)庫。
后續(xù)發(fā)展
OceanBase的優(yōu)勢(shì)在于采用分布式架構(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ì)算。
作者：陽振坤(OceanBase創(chuàng)始人)曹暉(OceanBase技術(shù)專家)陳萌萌(OceanBase資深技術(shù)專家)潘毅(OceanBase資深技術(shù)專家)韓富晟(OceanBase資深技術(shù)專家)趙裕眾(OceanBase高級(jí)技術(shù)專家)
【責(zé)任編輯：武曉燕 TEL：（010）68476606】
