OCEANBASE的王者攻略

前一段時間阿里的OCCEANBASE拿下TPC-C排行榜的冠軍消息傳來,隨即就在圈內引發熱議,由於位列第二名的甲骨文實際的測試時間是在2011年,而且兩者的性價比還差不多,所以不少網友認爲這隻國產數據庫在硬件設備方面的一次勝利,而並非從核心技術方面打敗了甲骨文、IBM等老牌數據庫公司。

筆者本着“Talk is cheap,show me the code”的精神,在第一時間撰文從代碼角度說明阿里的技術優勢(詳見《200行代碼告訴你OCEANBASE的速度源頭》),而近日筆者通過對於測試報告的仔細研究,發現在TPC的通關過程中絕非僅靠簡單的硬件堆積就能達成,需要總結的地方很多。

愛因斯坦曾經說過“如果你不能用最簡單的語言描述清楚一件事,那麼你還沒有真正瞭解他”所以接下來筆者爭取繼續使用最通俗的語言向大家解釋一下阿里OCEANBASE的TPC通關之路

速度VS整體:從基本概念說起

TPC是國際事務處理性能委員會的簡稱,其中TPC-C是其中一個認證標準,這個標準要求非常嚴格,大到性能、功能、數據一致性和容災能力,小到測試過程中使用過的鼠標鍵盤價格,都需要嚴格披露,確保測試可復現且與真實業務場景保持一致。其測試模擬商品交易,包含五種事務:NewOrder 創建新訂單(佔比 n/a)、Payment 支付訂單(佔比>=43%)、OrderStatus 查詢最近訂單(佔比>=4%)、Delivery 批量配送訂單(佔比>=4%)和 StockLevel 庫存狀態分析(佔比>=4%);並且要求最終要保證產生 10% 的“訂單創建”事務和 15% 的“訂單支付”事務要操作兩個及以上的倉庫。

如果用賽車的方式類比,那麼TPC就是賽車拉力委員會TPC-C就是一級方程式錦標賽。除了比拼速度之外,還要對賽車的轉彎(整體協同能力)、換胎(故障恢復性能)、故障概率等等方面進行比拼,絕不是簡單的直線競速。

傳統數據庫廠商VS互聯網新貴:賽車都有自己的策略

爲了保證賽車的彎道性能(整體的協同能力)並儘量減少換胎次數(高可用性)傳統廠商往往傾向於使用單臺強勁發動機的競爭策略,不過單發賽車的劣勢也非常明顯他們非常容易被發動機的瓶頸所限制。因以阿里爲首的互聯網選手更傾向於推銷他們極致的速度體驗,所以他們更傾向於使用多臺發動機聯動的方式,不過多發也必然會損失部分協調性,所謂韓信點兵,多多益善,能把各方捏合成整體,是兵神才能達到的境界,管理節點的增加會把複雜任務的協調難度以幾何級數增長。

所以正如咱們前文所說TPC-C的這樣一個複雜的賽道上,單純進行硬件的累積,其實起不到太大作用。那麼下面就我們就來詳盡分析一下各方選手的情況。

Oracle VS OCEANBASE:軟、硬件平臺優勢幾何

一、硬件平臺各有優勢:之前有不少網友吐槽使用今天的硬件和11年的硬件做比拼本身就不公平。不過筆者在仔細瞭解了相關情況後有以下情況需要說明:

  1. OCEANBASE的硬件投入不高:很多網友可能注意到Oracle與Oceanbase的性價比其實差不太多,但是仔細分析分析報告會發現,此性價比並不是硬件性價比。TPC的測試投入會發現,它分爲軟件與硬件兩部分。其中硬件價格代表數據庫的測試硬件成本,軟件價格代表商業數據庫的利潤。據測試報告顯示OceanBase 本輪測試的硬件價格佔比還不到 18%遠低於Oracle的65%。
  2. Oracle使用頂配的專用設備,OCEANBASE則使用普通的通用平臺:Oracle對於TPC的硬件平臺可謂下足了功夫,共動用了108 顆 T3 SPARC 處理器,共有 1728 個物理核心和 13824 個執行線程,同時使用了97 臺 COMSTAR 專用存儲設備,這些存儲設備都經過專門的優化,使用Intel 服務器作爲存儲機頭,共有194 顆 Intel X5670 CPU,2328 個物理核心。而反觀OCEANBASE則直接使用204 臺 ECS i2 阿里雲服務器,而並未使用專門存儲。

因此我們瞭解到OCEANBASE的總體硬件成本其實不高,而且也別起用專用的存儲設備來滿足高可用及性能需求。所以通俗來講使用的是11年頂配的專用發動機組成的精英賽車,而OCEANBASE僅使用最新的通用發動機組成的普通賽車,在硬件方面可謂各有優劣。

二、軟件方面OCEANBASE確有獨到之處

由於Oracle並未開源,所以僅從結果而言OCEANBASE的確是做到了遠超Oracle速度。我們之前《200行代碼告訴你OCEANBASE的速度源頭》也曾經解讀過OCEANBASE的緩存機制與過濾器機制。這裏我再來談談其它的點:

優秀的一致性協議Paxos直白的講,Paxo就是少數服從多數的協議,即超過半數成功即算成功的算法,這與之前傳統廠商要求的所有節點強一致的算法有較大不同。在三臺節點組成集羣時,當其中兩臺機器完成後,事務即可完成提交,剩下的一臺機器通常情況下,也是立即就持久化完成了。但如果這臺機器碰巧出現異常,也不會影響事務的提交,系統會在其恢復後自動補齊所缺失的 Redo Log。如果機器永久故障,系統會將故障機器所應負責同步的數據分散給集羣內的其他機器,這些機器會自動補齊所缺失內容,並跟上最新的 Redo Log 寫入。

精確的時間同步服務:OCEANBASE使用了GTS(Globe Timestamp Service),來對所有節點提供集中式服務,我們知道在行軍打仗的過程中大家進行對錶是不必可少的步驟,如果各節點之間的時間不一致,就造成命令執行的順序出現問題,OCEANBASE的GTS是使用上文提到的Paxos協議組提供服務的,這樣既避免的單點風險,又提升了整體的響應速度。

 

 

 

後記

通過本文相信各位讀者們可以看到如果把TPC-C比做一級方程式,那麼OCEANBASE則相當於一臺普通的多發賽車,雖然比高富帥的老爺車新一些,但也談不上佔了多大便宜,不過他的駕駛員技術非凡,在多發協同操控等方面做出了很多突破性的工作。我們也可以看到目前除了國產的操作系統,國產的優秀數據庫如TDENGINE和OCEANBASE也迎來一波熱潮,其中很多技術上的創新是非常值得稱讚,願我們的國產基礎平臺越做越好,筆者也會繼續爲各位讀者帶來理性解讀。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章