簡介：?2021年5月20日，據(jù)國際事務(wù)處理性能委員會(huì)（TPC，Transaction Processing Performance Council）官網(wǎng)披露，螞蟻集團(tuán)自主研發(fā)的分布式關(guān)系型數(shù)據(jù)庫OceanBase在數(shù)據(jù)分析型基準(zhǔn)測(cè)試（TPC-H）中，以1526萬QphH的性能總分創(chuàng)造了新的世界紀(jì)錄。同時(shí)，OceanBase也成為唯一在事務(wù)處理和數(shù)據(jù)分析兩個(gè)領(lǐng)域測(cè)試中都獲得過世界第一的中國自研數(shù)據(jù)庫。

作者 | 陳萌萌
來源 | 阿里技術(shù)公眾號(hào)

寫在前面的話

2021年5月20日，據(jù)國際事務(wù)處理性能委員會(huì)（TPC，Transaction Processing Performance Council）官網(wǎng)披露，螞蟻集團(tuán)自主研發(fā)的分布式關(guān)系型數(shù)據(jù)庫OceanBase在數(shù)據(jù)分析型基準(zhǔn)測(cè)試（TPC-H）中，以1526萬QphH的性能總分創(chuàng)造了新的世界紀(jì)錄。

同時(shí)，OceanBase也成為唯一在事務(wù)處理和數(shù)據(jù)分析兩個(gè)領(lǐng)域測(cè)試中都獲得過世界第一的中國自研數(shù)據(jù)庫。

我們特別邀請(qǐng)到OceanBase負(fù)責(zé)此次測(cè)試的核心成員陳萌萌撰文，講述背后的技術(shù)思考。

以下為陳萌萌的自述。

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

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

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

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

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

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

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

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

70年代末到80年代初，有“數(shù)據(jù)庫先生”之稱的圖靈獎(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ù)倉庫”（以下簡稱“數(shù)倉”）概念。1993年，E. F. Codd仿照“On-line Transaction Processing”的結(jié)構(gòu)首次提出了“On-line Analytical Processing”的概念，一下子把數(shù)據(jù)分析的抽象和應(yīng)用提升到了一個(gè)新的層面。可以說，在數(shù)據(jù)庫遠(yuǎn)古大神一個(gè)個(gè)涌現(xiàn)的年代，TP和AP兩種場景就像一對(duì)被他們細(xì)心呵護(hù)的孿生兄弟茁壯地成長著。

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

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

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

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

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

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

二 OceanBase把HTAP寫入基因

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

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

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

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

從時(shí)間上看，AP場景的幾項(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ǎn)品定位也都需要產(chǎn)品具備這樣的能力，從這個(gè)角度上講，OceanBase正式進(jìn)入到HTAP產(chǎn)品時(shí)代，也是市場的選擇。

從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í)性要求高的分析邏輯無法在TP數(shù)據(jù)庫中原地完成，只能等數(shù)據(jù)同步到AP數(shù)據(jù)庫中再做。另外就是系統(tǒng)難以運(yùn)維，尤其是中小型的客戶，運(yùn)維人員得熟悉兩套系統(tǒng)，還要時(shí)刻關(guān)注中間數(shù)據(jù)鏈路的穩(wěn)定性，技術(shù)門檻很高。

另外一部分用戶，一直使用的是像Oracle這樣的傳統(tǒng)的數(shù)據(jù)庫，對(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)部大家的看法也是不一樣的。只能說有一些場景偏TP類型或者偏AP類型，但很難給出絕對(duì)答案。

越來越多的客戶案例讓我意識(shí)到，過去一直堅(jiān)持的HTAP技術(shù)方向也是很多客戶需要的。但今天在很多客戶眼中，OceanBase就是只支持TP處理的數(shù)據(jù)庫，完全沒想到我們還有很強(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ù)庫就像蓋房子，今天OceanBase這座房子已經(jīng)到了交付階段，要給客戶的體驗(yàn)是“拎包入住”，因此水、電、裝修風(fēng)格都要做好。而2014 年就像在“打地基”的階段，你說我將來要做某某內(nèi)飾風(fēng)格，至少當(dāng)時(shí)沒有想到那么具體的事情，但是我知道分布式一定是這個(gè)房子的“地基”，我們要蓋的是一個(gè)摩天大樓，而不是一個(gè)獨(dú)門小院。這個(gè)是打破傳統(tǒng)數(shù)據(jù)庫設(shè)計(jì)限制的前提，想通了這個(gè)事兒，后面的技術(shù)落地就比較自然了。

為什么分布式數(shù)據(jù)庫是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ù)庫做不到的。一臺(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ù)庫，做到幾百臺(tái)機(jī)器的集群規(guī)模是非常輕松的，這種規(guī)模上的區(qū)別帶來技術(shù)上的想象空間是完全不同的。

而且在這次測(cè)試面向AP的場景中，又引入了一個(gè)OceanBase家族的新成員叫OceanBase File System（簡稱OFS）。這是一個(gè)分布式的共享存儲(chǔ)系統(tǒng)，基于OFS的方案在存儲(chǔ)容量上幾乎是可以無限擴(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ù)庫集群規(guī)模越大，性能分?jǐn)?shù)就越高。但在AP場景下，用戶同時(shí)也會(huì)關(guān)心能不能實(shí)現(xiàn)垂直擴(kuò)展，比如說能不能讓一個(gè)系統(tǒng)的幾千個(gè)CPU核，幾十臺(tái)機(jī)器同時(shí)為一個(gè)查詢服務(wù)。萬事萬物，只要涉及到“協(xié)同“，就有成本。把協(xié)同的成本降低到最低，考驗(yàn)的是系統(tǒng)整體的設(shè)計(jì)。

TPC-H測(cè)試場景中，要求我們用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場景和AP場景都有很強(qiáng)的處理能力。

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

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

記得曾經(jīng)一個(gè)同行半開玩笑的說，很多專注TP的數(shù)據(jù)庫系統(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ù)庫研究的重點(diǎn)，從“火山”模型到“數(shù)據(jù)流”模型、從“拉”數(shù)據(jù)到“推”數(shù)據(jù)、cache-aware、即時(shí)編譯（Just-in-time compilation），各種技術(shù)令人眼花繚亂。

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

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

而AP場景則是復(fù)雜查詢居多，運(yùn)行時(shí)間長，更多關(guān)注響應(yīng)延遲。這就像是田徑項(xià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)員，既能跑一百米的短跑，又能跑一萬米或者是馬拉松。好比博爾特，100米短跑的王者，但今天還要博爾特跑進(jìn)一萬米的世界決賽，難度可想而知。

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

另外，一旦將TP和AP的請(qǐng)求放在了同一個(gè)系統(tǒng)，意味著系統(tǒng)對(duì)于不同請(qǐng)求的資源使用要非常“合理”并且盡量互不影響。困擾數(shù)據(jù)庫開發(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ù)庫，至少要能夠比較好的解決上面提到的三個(gè)方面的挑戰(zhàn)。

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

過去大家提到OceanBase，第一反應(yīng)就是一個(gè)典型的TP處理系統(tǒng)，具有很強(qiáng)的高可用和線性擴(kuò)展的能力。TPC-H成績出來以后，身邊的很多朋友都想了解未來OceanBase會(huì)成為一款什么樣的數(shù)據(jù)庫產(chǎn)品？對(duì)這個(gè)問題，我有幾點(diǎn)想法想和同行、客戶分享。

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

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

其次，每款HTAP產(chǎn)品都有自己的定位。OceanBase起步于企業(yè)核心場景的分布式數(shù)據(jù)庫，TP場景的處理能力將永遠(yuǎn)是OceanBase堅(jiān)持的底線和優(yōu)化方向。換句話說，我們不會(huì)以犧牲TP場景的能力為手段，提升AP場景的處理能力，這和很多以AP為核心場景的產(chǎn)品定位會(huì)有所不同。最后，HTAP是一種技術(shù)架構(gòu)選擇。

就像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.

說到底，HTAP架構(gòu)是希望通過打破TP和AP的邊界，最終帶給客戶實(shí)實(shí)在在的商業(yè)價(jià)值。對(duì)于OceanBase這樣一款數(shù)據(jù)庫產(chǎn)品，選擇HTAP這樣的技術(shù)方向意味著要克服更多困難。路還很長，好在11歲的OceanBase還很年輕，還有很多機(jī)會(huì)，很多希望。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的OceanBase再破纪录！核心成员陈萌萌：坚持HTAP就是坚持我们做数据库的初心的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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