Alibaba 螞蟻自研數(shù)據(jù)庫OceanBase登頂TPC-H榜單，核心成員撰文講述背后思考( 四 ) 螞蟻自研數(shù)據(jù)庫OceanBase登頂T

TPC-H測試場景中，要求我們用64臺機器的5120個CPU超線程，同時去服務每一個用戶請求，把本來需要幾十分鐘才能完成的請求，在幾秒內處理掉，這里涉及的CPU核數(shù)和整體性能數(shù)值都是整個TPC-H結果中最高的。
第二個方面是一個真正的HTAP系統(tǒng)需要在TP場景和AP場景都有很強的處理能力。
OceanBase的TP處理能力在TPC-C打榜過程中已經(jīng)得到了驗證，背后的技術也有相關文章詳細解讀，這里不再贅述。那AP場景到底要求的是什么能力？
首先來說是查詢優(yōu)化的能力。AP場景天然有很多復雜的用戶查詢，具體到SQL語句上就是大量的多表連接、復雜的表達式計算、多層嵌套的子查詢、聚合函數(shù)等等，這些對引擎的查詢優(yōu)化能力要求門檻極高。
記得曾經(jīng)一個同行半開玩笑的說，很多專注TP的數(shù)據(jù)庫系統(tǒng)不是不想做HTAP，只是“沒有時間好好寫一個查詢優(yōu)化器” 。OceanBase的1.0版本，重點重構了整個優(yōu)化器的架構，引入了幾十種邏輯改寫和基于代價的計劃選擇，沒有這個基礎，我們不可能跑出今天TPC-H的這個性能。
其次，執(zhí)行引擎的設計要求與TP天然不同，AP系統(tǒng)要訪問大量的數(shù)據(jù)，迭代數(shù)據(jù)的效率極為關鍵。這個領域也是近十年來數(shù)據(jù)庫研究的重點，從“火山”模型到“數(shù)據(jù)流”模型、從“拉”數(shù)據(jù)到“推”數(shù)據(jù)、cache-aware、即時編譯（Just-in-time compilation），各種技術令人眼花繚亂。
OceanBase的最新3.0版本引擎與之前的最大不同在于引入了新的cache-aware向量化處理，在大數(shù)據(jù)量場景下有數(shù)倍的性能提升。當然，我們還要清醒的看到，OceanBase的引擎性能距離很多優(yōu)秀產(chǎn)品還有明顯的差距，這個方向的工作才剛起步。
第三個挑戰(zhàn)，在于HTAP里面的H，Hybrid，混合。AP和TP是技術要求上天然不同的兩類請求，典型的TP的場景是簡單請求、小數(shù)據(jù)量、高并發(fā)，關注重點在系統(tǒng)的吞吐量。
而AP場景則是復雜查詢居多，運行時間長，更多關注響應延遲。這就像是田徑項目中的短跑和長跑，對運動員肌肉類型、反應速度、耐力都有不一樣的要求。一個好的HTAP系統(tǒng)，能在一個系統(tǒng)里把很多TP、AP的請求同時解決掉，就相當于在培養(yǎng)一個運動員，既能跑一百米的短跑，又能跑一萬米或者是馬拉松。好比博爾特，100米短跑的王者，但今天還要博爾特跑進一萬米的世界決賽，難度可想而知。
【Alibaba|螞蟻自研數(shù)據(jù)庫OceanBase登頂TPC-H榜單，核心成員撰文講述背后思考】因此，考驗一個HTAP系統(tǒng)，往往不是一個單一的維度，而是看如何在去做技術的妥協(xié)，這個是考驗我們整個技術的能力。OceanBase今天已經(jīng)應用在很多TP為主的核心場景，我希望做到的是AP能力的盡量能的延伸，我們今天在TPC-H測試中做了很多優(yōu)化，但我們在TP場景的性能并沒有出現(xiàn)回退。
另外，一旦將TP和AP的請求放在了同一個系統(tǒng)，意味著系統(tǒng)對于不同請求的資源使用要非常“合理”并且盡量互不影響。困擾數(shù)據(jù)庫開發(fā)人員的一個難題是，當TP和AP請求混布時，兩者之間的互相影響很難被“隔離”，今天“隔離”問題仍然是影響用戶選擇HTAP系統(tǒng)的一個重要挑戰(zhàn)，我們將不同的資源在內部進行了虛擬化，并通過資源組的概念將TP、AP請求進行隔離，一定程度上解決了這個問題，但HTAP如何徹底的解決這些問題，還有很多有待探索的空間。
類似的問題還有很多，限于篇幅，只能先說這么多。但我認為任何一個真正的HTAP數(shù)據(jù)庫，至少要能夠比較好的解決上面提到的三個方面的挑戰(zhàn) 。
四、HTAP的邊界在哪里？未來OceanBase的方向在哪里？
過去大家提到OceanBase，第一反應就是一個典型的TP處理系統(tǒng)，具有很強的高可用和線性擴展的能力。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)的復雜性，是有不可否認的客戶價值的，這點是HTAP產(chǎn)品的立足之本，也是我們做產(chǎn)品的初心。
因此，一個HTAP系統(tǒng)如果本身的處理能力不足或者使用起來很復雜，也是不能滿足用戶期待的，OB過去兩年一直在嘗試降低用戶的使用成本，就是希望不管是大型客戶還是中小型客戶，是金融客戶還是非金融客戶，都能用的起，用的簡單，甚至用的爽，這個方向很關鍵，未來也會繼續(xù)堅持下去。