三次刷榜TPC，OceanBase向世界證明中國資料庫也能行

題圖：來自TPC官網截圖

當前，號稱HTAP的資料庫不少，但是OLTP和OLAP（以下簡稱：TP和AP）任意一方面做好的其實並不多，更何況是兩方面都做的不錯的。

不過，OceanBase可以算是一個。

為什麼這麼說？因為，OceanBase又打榜了。

每家資料庫廠商都試圖向客戶證明自己的系統效能最好、處理能力最強，但資料庫廠商各自的效能測試資料，沒有足夠的說服力。

這時候，TPC的價值就體現出來了。TPC作為資料庫領域benchmark世界最權威的測試基準（不是給錢就能過的，需要經過嚴苛測試流程、審計及公示，一次打榜長則半年，短則數月），因此，在業內被廣泛接受。在國內，曾經金融，電信，政府等行業POC都以TPC為效能測試基準。

事實上，國內這幾年也在搞類似的標準，但目前看，還差點火候，距離被廣泛接受還需要一些時間。至於，其他廠商說跑分沒意義，顯然是有點酸。

繼2次打榜TPC-C證明自身OLTP能力之後，OceanBase再次打榜，不過，這次打的是TPC-H，並以1526萬QphH的效能總分創造了新的世界紀錄，成績是現在榜單（V3）上的第二名10倍多！

本文重點不在此次打榜過程及故事，都第三次打榜了，大家看膩味了，老魚也寫膩味了，本文關鍵在於解析OceanBase此次打榜的目的？OceanBase為什麼要做HTAP，又是如何支援HTAP的，這其中OceanBase有著怎樣的思考。

在獲知TPC結果的第一時間，老魚採訪了OceanBase創始人兼首席科學家陽振坤和OceanBase研發中心資深總監陳萌萌。

TPC-H是一個偏OLAP場景的基準測試，反映了系統處理查詢能力的多個方面。

陳萌萌告訴老魚，OceanBase在TPC-C登頂之後再次打榜TPC-H，是希望使用者能夠對OceanBase在OLAP場景的一些能力有進一步瞭解，也是進一步貫徹OceanBase產品的HTAP定位。

OceanBase立志成為一個世界級的通用關聯式資料庫。其產品定位在2.0後就很清晰，其存在就為解決企業客戶三大難題，第一大難題是可擴充套件性，第二難題是高可用，第三大難題是混合事務/分析處理（HTAP）。而AP能力與TP能力一樣，並不是突然出現，是一個漸進的過程，在2.0版本後，AP能力開始逐步發展。

目前，號稱HTAP的資料庫不少，但是TP和AP任意一方面做好的其實並不多，更何況是兩方面都做的不錯的。

因為，單一的AP分析系統，只需要關注AP，資料也是按業務需求生成的，所以通常產生報表速度更快，但缺點是，一旦業務需求發生較大的變化，需要重新拉取資料；HTAP系統，需要同時兼顧TP和AP，其AP分析也更加困難，這也是為什麼兩個都做的好很難的原因，但好處是，即使業務需求發生了很大的變化，也不需要重新拉取資料，因為資料已經在系統中了。

為什麼OceanBase能做HTAP，陽振坤說，因為要能夠產生報表（AP），那麼，系統的容量必須足夠大，這隻能是分散式資料庫，而這個系統還需要有真正的TP能力，即得是真正的分散式交易資料庫，而市場上的AP系統， TP處理能力普遍非常弱，根本不足以作為一個交易處理資料庫。

OceanBase是一個真正的分散式資料庫，首先展示和被驗證的，是其TP能力，最近幾年，OceanBase的AP能力也在螞蟻內部和外部得到了驗證。因此OceanBase的HTAP產品和技術能力，其實是領先的。

2014 年 1 月 28 日，Gartner 在《混合事務/分析處理促進重大商業創新》報告中，對HTAP資料庫給出了明確的定義。HTAP資料庫需要同時支援 OLTP 和OLAP 場景。HTAP迅速成為引起一些企業的關注，被很多人視為未來資料庫領域發展趨勢之一。

HTAP並不是要徹底取代傳統TP或AP資料庫，HTAP有自己的市場。

陽振坤告訴老魚，客戶對銷售狀況和業務收入等各種報表的實時性要求越來越高，透過ETL（資料抽取轉換載入）從交易資料庫(TP)系統同步資料到資料倉儲或大資料系統，然後產生報表，不可避免地存在較大的延遲，從數小時到數天不等，進一步縮短這個延時的代價非常大。在交易資料庫上直接生成報表，即HTAP，天然沒有任何延遲，是最符合業務需求的。這也是OceanBase為什麼要做HTAP的原因所在。

對於OceanBase是如何支援HTAP的，此前，OceanBase CTO、團隊創始成員楊傳輝在《 OceanBase CTO 楊傳輝：下一代企業級分散式資料庫的一體化設計》一文中，有所提及。

HTAP 也是分散式資料庫領域的一個熱門概念。

有兩種做法： 

第一種是主備庫物理隔離，主庫做 OLTP，備庫做 OLAP，主備之間透過 redo 日誌做同步，備庫與主庫之間有一定的延遲。第二種是在同一套引擎實現 OLTP 和 OLAP 混合負載，區分 OLTP 和 OLAP 請求所在的資源組，對資源組進行邏輯隔離。

第一種方案實現相對簡單，但由於產生了更多資料冗餘，價效比較低；第二種方案實現相對複雜，但採用一體化設計，價效比更高。第二種方案來自經典資料庫，例如 Oracle、SQL Server。

我認為，企業級分散式資料庫應該學習 HTAP 技術，採用第二種方案。

很顯然，OceanBase採用的第二種。也就是說，OceanBase自研了一套引擎同時支援了OLTP和OLAP，這是與其它HTAP資料庫差異化的體現，比如當紅炸子雞TiDB，使用的就是兩套引擎。OLAP引擎魔改自ClickHouse，OLTP引擎基於KV。

陳萌萌告訴老魚，OceanBase當前的OLAP能力已經實現了很多複雜的決策支援的查詢，報表的製作等。

那麼，OceanBase到底能兼顧怎樣程度的OLAP？陳萌萌說，OceanBase當前的OLAP能力以結構化資料為主（暫時還不支援JSON、圖、全文索引等大資料分析），覆蓋了一些比較常見的SQL功能，包括CTE（with語句）、視窗函式、多表連線（小於15張表）、聚合、子查詢、層次查詢等等。

從決心做一個通用關聯式資料庫開始，OceanBase團隊就很清楚，不可避免的需要直面市場傳統關聯式資料庫的競爭，作為後來者，假如OceanBase硬體價效比沒有高出市場上主流商業關聯式資料庫一個數量級，假如OceanBase不能做到傳統商業資料庫做不到的事情，比如主庫故障時備庫資料不完整、水平擴充套件能力缺失等等。那麼，OceanBase很難會有明顯競爭優勢。

三次刷榜TPC，並三次打破世界紀錄，倔強的OceanBase無疑是在用成績向世界證明，中國資料庫也能行，OceanBase不僅能做到傳統關聯式資料庫能做到的事，也能做到傳統關聯式資料庫做不到的事，而且是世界級的。

畢竟，資料庫競爭光靠情懷、政策是不行的，關鍵還要看技術能力。

不少人覺得OceanBase不接地氣，過於強調世界第一、金融級，整的太高大上，這讓中小規模的企業都不敢去嘗試，怕殺雞用牛刀。其實，這是一種誤解，與傳播策略有關，但與產品本身與技術無關。

確實，OceanBase誕生於螞蟻這種超大規模和超高壓力的應用場景，在最初設計時確實有很多對極限場景的考慮和最佳化，但從開始商業化之後，OceanBase其實已經開始強調更貼近外部真實客戶場景，特別是降低中小客戶的使用門檻。

比如在這次TPC-H測試中，OceanBase除了水平擴充套件能力（多機），也非常強調單機的垂直擴充套件能力，透過向量化引擎、單機並行執行等技術，充分挖掘硬體潛力。

據陳萌萌介紹，在內部非官方的測試中，在幾T甚至更小的資料規模下，OceanBase也能取得不錯的成績。另外，這幾年OceanBase對硬體的要求也一直在降低過程中，從之前的動輒幾十G上百G的最小記憶體規格，降低到現在的十幾G甚至幾G就可以執行，都是為了更好的服務中小客戶，降低使用門檻。

對於一般的中小規模客戶，OceanBase的HTAP能力能夠在一套系統中承載更多的客戶需求，避免獨立TP、AP系統帶來的各種開銷，整體來看使用者的成本是明顯降低的。

陽振坤說，未來，OceanBase希望能夠幫助客戶完全擺脫ETL+資料倉儲/大資料，而首先是中小企業客戶。