曾經(jīng)一度瀕臨解散的OceanBase團(tuán)隊(duì)（專注分布式關(guān)系數(shù)據(jù)庫(kù)），在5月20日這天再次迎來了自己的高光時(shí)刻：

國(guó)際事務(wù)處理性能委員會(huì)（TPC，Transaction Processing Performance Council）官網(wǎng)發(fā)布最新的數(shù)據(jù)分析型基準(zhǔn)測(cè)試（TPC-H）榜單，其中，螞蟻集團(tuán)自主研發(fā)的分布式關(guān)系數(shù)據(jù)庫(kù)OceanBase以1526萬(wàn)QphH的性能總分排名30000GB第一。

這是中國(guó)自研數(shù)據(jù)庫(kù)的一次里程碑。

這意味著，OceanBase成為唯一在事務(wù)處理和數(shù)據(jù)分析兩個(gè)領(lǐng)域測(cè)試中都獲得第一的中國(guó)自研數(shù)據(jù)庫(kù)。

雷鋒網(wǎng)注意到，去年的5月20日OceanBase同樣破了一個(gè)記錄：性能分?jǐn)?shù)首次突破億級(jí)大關(guān)達(dá)到7.07億tpmC，相比2019年提升近11倍。（雷鋒網(wǎng)注：tpmC值在國(guó)內(nèi)外被廣泛用于衡量計(jì)算機(jī)系統(tǒng)的事務(wù)處理能力，為"每分鐘內(nèi)系統(tǒng)處理的新訂單個(gè)數(shù)"的英文縮寫） 這一事件標(biāo)志著OceanBase在當(dāng)時(shí)成為全球最快數(shù)據(jù)庫(kù)，實(shí)現(xiàn)了數(shù)據(jù)庫(kù)這一基礎(chǔ)技術(shù)的革命性突破，也是自研技術(shù)對(duì)世界IT技術(shù)作出的重要貢獻(xiàn)。 

一直以來，數(shù)據(jù)庫(kù)與芯片、操作系統(tǒng)并列為全球技術(shù)三大件，也是企業(yè)IT系統(tǒng)必不可少的核心技術(shù)。OceanBase由螞蟻集團(tuán)自主研發(fā)，歷經(jīng)阿里巴巴和螞蟻集團(tuán)大規(guī)模業(yè)務(wù)場(chǎng)景的長(zhǎng)時(shí)間考驗(yàn)。

“OceanBase是典型的‘用出來’的數(shù)據(jù)庫(kù)，經(jīng)過十余年不同場(chǎng)景的嚴(yán)苛打磨?！?OceanBase公司CEO楊冰表示，“原生分布式的OceanBase具有無(wú)單點(diǎn)瓶頸，可線性、在線擴(kuò)展和收縮等特性，可以更好地解決業(yè)務(wù)擴(kuò)展性難題，幫助機(jī)構(gòu)快速實(shí)現(xiàn)數(shù)字化轉(zhuǎn)型?！?/p>

數(shù)據(jù)分析型基準(zhǔn)測(cè)試（TPC-H）自2006年公布以來很快被業(yè)界認(rèn)可，是公認(rèn)的衡量數(shù)據(jù)庫(kù)數(shù)據(jù)分析能力的權(quán)威標(biāo)準(zhǔn)之一。TPC官網(wǎng)顯示，在數(shù)據(jù)分析型基準(zhǔn)測(cè)試榜單的30000GB結(jié)果一欄，OceanBase占據(jù)性能排行首位，其中代表著數(shù)據(jù)庫(kù)核心性能的每小時(shí)執(zhí)行請(qǐng)求數(shù)綜合指標(biāo)達(dá)到了1526萬(wàn)QphH@30,000GB, 比第二名微軟SQLServer的成績(jī)高出10多倍。

此前，螞蟻OceanBase在2019年和2020年均參與了事務(wù)處理型基準(zhǔn)測(cè)試（TPC-C），并兩度登頂。

很多人會(huì)好奇，OceanBase不是拿過事務(wù)處理型基準(zhǔn)測(cè)試（TPC-C）第一了么，為什么還要打TPC-H這樣一個(gè)AP場(chǎng)景的榜單？

OceanBase負(fù)責(zé)此次測(cè)試的核心成員陳萌萌撰文，講述了背后的技術(shù)思考。以下enjoy：

收到期盼了好幾天的審計(jì)員最終郵件，告知測(cè)試結(jié)果已經(jīng)掛到了官方網(wǎng)站。這意味著，測(cè)試小組的工作可以正式告一段落。接下來的60天，此次測(cè)試的報(bào)告將處于公示階段，迎接全世界數(shù)據(jù)庫(kù)專家的檢視和挑戰(zhàn)。

OceanBase TPC-H項(xiàng)目組

對(duì)我個(gè)人來說，原本期待的興奮感沒有如期而至。更多的是平靜。平靜地把官網(wǎng)上的測(cè)試報(bào)告又從頭到尾讀了一遍。按說，前前后后來來回回幾十封郵件的技術(shù)溝通，報(bào)告里面的內(nèi)容已經(jīng)爛熟。再讀一次，既是出于技術(shù)人天生的謹(jǐn)慎，更是不想因?yàn)橐粋€(gè)低級(jí)錯(cuò)誤而讓項(xiàng)目所有同學(xué)三個(gè)月的心血付諸東流。

關(guān)于為什么要沖擊此次的榜單？簡(jiǎn)單來說，是因?yàn)榻裉斓腛ceanBase已經(jīng)升級(jí)為一款支持 HTAP 混合負(fù)載的企業(yè)級(jí)分布式數(shù)據(jù)庫(kù)，同時(shí)具備事務(wù)處理和數(shù)據(jù)分析兩類場(chǎng)景的處理能力。我們希望市場(chǎng)對(duì)我們有更多了解。權(quán)威中立機(jī)構(gòu)的背書總好過“王婆賣瓜自賣自夸”。此外，從技術(shù)上說，這也是一件水到渠成的事情。只是，這個(gè)時(shí)間點(diǎn)跟OceanBase對(duì)數(shù)據(jù)庫(kù)的理解，以及未來想做的事情有密切關(guān)系。

一、HTAP ，既是數(shù)據(jù)庫(kù)的初心，也是數(shù)據(jù)庫(kù)的未來

HTAP數(shù)據(jù)庫(kù)（Hybrid Transaction and Analytical Processing，混合事務(wù)和分析處理）就是能夠?qū)⑹聞?wù)處理(On-Line Transactional Processing，以下簡(jiǎn)稱TP) 和數(shù)據(jù)分析 (On-Line Analytical Processing，以下簡(jiǎn)稱AP) 請(qǐng)求在同一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)中完成。

這個(gè)概念，由Gartner在2014年的一份報(bào)告中提出。分析師認(rèn)為，這種架構(gòu)具有顯而易見的優(yōu)勢(shì)：不但避免了繁瑣且昂貴的ETL操作，而且可以更快地對(duì)最新數(shù)據(jù)進(jìn)行分析。這種快速分析數(shù)據(jù)的能力將成為未來企業(yè)的核心競(jìng)爭(zhēng)力之一。

關(guān)系型數(shù)據(jù)庫(kù)的英文縮寫是RDBMS，其中的M就是“管理”的意思，不管是TP還是AP，數(shù)據(jù)庫(kù)的存在就是為了“管理”數(shù)據(jù)，我認(rèn)為這是數(shù)據(jù)庫(kù)這個(gè)系統(tǒng)的初心。

天下大事，分久必合，合久必分。HTAP本來也不能算是新概念。TP和AP這兩種需求在數(shù)據(jù)庫(kù)的發(fā)展上已經(jīng)歷了漫長(zhǎng)的混合-分離-再融合過程。

上世紀(jì)70年代末到90年代初是數(shù)據(jù)庫(kù)從理論到實(shí)踐逐漸成熟的黃金時(shí)代。1970年，IBM的E. F. Codd提出了“關(guān)系型數(shù)據(jù)庫(kù)”的概念。1974年，IBM著手研發(fā)System R數(shù)據(jù)庫(kù)，極大地推動(dòng)了關(guān)系型數(shù)據(jù)庫(kù)概念的發(fā)展，并采用SQL作為標(biāo)準(zhǔn)的數(shù)據(jù)庫(kù)語(yǔ)言。

70年代末到80年代初，有“數(shù)據(jù)庫(kù)先生”之稱的圖靈獎(jiǎng)獲得者Jim Gray奠定了事務(wù)處理的理論基礎(chǔ)。同一時(shí)期，System R系統(tǒng)的實(shí)現(xiàn)也催生了查詢優(yōu)化技術(shù)。Selinger等人發(fā)表的“Access Path Selection in a Relational Database Management System”論文則被認(rèn)為是基于代價(jià)的查詢優(yōu)化技術(shù)的開山之作。1988年，IBM的Barry Devlin和Paul Murphy提出了專門用來做數(shù)據(jù)分析的“數(shù)據(jù)倉(cāng)庫(kù)”（以下簡(jiǎn)稱“數(shù)倉(cāng)”）概念。1993年，E. F. Codd仿照“On-line Transaction Processing”的結(jié)構(gòu)首次提出了“On-line Analytical Processing”的概念，一下子把數(shù)據(jù)分析的抽象和應(yīng)用提升到了一個(gè)新的層面?？梢哉f，在數(shù)據(jù)庫(kù)遠(yuǎn)古大神一個(gè)個(gè)粉墨登場(chǎng)的年代，TP和AP兩種場(chǎng)景就像一對(duì)被他們細(xì)心呵護(hù)的孿生兄弟茁壯地成長(zhǎng)著。

隨著數(shù)據(jù)庫(kù)使用場(chǎng)景的日益豐富，TP和AP需求的矛盾逐漸顯露。單機(jī)數(shù)據(jù)庫(kù)的處理能力畢竟有限，分布式數(shù)據(jù)庫(kù)的理論開始出現(xiàn)，工程實(shí)踐也遇到很多問題。

怎么同時(shí)處理TP和AP請(qǐng)求？1988年 提出的“數(shù)倉(cāng)”概念，背后隱藏的假設(shè)是TP和AP請(qǐng)求會(huì)放在不同的系統(tǒng)中處理。這樣假設(shè)有業(yè)務(wù)發(fā)展和應(yīng)用架構(gòu)的必然性，但技術(shù)層面的限制也是不可回避的問題。畢竟在那個(gè)時(shí)代，作為分布式數(shù)據(jù)庫(kù)系統(tǒng)的Teradata，最大只能支持1000個(gè)核和5TB存儲(chǔ)。而且，真正能夠使用這樣高端系統(tǒng)的用戶寥寥無(wú)幾。

當(dāng)用戶開始被迫地把TP或者是AP的請(qǐng)求分成不同系統(tǒng)時(shí)，專門處理TP和AP場(chǎng)景的數(shù)據(jù)庫(kù)隨之出現(xiàn)。針對(duì)不同場(chǎng)景，采用不同引擎技術(shù)，比如按行存儲(chǔ)或是按列存儲(chǔ)，確實(shí)能夠大幅度提高特定場(chǎng)景下的數(shù)據(jù)庫(kù)性能。

但不可否認(rèn)，一個(gè)能同時(shí)處理TP和AP請(qǐng)求的數(shù)據(jù)庫(kù)，對(duì)于用戶來說是非常有價(jià)值的，除了能大幅度降低用戶成本外，還能明顯降低用戶系統(tǒng)的復(fù)雜性和運(yùn)維成本。

因此，很多成熟的商業(yè)數(shù)據(jù)庫(kù)，如Oracle、IBM DB2等，在保持極強(qiáng)的TP處理能力之外，從來沒有停止過對(duì)AP場(chǎng)景的支持和優(yōu)化。如果大家看一下這些數(shù)據(jù)庫(kù)巨頭在頂級(jí)學(xué)術(shù)會(huì)議上發(fā)表的論文列表就會(huì)發(fā)現(xiàn)，面向AP場(chǎng)景的論文，數(shù)量甚至比事務(wù)處理方向的還多，而且每年都有更新。

2010年前后，隨著硬件能力越來越強(qiáng)，尤其是SSD固態(tài)盤、大容量?jī)?nèi)存和多核CPU等技術(shù)的普及，大大增加了數(shù)據(jù)庫(kù)的設(shè)計(jì)可能，促使不少數(shù)據(jù)庫(kù)研究人員重新思考在同一個(gè)數(shù)據(jù)庫(kù)中處理TP和AP請(qǐng)求的可能，甚至包括當(dāng)初締造“數(shù)倉(cāng)”概念的Barry Devlin都提出，應(yīng)該“重新考慮將TP和AP分開這一設(shè)計(jì)理念”。今天，不少新的數(shù)據(jù)庫(kù)也開始宣稱支持HTAP，我想也是順應(yīng)了整個(gè)技術(shù)的大趨勢(shì)。

二、OceanBase 把HTAP寫入基因

OceanBase是2010年開始在阿里集團(tuán)內(nèi)部自主研發(fā)的分布式數(shù)據(jù)庫(kù)。最開始基本就是在阿里、螞蟻內(nèi)部用，真正長(zhǎng)得像一個(gè)數(shù)據(jù)庫(kù)的樣子，應(yīng)該是從2014年啟動(dòng)OceanBase 1.0版本開始的。我也是在那個(gè)時(shí)候加入OceanBase，跟著團(tuán)隊(duì)一步步走到了今天。

回想當(dāng)初，數(shù)據(jù)庫(kù)的很多技術(shù)都在悄悄發(fā)生著變化。一方面，以O(shè)racle為首的傳統(tǒng)數(shù)據(jù)庫(kù)在TP場(chǎng)景似乎已經(jīng)“獨(dú)孤求敗“，TPC-C世界紀(jì)錄已經(jīng)多年未被打破，而像OceanBase這樣的分布式數(shù)據(jù)庫(kù)還沒有看到挑戰(zhàn)Oracle霸主地位的可能。

另外一方面，傳統(tǒng)數(shù)據(jù)庫(kù)的AP能力越來越跟不上數(shù)據(jù)規(guī)模和硬件的發(fā)展。SSD、大容量?jī)?nèi)存、超高核數(shù)的CPU，這些理論上能帶來巨大性能提升的硬件無(wú)一不在挑戰(zhàn)傳統(tǒng)的數(shù)據(jù)庫(kù)軟件設(shè)計(jì)。TPC-H榜單上，Oracle、SQL Server這種傳統(tǒng)數(shù)據(jù)庫(kù)被神秘的數(shù)據(jù)庫(kù)廠商Exasol虐的找不著北。Exasol具體怎么實(shí)現(xiàn)的我不是特別清楚，但向量化引擎、cache-aware、列存、及時(shí)編譯（Just-in-Time compilation）,大致總離不開這幾個(gè)方向。但傳統(tǒng)數(shù)據(jù)庫(kù)不是這么設(shè)計(jì)的，內(nèi)存能大到幾百GB甚至上TB？最初的數(shù)據(jù)庫(kù)設(shè)計(jì)者想都不敢想，更別提充分利用了，“守著金山要飯吃”，當(dāng)時(shí)的傳統(tǒng)數(shù)據(jù)庫(kù)看到硬件的發(fā)展就是這么一種感覺吧。

當(dāng)時(shí)的我也在思考這個(gè)問題：一個(gè)能同時(shí)處理好TP和AP請(qǐng)求、并且能充分挖掘硬件能力的數(shù)據(jù)庫(kù)到底應(yīng)該是什么樣的？“縫縫補(bǔ)補(bǔ)帶不來真正的技術(shù)革新”。在一個(gè)現(xiàn)成的開源組件去打補(bǔ)丁，或者簡(jiǎn)單重構(gòu)很難做出一個(gè)劃時(shí)代的產(chǎn)品，因?yàn)槲易约涸谝粋€(gè)面向AP的開源引擎上嘗試過這件事兒，干到后面覺得比重寫一個(gè)引擎難多了。2014年OceanBase 1.0版本正在醞釀中，對(duì)我來說，做一個(gè)真正HTAP引擎的機(jī)會(huì)來了。

從時(shí)間上看，AP場(chǎng)景的幾項(xiàng)關(guān)鍵技術(shù)是隨著產(chǎn)品豐富逐步完善起來的。2014年做了基于代價(jià)的查詢優(yōu)化器。2016年做了分布式運(yùn)行一體化執(zhí)行。2019年和2020年分別做了向量化執(zhí)行引擎和TP、AP的資源隔離。事實(shí)上，這些年，OceanBase的AP能力一直在不斷增強(qiáng)，只不過大家很少有機(jī)會(huì)了解。

如果知道這些來龍去脈，大家對(duì)OceanBase沖擊TPC-H這件事兒，也許就沒那么奇怪了。今天我們的用戶場(chǎng)景和產(chǎn)品定位也都需要產(chǎn)品具備這樣的能力，從這個(gè)角度上講，OceanBase正式進(jìn)入到HTAP產(chǎn)品時(shí)代，也是市場(chǎng)的選擇。

從2017年開始，我每年都會(huì)投入相當(dāng)比例的時(shí)間拜訪外部客戶。在這個(gè)過程中，深刻感受到，對(duì)于HTAP，不同客戶有不一樣的認(rèn)知。

其中一部分用戶使用的是典型的TP、AP獨(dú)立架構(gòu)。這類用戶以互聯(lián)網(wǎng)公司居多，受目前流行的解決方案影響。系統(tǒng)設(shè)計(jì)之初就將TP和AP系統(tǒng)分開，通過中間鏈路同步數(shù)據(jù)。這類用戶一般有兩個(gè)痛點(diǎn)，一個(gè)是實(shí)時(shí)性要求高的分析邏輯無(wú)法在TP數(shù)據(jù)庫(kù)中原地完成，只能等數(shù)據(jù)同步到AP數(shù)據(jù)庫(kù)中再做。另外就是系統(tǒng)難以運(yùn)維，尤其是中小型的客戶，運(yùn)維人員得熟悉兩套系統(tǒng)，還要時(shí)刻關(guān)注中間數(shù)據(jù)鏈路的穩(wěn)定性，技術(shù)門檻很高。

另外一部分用戶，一直使用的是像Oracle這樣的傳統(tǒng)的數(shù)據(jù)庫(kù)，對(duì)于TP和AP的邊界認(rèn)知比較模糊，尤其是Oracle的處理能力很強(qiáng)，很多復(fù)雜查詢?nèi)拥絆racle里面也能跑。在一次某大型客戶的業(yè)務(wù)上線過程中，壓測(cè)的最后階段，我們發(fā)現(xiàn)了非常多的復(fù)雜查詢。當(dāng)我們?cè)儐柨蛻魹槭裁此麄兊腡P系統(tǒng)中會(huì)有如此多AP請(qǐng)求時(shí)，客戶的一句話把我們問懵了——“啥叫TP、AP請(qǐng)求？”我們?cè)趦?nèi)部也有過討論，發(fā)現(xiàn)即使是團(tuán)隊(duì)內(nèi)部大家的看法也是不一樣的。只能說有一些場(chǎng)景偏TP類型或者偏AP類型，但很難給出絕對(duì)答案。

越來越多的客戶案例讓我意識(shí)到，過去一直堅(jiān)持的HTAP技術(shù)方向也是很多客戶需要的。但今天在很多客戶眼中，OceanBase就是只支持TP處理的數(shù)據(jù)庫(kù)，完全沒想到我們還有很強(qiáng)的AP處理能力?！熬葡阋才孪镒由睢?，我們覺得這個(gè)時(shí)候打榜TPC-H，既能讓產(chǎn)品的能力進(jìn)一步提高，大家也能更了解OceanBase的價(jià)值。

三、TPC-H新世界紀(jì)錄背后的“三座大山”

如果讓2014年的我說OceanBase什么時(shí)候能夠在TPC-C、TPC-H這樣的榜單上露個(gè)臉，我還真不知道。

做數(shù)據(jù)庫(kù)就像蓋房子，今天OceanBase這座房子已經(jīng)到了交付階段，要給客戶的體驗(yàn)是“拎包入住”，因此水、電、裝修風(fēng)格都要做好。而2014 年就像在“打地基”的階段，你說我將來要做某某內(nèi)飾風(fēng)格，至少當(dāng)時(shí)沒有想到那么具體的事情，但是我知道分布式一定是這個(gè)房子的“地基”，我們要蓋的是一個(gè)摩天大樓，而不是一個(gè)獨(dú)門小院。這個(gè)是打破傳統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)限制的前提，想通了這個(gè)事兒，后面的技術(shù)落地就比較自然了。

為什么分布式數(shù)據(jù)庫(kù)是HTAP技術(shù)的未來？這個(gè)和HTAP的幾大技術(shù)挑戰(zhàn)有關(guān)。

首先，也是最重要的事情，這個(gè)系統(tǒng)的容量一定要足夠大，擴(kuò)展性足夠強(qiáng)。

從數(shù)據(jù)容量上看，因?yàn)锳P本身的分析要有價(jià)值，就需要聚集相當(dāng)量的數(shù)據(jù)才有價(jià)值，這是以前的單機(jī)數(shù)據(jù)庫(kù)做不到的。一臺(tái)機(jī)器的容量，或者是幾臺(tái)機(jī)器的容量永遠(yuǎn)是受限的。十年前，世界上最大的Oracle RAC實(shí)際系統(tǒng)只有20來個(gè)節(jié)點(diǎn)。當(dāng)時(shí)我在Oracle經(jīng)歷的一個(gè)重要項(xiàng)目是，將RAC的集群規(guī)模擴(kuò)展到128臺(tái)。而今天像OceanBase這樣一個(gè)分布式數(shù)據(jù)庫(kù)，做到幾百臺(tái)機(jī)器的集群規(guī)模是非常輕松的，這種規(guī)模上的區(qū)別帶來技術(shù)上的想象空間是完全不同的。

而且在這次測(cè)試面向AP的場(chǎng)景中，又引入了一個(gè)OceanBase家族的新成員叫OceanBase File System（簡(jiǎn)稱OFS）。這是一個(gè)分布式的共享存儲(chǔ)系統(tǒng)，基于OFS的方案在存儲(chǔ)容量上幾乎是可以無(wú)限擴(kuò)展，永遠(yuǎn)不用擔(dān)心數(shù)據(jù)沒地方存。這就解決了整個(gè)系統(tǒng)容量的擴(kuò)展的問題。

另外，既然要將TP和AP放到同一個(gè)集群中處理，那么集群的處理能力也要有非常強(qiáng)的可擴(kuò)展性。這里如果再講多一些，處理能力的擴(kuò)展性還能分為“水平”擴(kuò)展和“垂直”擴(kuò)展兩個(gè)維度。

大家看過我們TPC-C的測(cè)試結(jié)果可能還有印象。當(dāng)時(shí)，是用了1554臺(tái)機(jī)器，把整個(gè)TP系統(tǒng)跑這么高的分?jǐn)?shù)。這個(gè)體現(xiàn)的是OceanBase的水平擴(kuò)展能力。

什么叫垂直擴(kuò)展性呢？就是在一臺(tái)機(jī)器內(nèi)部通過硬件擴(kuò)展（更多CPU核數(shù)、更大內(nèi)存）而提升性能。為什么這個(gè)在HTAP下仍然有挑戰(zhàn)？因?yàn)樵赥PC-C的擴(kuò)展里面，更強(qiáng)調(diào)的是水平擴(kuò)展，換句話說，數(shù)據(jù)庫(kù)集群規(guī)模越大，性能分?jǐn)?shù)就越高。但在AP場(chǎng)景下，用戶同時(shí)也會(huì)關(guān)心能不能實(shí)現(xiàn)垂直擴(kuò)展，比如說能不能讓一個(gè)系統(tǒng)的幾千個(gè)CPU核，幾十臺(tái)機(jī)器同時(shí)為一個(gè)查詢服務(wù)。萬(wàn)事萬(wàn)物，只要涉及到“協(xié)同“，就有成本。把協(xié)同的成本降低到最低，考驗(yàn)的是系統(tǒng)整體的設(shè)計(jì)。

TPC-H測(cè)試場(chǎng)景中，要求我們用64臺(tái)機(jī)器的5120個(gè)CPU超線程，同時(shí)去服務(wù)每一個(gè)用戶請(qǐng)求，把本來需要幾十分鐘才能完成的請(qǐng)求，在幾秒內(nèi)處理掉，這里涉及的CPU核數(shù)和整體性能數(shù)值都是整個(gè)TPC-H結(jié)果中最高的。

第二個(gè)方面是一個(gè)真正的HTAP系統(tǒng)需要在TP場(chǎng)景和AP場(chǎng)景都有很強(qiáng)的處理能力。

OceanBase的TP處理能力在TPC-C打榜過程中已經(jīng)得到了驗(yàn)證，背后的技術(shù)也有相關(guān)文章詳細(xì)解讀，這里不再贅述。那AP場(chǎng)景到底要求的是什么能力？

首先來說是查詢優(yōu)化的能力。AP場(chǎng)景天然有很多復(fù)雜的用戶查詢，具體到SQL語(yǔ)句上就是大量的多表連接、復(fù)雜的表達(dá)式計(jì)算、多層嵌套的子查詢、聚合函數(shù)等等，這些對(duì)引擎的查詢優(yōu)化能力要求門檻極高。

記得曾經(jīng)一個(gè)同行半開玩笑的說，很多專注TP的數(shù)據(jù)庫(kù)系統(tǒng)不是不想做HTAP，只是“沒有時(shí)間好好寫一個(gè)查詢優(yōu)化器”。OceanBase的1.0版本，重點(diǎn)重構(gòu)了整個(gè)優(yōu)化器的架構(gòu)，引入了幾十種邏輯改寫和基于代價(jià)的計(jì)劃選擇，沒有這個(gè)基礎(chǔ)，我們不可能跑出今天TPC-H的這個(gè)性能。

其次，執(zhí)行引擎的設(shè)計(jì)要求與TP天然不同，AP系統(tǒng)要訪問大量的數(shù)據(jù)，迭代數(shù)據(jù)的效率極為關(guān)鍵。這個(gè)領(lǐng)域也是近十年來數(shù)據(jù)庫(kù)研究的重點(diǎn)，從“火山”模型到“數(shù)據(jù)流”模型、從“拉”數(shù)據(jù)到“推”數(shù)據(jù)、cache-aware、即時(shí)編譯（Just-in-time compilation），各種技術(shù)令人眼花繚亂。

OceanBase的最新3.0版本引擎與之前的最大不同在于引入了新的cache-aware向量化處理，在大數(shù)據(jù)量場(chǎng)景下有數(shù)倍的性能提升。當(dāng)然，我們還要清醒的看到，OceanBase的引擎性能距離很多優(yōu)秀產(chǎn)品還有明顯的差距，這個(gè)方向的工作才剛起步。

第三個(gè)挑戰(zhàn)，在于HTAP里面的H，Hybrid，混合。AP和TP是技術(shù)要求上天然不同的兩類請(qǐng)求，典型的TP的場(chǎng)景是簡(jiǎn)單請(qǐng)求、小數(shù)據(jù)量、高并發(fā)，關(guān)注重點(diǎn)在系統(tǒng)的吞吐量。

而AP場(chǎng)景則是復(fù)雜查詢居多，運(yùn)行時(shí)間長(zhǎng)，更多關(guān)注響應(yīng)延遲。這就像是田徑項(xiàng)目中的短跑和長(zhǎng)跑，對(duì)運(yùn)動(dòng)員肌肉類型、反應(yīng)速度、耐力都有不一樣的要求。一個(gè)好的HTAP系統(tǒng)，能在一個(gè)系統(tǒng)里把很多TP、AP的請(qǐng)求同時(shí)解決掉，就相當(dāng)于在培養(yǎng)一個(gè)運(yùn)動(dòng)員，既能跑一百米的短跑，又能跑一萬(wàn)米或者是馬拉松。好比博爾特，100米短跑的王者，但今天還要博爾特跑進(jìn)一萬(wàn)米的世界決賽，難度可想而知。

因此，考驗(yàn)一個(gè)HTAP系統(tǒng)，往往不是一個(gè)單一的維度，而是看如何在去做技術(shù)的妥協(xié)，這個(gè)是考驗(yàn)我們整個(gè)技術(shù)的能力。OceanBase今天已經(jīng)應(yīng)用在很多TP為主的核心場(chǎng)景，我希望做到的是AP能力的盡量能的延伸，我們今天在TPC-H測(cè)試中做了很多優(yōu)化，但我們?cè)赥P場(chǎng)景的性能并沒有出現(xiàn)回退。

另外，一旦將TP和AP的請(qǐng)求放在了同一個(gè)系統(tǒng)，意味著系統(tǒng)對(duì)于不同請(qǐng)求的資源使用要非?！昂侠怼辈⑶冶M量互不影響。困擾數(shù)據(jù)庫(kù)開發(fā)人員的一個(gè)難題是，當(dāng)TP和AP請(qǐng)求混布時(shí)，兩者之間的互相影響很難被“隔離”，今天“隔離”問題仍然是影響用戶選擇HTAP系統(tǒng)的一個(gè)重要挑戰(zhàn)，我們將不同的資源在內(nèi)部進(jìn)行了虛擬化，并通過資源組的概念將TP、AP請(qǐng)求進(jìn)行隔離，一定程度上解決了這個(gè)問題，但HTAP如何徹底的解決這些問題，還有很多有待探索的空間。

類似的問題還有很多，限于篇幅，只能先說這么多。但我認(rèn)為任何一個(gè)真正的HTAP數(shù)據(jù)庫(kù)，至少要能夠比較好的解決上面提到的三個(gè)方面的挑戰(zhàn)。

四、HTAP的邊界在哪里？未來OceanBase的方向在哪里？

過去大家提到OceanBase，第一反應(yīng)就是一個(gè)典型的TP處理系統(tǒng)，具有很強(qiáng)的高可用和線性擴(kuò)展的能力。TPC-H打榜成績(jī)以后，身邊的很多朋友都問過我這樣一些問題：

• 作為一款HTAP數(shù)據(jù)庫(kù)產(chǎn)品，OceanBase未來有哪些是無(wú)法支持的？

• OceanBase會(huì)不會(huì)主張One size fits all？

• OceanBase會(huì)不會(huì)走自己的路，讓別人無(wú)路可走？

換句話說，HTAP的產(chǎn)品邊界到底在哪里？說實(shí)話，我對(duì)這個(gè)問題沒有直接的答案。

但有幾點(diǎn)想法想和同行、客戶分享。

首先，一個(gè)既能處理TP又能處理AP的數(shù)據(jù)庫(kù)系統(tǒng)，可以大大簡(jiǎn)化系統(tǒng)的復(fù)雜性，是有不可否認(rèn)的客戶價(jià)值的，這點(diǎn)是HTAP產(chǎn)品的立足之本，也是我們做產(chǎn)品的初心。

因此，一個(gè)HTAP系統(tǒng)如果本身的處理能力不足或者使用起來很復(fù)雜，也是不能滿足用戶期待的，OB過去兩年一直在嘗試降低用戶的使用成本，就是希望不管是大型客戶還是中小型客戶，是金融客戶還是非金融客戶，都能用的起，用的簡(jiǎn)單，甚至用的爽，這個(gè)方向很關(guān)鍵，未來也會(huì)繼續(xù)堅(jiān)持下去。

其次，每款HTAP產(chǎn)品都有自己的定位。盡管OceanBase拿到了還不錯(cuò)的TPC-H的成績(jī)，但我們的AP處理能力距離世界頂級(jí)數(shù)據(jù)庫(kù)還有不小的差距，未來還需要繼續(xù)努力。

剛才也提到了，OceanBase起步于企業(yè)核心場(chǎng)景的分布式數(shù)據(jù)庫(kù)，TP場(chǎng)景的處理能力將永遠(yuǎn)是OceanBase堅(jiān)持的底線和優(yōu)化方向。換句話說，我們不會(huì)以犧牲TP場(chǎng)景的能力為手段，提升AP場(chǎng)景的處理能力，這和很多以AP為核心場(chǎng)景的產(chǎn)品定位會(huì)有所不同。

最后，HTAP數(shù)據(jù)庫(kù)只能在技術(shù)層面解決TP和AP場(chǎng)景混合的問題，但HTAP的技術(shù)不能完全替代獨(dú)立數(shù)據(jù)分析系統(tǒng)，比如當(dāng)數(shù)據(jù)的源頭來自于很多獨(dú)立數(shù)據(jù)庫(kù)系統(tǒng)甚至各種各樣的日志、傳感器等數(shù)據(jù)源時(shí)。

就像Gartner提到的，Hybrid Transaction/Analytical Processing (HTAP) is an emerging application architecture that breaks the wall between transaction processing and analytics. It enables more informed and in business real time decision making。說白了，這是一種架構(gòu)選擇，而只有給客戶帶來實(shí)實(shí)在在的商業(yè)價(jià)值，這個(gè)架構(gòu)才算是真的成功。

對(duì)于OceanBase這樣一款數(shù)據(jù)庫(kù)產(chǎn)品，選擇HTAP這樣的技術(shù)方向意味著要克服更多困難。路還很長(zhǎng)，好在11歲的OceanBase還很年輕，還有很多機(jī)會(huì)，很多希望。（雷鋒網(wǎng)雷鋒網(wǎng)雷鋒網(wǎng)）

相關(guān)文章：

阿里核心技術(shù)成員解讀自研數(shù)據(jù)庫(kù) OceanBase

OceanBase刷新世界紀(jì)錄，支付寶再闖“無(wú)人區(qū)”

雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。