陽振坤：OceanBase 資料庫七億 tpmC 的關鍵技術

OB君：2020年9月25日，OceanBase在外灘大會舉辦的“資料庫，新標杆，新徵途”分論壇正式落幕，內容涵蓋資料庫的趨勢探討、分散式資料庫的技術創新與行業應用，及國內資料庫的發展與生態。歡迎持續關注本系列內容~

北京奧星貝斯科技有限公司 CTO 兼 OceanBase 資料庫創始人 陽振坤，在外灘大會上分享了 《OceanBase 資料庫七億 tpmC 的關鍵技術》的主題演講，以下為演講實錄：

聯機事務處理（OLTP）系統

很多人都清楚事務的 ACID 特性，知道事務要滿足 原子性、 一致性、 隔離性和 永續性，這是從資料庫本身的角度來看。但是，如果站在業務的角度，客戶對資料庫其實有更高的要求，第一個要求是 資料不能錯，交易資料是企業所有資料的基礎，是最核心的資料，這是企業的命脈。

第二個要求是 服務不能停 ，比如最早期的支付寶在後半夜沒有業務訪問或者業務訪問量很少，如今支付寶24小時都有訪問，每日高峰的時候峰值甚至比早年的雙11還高。所以服務是永遠不能停的。

 

第三個要求是 事務高併發處理能力，因為很難預算出有多少使用者在同時使用，所以這就需要資料庫有高度併發處理的能力。全世界有非常多的資料庫廠商，近年來也進入了國產資料庫的繁榮時期，但是翻過這座山真正能夠把這套系統做到生產中使用的其實少之又少。

TPC-C 基準測試 

TPC-C benchmark 誕生於上個世紀80年代，ATM 自動提款機問世以後，資料庫廠商都希望推銷自家的聯機交易處理系統。各個資料庫廠商在聯機交易處理的 benchmark 上各自為政，沒有統一的規範，各自的 benchmark 結果既缺乏足夠的說服力，使用者也無法在各個系統之間進行參照和對比。

 

TPC 組織的創始人 Omri Serlin 說服了8家公司成立 TPC 組織，共同制定資料庫的系列 benchmark 測試標準並對測試過程和結果進行審計和認證。 TPC-C 是其中的聯機交易處理的測試標準，也是國際上最重要最權威的測試標準。TPC-C 模型本身看起來似乎很簡單，也就是九張表、五種事務。但正是這個看似簡單的模型，卻很好了抽象了直到今天的各個行業業務系統，包括電子商務、銀行、商場、交通、通訊、政府、企業等等。

 

TPC-C 的測試和審計是一個特別嚴格的過程。TPC-C 審計要求首先做功能的驗證，也就是資料庫事務的 ACID，功能驗證透過了才能跑效能。跑效能則有兩個要求： 第一，要求8小時穩定執行，沒有任何人工干預；第二，效能測試至少進行2小時且期間的效能波動不超過2%。這一定程度上證明了系統的穩定和可靠性。

 

過去從來沒有分散式資料庫做過 TPC-C 測試。鑑於 OceanBase 儲存架構的特殊性，OceanBase 的效能測試是8小時而不是通常的2小時，因此 整個8小時中效能波動不能超過2%。

可能有人會說，我可以用很少的資料也能跑出很高的效能，這個資料可以在 CPU 的快取裡，但這是 TPC-C 所不允許的，因為 TPC-C 測試對應的是實際業務場景。在實際業務中，使用者數越多，效能越高，資料量也越大。所以，TPC-C 要求 效能與資料量成正比。這裡我們需要提到 TPC-C 的一個基本概念——倉庫，每個倉庫最高只允許12.86個tpmC，大致換算一下，相當於一個  tpmC  對應5.44MB的資料。

 

另外有一個看起來很寬鬆的要求， 不限制測試的軟體和硬體的版本和型號， 也不限制軟體硬體的數量和規格，但配置和價格必須是公開的，且在市場上可購買的。那麼有人會問是否只要堆越多的機器，就能達到越高的效能呢？對於交易處理系統，其實並沒有這麼簡單。

為什麼沒有分散式 OLTP 資料庫產品？

很多人大學裡學過分散式事務，有人說兩階段提交如果2臺機器能夠做，3臺、4臺、5臺機器也能做，那麼用100臺、1000臺機器，是否就能跑出更高的效能？

 

可能很多人沒有仔細去想這件事，分散式事務兩階段提交其實是理論上的結果，而且這基於很強的假設—— 假設硬體不出故障，尤其儲存不出故障。

 

那我們看看下面這個模型，假設 A 給 B 轉 100 元錢，原來 A 有 900 元，B 有 500 元，轉賬後應該 A 有 800 元、B 有 600 元，這是很簡單的一個流程：第一階段做準備工作，檢查一下 A 賬戶是否正常，同時檢查 B 帳戶是否正常，任何一個不滿足轉賬條件，轉賬交易就要被取消，如果兩個賬戶都正常，那就通知 A 扣 100 元，通知 B 加 100元。

這個過程看起來一切都很正常，但是如果其中有一個結點比如 A 這個結點壞了，這怎麼辦？B 這個結點的 100 元加還是不加，仔細分析加也不對，不加也不對。假如 A 徹底壞掉了，就沒有人知道它曾經做過這筆交易，如果 B 加了這 100 元，A 這裡沒減，這個帳就不平了。那反過來如果 A 這個節點過一會兒又正常了，B 這個節點不加這 100 元也不對，因為 A 的 100元減掉了，B 的100元沒有加。那麼看起來很簡單的一件事，其實做起來就變得很困難。所以事務處理不是簡簡單單靠堆機器就可以堆出來的。

那麼，又有人會問如果給這兩個結點各建一個備庫，出了問題用備庫來頂上行不行？答案也是否定的。因為主備映象無法做到主庫與備庫完全一致，你要想做到完全一致，意味著每一筆事務都需要從主庫同步到備庫，這時候整個系統的可用性的鏈路變長了。對於銀行和企業來說，這是一個生死兩難的問題，要保證同步，就面臨著業務不可用的風險。 所以，主備一致性與服務可用性兩者不可兼得 。

OceanBase 的誕生契機

我們前面講了，交易型資料庫很難做，而且做了市場上很可能沒有使用者敢用，何況它的各方面投入也會很大。而 OceanBase 的誕生和發展得益於有了千載難逢的 天時地利與人和 的機遇。

“天時” 是網際網路的爆發式增長對資料庫的高併發、大資料量提出了很高的需求，而傳統關聯式資料庫難以滿足這個需求； “地利” 是阿里巴巴內部從淘寶到支付寶擁有大量使用資料庫的場景，OceanBase 可以從不是特別關鍵的應用場景開始嘗試，一步步地將資料庫做到關鍵系統； “人和” 是當時單機資料庫已經走到了盡頭，下一步一定是走向分散式，而當時團隊成員恰好具備分散式技術背景。這幾個條件一起促成了 OceanBase 的誕生。

OceanBase 的技術架構

多數派(Paxos)協議

分散式資料庫一定會面臨分散式事務，面臨兩階段提交，普通兩階段提交解決不了這個問題，也分析過之所以出問題是因為對節點的可靠性做了假設。可以回想一下，如果剛才兩階段提交中結點都不出問題，那麼兩階段提交是可以工作的。

OceanBase 是怎麼解決這個問題的呢？OceanBase 的做法是在原有的基礎上增加一個備庫，主庫同步事務到兩個備庫，只要一個備庫收到，加上主庫自己至少兩個庫收到，這樣如果兩個備庫相當於三個結點三個副本，如果四個備庫相當於五個結點五個副本。你壞一個甚至兩個結點，資料還在，整個系統可以正常完成兩階段的提交工作。

OceanBase 分散式事務實現

我們以三個結點三個副本為例，哪怕壞了一個結點，剩下兩個結點每一筆事務至少在其中一個結點上存在，那麼可以利用這一點把剛才沒有進行完的事務或者進行中的事務恢復出來，只要恢復出來事情就可以做下去，兩階段的提交就可以正常結束。

三代 TPC-C 排行榜榜首

去年 OceanBase 第一次 TPC-C 測試之後，有一些的噪音，大家說你跟九年前的結果比算不了什麼，其實是這些人並不瞭解 OceanBase 登頂背後的真正意義。

OceanBase 的 TPC-C 測試的立項是2018年8月16日，立項前討論這個事情的時候，大家有一定的擔心，因為從人力物力各方面來看都是比較大的投入。討論之後定了兩步走的策略，第一步做小一點的規模，目的是把這條路先走通，因為當時全世界還沒有廠商用分散式資料做過 TPC-C 測試。後來用了200多臺的資料庫伺服器，經過半年多的時間，最終透過了這個測試。TPC-C 委員會的人對於傳統的集中式資料庫很熟悉，但分散式事務處理資料庫，他們也沒有接觸過。

第一次 TPC-C 測試透過之後，第二次測試的準備就開始了。因為有了第一次測試的經驗，第二次的測試結果是在意料之中的。或許有人會問集中式資料庫是否還能跑出更高的效能？眾所周知，資料庫的效能，受制於兩個瓶頸，一個是 CPU，另一個是 IO。三代 TPC-C 榜首中，第一和第二代的榜首是傳統資料庫的代表。第三代榜首是 OceanBase，達到了7億多 tpmC，比二代高了一個數量級 。在分散式環境下，OceanBase 的儲存是本地盤，這個 IO 能力比共享儲存的萬兆網路卡要更強，最關鍵是沒有數量上的限制，無論是 CPU 還是硬碟數量。

新一代 HTAP 原生分散式關聯式資料庫

講到這裡，可能會有人說，分庫分表也可以解決你說到的類似問題。是的，確實會解決一些問題，但有些是很難解決的，比如分庫分表後是多個資料庫，這多個資料庫要保持 ACID 就非常困難。如果原來的資料庫是單一資料庫，就需要重新設計和規劃整個系統。有人混淆分散式資料庫的概念，把分庫分表也叫分散式，但其實它不是分散式資料庫，因為它是多個資料庫而不是一個資料庫，也不滿足 ACID 。

分庫分表方案缺乏全域性索引和唯一ID，因為它不再是單個資料庫。還要對業務做拆分，有個拆分維度，比如買家維度，那麼業務上需要對賣家的維度進行處理怎麼辦？因為賣家的資訊會遍佈所有分庫，如果做簡單的統計還可以進行，但如果涉及事務的處理是沒有辦法進行的。 分庫分表方案雖然可以解決一些問題，但也帶來更多的挑戰，更大的複雜性和更高的成本。

作為一款原生分散式關聯式資料庫，OceanBase 本身可以做到水平擴充套件，不需要重新拆分業務，我們可以在主庫做交易處理，在備庫做資料分析處理。甚至在未來可以在主庫上同時完成交易和分析的處理。這一技術上的革新很好地克服了分庫分表方案的弊端。

原生分散式是資料庫的未來

如今的海量資料處理系統，不論是大資料系統還是資料倉儲，它們都是分散式——原生分散式。但是我們再看關聯式資料庫尤其是 OLTP 資料庫，目前它仍然是單機/集中式的。不是 OLTP 資料庫不需要分散式，而是分散式的 OLTP 資料庫的研製非常困難。

 

有很多客戶說，分散式是很好，但是今天分散式的生態不夠成熟，不如集中式資料庫的生態。回想起150年前，汽車剛剛被發明，馬車還是最主流的交通工具，當時在馬路上優先通行的是馬車，汽車也沒有生態。而到了2020年的今天，作為主流交通工具的馬車已經成為遠古的過去，汽車早就成為了不可逆轉的主流。