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

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

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

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

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

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

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

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

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

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

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

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

OceanBase TPC-H項目組

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

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

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

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

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

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

70年代末到80年代初，有“數(shù)據(jù)庫先生”之稱的圖靈獎獲得者Jim Gray奠定了事務(wù)處理的理論基礎(chǔ)。同一時期，System R系統(tǒng)的實現(xiàn)也催生了查詢優(yōu)化技術(shù)。Selinger等人發(fā)表的“Access Path Selection in a Relational Database Management System”論文則被認(rèn)為是基于代價的查詢優(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)用提升到了一個新的層面?？梢哉f，在數(shù)據(jù)庫遠(yuǎn)古大神一個個粉墨登場的年代，TP和AP兩種場景就像一對被他們細(xì)心呵護(hù)的孿生兄弟茁壯地成長著。

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

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

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

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

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

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

二、OceanBase 把HTAP寫入基因

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

回想當(dāng)初，數(shù)據(jù)庫的很多技術(shù)都在悄悄發(fā)生著變化。一方面，以O(shè)racle為首的傳統(tǒng)數(shù)據(jù)庫在TP場景似乎已經(jīng)“獨孤求敗“，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è)計。TPC-H榜單上，Oracle、SQL Server這種傳統(tǒng)數(shù)據(jù)庫被神秘的數(shù)據(jù)庫廠商Exasol虐的找不著北。Exasol具體怎么實現(xiàn)的我不是特別清楚，但向量化引擎、cache-aware、列存、及時編譯（Just-in-Time compilation）,大致總離不開這幾個方向。但傳統(tǒng)數(shù)據(jù)庫不是這么設(shè)計的，內(nèi)存能大到幾百GB甚至上TB？最初的數(shù)據(jù)庫設(shè)計者想都不敢想，更別提充分利用了，“守著金山要飯吃”，當(dāng)時的傳統(tǒng)數(shù)據(jù)庫看到硬件的發(fā)展就是這么一種感覺吧。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• OceanBase會不會主張One size fits all？

• OceanBase會不會走自己的路，讓別人無路可走？

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

但有幾點想法想和同行、客戶分享。

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

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

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

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

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

就像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)選擇，而只有給客戶帶來實實在在的商業(yè)價值，這個架構(gòu)才算是真的成功。

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

相關(guān)文章：

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

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

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