2019年11月19日，螞蟻金服在北京舉辦“巔峰洞見·聚焦金融新技術”釋出會，介紹2019雙11支付寶背後的技術，並重磅釋出全新OceanBase 2.2版本和SOFAStack雙模微服務平臺。我們將系列演講整理併發布在  “螞蟻金服科技” 公眾號上，歡迎關注。

螞蟻金服高階研究員兼 OceanBase 資料庫創始人陽振坤，在釋出會分享了《OceanBase：面向未來的企業級關聯式資料庫》，以下為演講實錄：

10月2日，OceanBase 資料庫 TPC-C 基準測試結果釋出，今天我想跟大家彙報一下它背後的一些東西，然後給大家簡單講一下我們的技術方案，以及給大家介紹 TPC-C benchmark 以及 OceanBase 進行測試認證的一些事情，最後是個簡短的小結。

我們做的是線上的交易處理系統（OLTP），但更大的意義不在於 benchmark 本身，而在於我們改變了關聯式資料庫做交易處理的方法，把它由一個集中式系統，變成一個分散式系統。另外，更大的意義不是 OLTP 本身，而是在 OLAP 上。大家可能覺得奇怪，你做的是 OLTP benchmark，它的價值怎麼會在OLAP上呢？

首先介紹下資料庫和業務應用的背景。可以看到當前的集中式資料庫所面臨的挑戰，要做資料庫產品的研發首先要有業務需求，資料庫經過一些年的發展，到了80年代中期自動提款機出現之後，資料庫非常重要的特性開始得到普遍的應用，就是線上的交易處理。

後續很多年資料庫就圍繞這個繼續發展，之後企業發現還需要商業智慧：需要報表，需要對銷售結果進行探討、進行對比、進行分析等，所以資料庫除了線上交易處理的能力之外，還需要線上分析處理的能力，傳統的商業資料庫在這兩個能力上其實做得非常好。

但最近這些年情況發生了變化，原來由同一個關聯式資料庫做的 OLTP 和 OLAP 這兩件事情變成了由兩個系統來做：關聯式資料庫分庫分表繼續做線上交易處理，資料倉儲則做商業智慧分析即線上分析處理。

為什麼會出現這樣的情況？因為網際網路。網際網路在短短几年時間裡，把整個交易量、資料量翻了幾百倍幾千倍，發展最快的單個硬體仍然趕不上這個速度，單個硬體就算能夠有這個處理能力和容量也肯定不經濟。

這樣一個系統變成兩個系統帶來很大的不便。 首先，資料倉儲本身沒有資料，資料還得從交易處理資料庫來。所以還得架一個橋樑，把資料從交易資料庫透過ETL即抽取、轉換然後載入到資料倉儲，而且這個本質是非實時的，否則的話資料倉儲就成為了交易資料庫。

其次，交易資料庫分庫分表後也帶來了很多挑戰，比如訂單號需要全域性唯一，如果只有一個資料庫這件事情很好辦，多個資料庫是需要在訂單號中加一位代表哪個分庫庫，而每個分庫能做到唯一。當你分庫變成兩位數變成三位數怎麼辦？這是業務擴容，如果是業務縮容呢？所以業務需要做很多的改動。

第三是資料倉儲本身，資料倉儲天然是面向某個主題的，從來沒有聽說過關聯式資料庫面向某個主題，關聯式資料庫就是關聯式資料庫，你可以根據需要建索引，可以根據需要建物化檢視等，但資料倉儲只能是面向某個主題的。如果有多個不同的主題，就要建好多個資料倉儲，儘管可以把相近的主題合併在一起，但這並不能改變資料倉儲面向主題的本質，它會造成大量的資料冗餘。另外一個問題是時效性，因為資料倉儲本質上不是實時更新的。

交易處理資料庫不能擴張，是因為它是集中式。 集中式的根本原因還是由於交易處理最重要的一個特性，即事務的 ACID，原子性、一致性、隔離性、永續性。資料庫發展了半個多世紀，做交易處理的一直都是集中式系統。

另外一個原因是線上交易處理系統要求非常高的可用性、可靠性，分散式系統有一個固有的缺陷就是可靠性：多臺機器在一起的時候，整體可靠性是指數級下降，除非你有特殊的技術。比如當你把一百臺5個9機器放在一起的時候，整個系統只有3個9的可靠性，任何一個關鍵業務都不敢使用3個9可靠性的系統。

這兩個原因使得多年來交易處理的系統一直是集中式。我們做 OceanBase 分散式的交易處理系統的時候，就出現很多的質疑，這個質疑聲一直到去年還有。最後公司下決心說好吧，我們就做一次線上交易處理的 benchmark 的認證，這個 benchmark 不僅是跑分，首先你要證明你的系統能夠做交易處理，能夠滿足事務的 ACID，原子性、一致性、隔離性、永續性，只有透過 ACID 測試才能進行下一步測試，所以這個TPC-C benchmark不是像有人說的那樣，堆砌機器就可以跑個高分的。

假如圖中這個球代表一百塊錢，金融場景裡最常見的是A轉一百塊錢給B。這個轉賬過程最大的困難是它的過程必須是原子的，即沒有中間過程：這個錢只要A這邊轉出去，B一定就收到了；如果B沒有收到錢，同一時刻A一定沒有轉出這個錢。

如果這兩個賬戶在一臺機器上，這個事情可以有比較成熟的做法；如果是在兩臺機器的話，這件事情變得非常困難，怎麼樣協調兩臺機器同一時間做這個事情？資料庫設計者把這個事情做了兩個階段，第一階段要檢查A帳戶，看它能不能轉錢，也要檢查B帳戶，看它是不是存在，是否能夠接收轉入。這些檢查如果有一個不合格轉賬就要取消掉，比方說沒錢拿什麼轉賬；這些檢查如果都合格了就進入第二步：通知A扣一百塊錢，通知B加一百塊錢。

這個做法其實有一個大的缺陷：如果第一階段檢查都是好的，在第二階段A這個機器突然出了一點問題，怎麼辦？B那邊一百塊錢還加不加？按協議第一階段都正常，那麼B的一百塊應該加，但假如A這臺機器徹底壞了，拿一臺備機來，備機沒有這個轉帳資訊，它根本就不知道曾經有這個轉賬，這樣整個系統裡多了一百塊錢出來，不知道哪來的；如果B的一百塊錢不加，假如A這臺機器只是 CPU 負載高、網路特別忙阻塞了一會兒，過一會兒又正常了，把這100塊錢扣掉了，B不加這一百塊錢也不對，所以就出現B加也不對，不加也不對，這導致很多年來沒有分散式資料庫能夠用來做交易處理。

是否有個交易處理的系統能夠做到隨時可以擴充套件也隨時可以收縮呢？這正是2010年公司立項做 OceanBase 的目標。

OceanBase技術方案

OceanBase 專案最早做這件事情首先是有市場驅動的，我們的訪問量、資料量都比以前漲了幾十倍，甚至幾百倍，用傳統的資料庫很困難了，或者說買不起資料庫了。

第二，因為線上交易處理是一個實時系統，不能停，否則大家拿支付寶吃個飯、坐個車都不行。

第三，資料庫的資料還不能出錯，可是軟體哪能沒有 BUG 呢？所以一個做實時交易處理的資料庫系統不只是研發出來的，更是用出來的。當時的淘寶和支付寶就有成千上萬的資料庫，有這麼多的資料庫對於這個專案來講有兩個好處：一是經濟價值足夠大，不用給商業資料庫系統付那麼多錢；二是這麼多的業務提供了一個土壤，讓新的資料庫成長起來。我們總是講農村包圍城市，總能找到相對邊緣一些的業務。

OceanBase專案一開始的時候，就設定了 兩個重要的目標：

1. 這個系統要能夠水平擴充套件；

2. 這個系統必須高可用的，儘管使用普通的硬體。

現在讓我們看看 OceanBase 是如何解決高可用的問題的。

這個圖是傳統資料庫主備映象的示意圖：主庫做事務，並同步給備庫。如果要求備庫跟主庫完全一致，那麼每一筆事務都要實時同步給備庫，如果備庫出現異常或者主備庫之間的網路異常，那麼主庫上的事務就會積壓，並且會在很短時間內撐爆主庫，然後導致業務不可用，這可能比資料差錯更糟糕。大家會問資料倉儲也是分散式，它怎麼不擔心機器壞？根本原因是資料倉儲的資料不是實時更新的，如果出現上面的異常，它可以暫停更新。

我們的做法是增加一個備庫，主庫同步事務到兩個備庫，只要一個備庫收到，加上主庫自己至少兩個庫收到就可以。這個裡面關鍵是多數派，每一筆事務至少在3個庫中的2個庫落地，任何一個庫壞了，哪怕主庫壞了，每筆交易至少在一臺機器上存在。我們透過這個方法，把系統做到高可用。

同時壞兩臺機器的機率，如果是自然損壞確實很低，但如果有人為因素，就不一定了。比如說人為把機器關掉，換一個元件做升級，加上自然損壞，可能出現同時兩臺機器故障。所以比較重要的業務會寫五份事務日誌，有三份資料或者是四份資料。即使人工關掉一臺機器，自然再故障一臺機器，整個業務系統還是可用的。

回到剛才的分散式事務，OceanBase 的方法是：我們把原來的每一個物理節點換成一個 Paxos 組，相當於換成一個虛擬節點，這個虛擬節點背後有三/五個物理節點。根據多數派成功協議，三/五個節點裡有兩/三個節點寫成功這個事務就被判定為成功。實際上使用了這樣一種方式解決了我們提到的萬一有一臺機器故障，兩階段提交就沒辦法推進下去的問題。我們就是透過這樣一些看上去相對簡單的方式解決了分散式事務的問題。

OceanBase 比較早在建設銀行就有了一些業務。螞蟻金服絕大多數的資料庫都在 OceanBase，還有一部分在持續遷過來。阿里巴巴是最早立專案用的，後續包括網商銀行、南京銀行等金融機構也在把一大批業務遷到 OceanBase 上。西安銀行是今年發展起來的業務，已經把Oracle業務遷移到 OceanBase 上。

TPC-C基準測試

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

就在這時，Jim Gray 聯合多位學術界、工業界的權威人士提出了 DebitCredit 標準。標準雖然有了，但是資料庫廠商卻並沒有嚴格按照標準測試，而是肆意篡改標準讓自己跑出更高的結果。這就好比有了法律卻沒有執法的隊伍，每個人都按照自己的理解來解釋法律和執行法律。

Omri Serlin 非常了不起，他說服了8家公司成立 TPC 組織，並且制定了 TPC 系列標準，相當於立法；同時 TPC 組織還負責監督稽核測試過程和測試結果，相當於執法。從這之後，資料庫領域各自為政的 benchmark 才有了一個統一的標準。

TPC 的 Benchmark 後來不斷的修訂，這些年修訂了很多版本。一方面適應業務的變化，另一方面是軟體硬體的變化。即使放在今天來看，它還是一個普遍適用的場景，不管是金融、交通、通訊等，還是一個非常普遍適用的場景。

TPC-C 測試一共五種事務。裡面最多的是訂單建立，又叫交易建立。TPC-C 模型是一個銷售模型，最多是15件商品，平均是10件商品。模型是以一個倉庫為單位，每個倉庫有10個銷售點/倉庫，每個銷售點服務3000個顧客，這個測試是模擬其中某一個顧客到銷售點買東西，買的東西可能是5件，可能是15件，因為買的東西不一定都在本地倉庫裡有，所以每件商品假設有1%機率在別的倉庫，每個訂單建立的事務如果在分散式系統裡有10%的機率是分散式的事務。還要模擬整個訂單建立裡面有1%訂單是要回滾掉。整個效能指標 tpmC 是每分鐘訂單建立的數量，假設100筆事務其中有45筆是訂單建立，還有55筆是另外的，其中訂單的支付是43筆。訂單支付裡面有15%機率不在本地倉庫支付，要到異地倉庫支付，也變成分散式事務。

這是 TPC-C 測試的模型，模擬一個人到一個銷售終端買東西。你的請求會發到一個應用系統去，可以想象應用系統是一個簡化版的淘寶或者支付寶。然後你的請求會發到資料庫裡去，整個應用系統和資料庫都要公開，你用什麼機器，機器配置是什麼，包括價格都要公開。終端模擬器不要求公開。這裡面有很多硬要求，倉庫裡面有9張表，每張表有多少資料，每個資料有什麼樣的分佈都有規定，如果你不符合就不能進行測試。

每個倉庫最高只允許達到12.86個 tpmC。我們做的6000萬 tpmC，大概按照這個比例大概需要480萬的倉庫，整個算下來資料336T左右，我們的資料是乘以2的。規範定義的系統單個部件允許失效，如果用了共享儲存，就是說共享儲存裡允許單個部件失效，大家知道共享儲存裡單個部件失效，共享儲存肯定不會失效，我們沒有用，我們就是用的虛擬機器。如果想透過這個測試，只能把每份資料寫兩份，這樣任何一臺機器壞掉，我們的系統還能正常工作。

另外，你在做效能之前必須先測功能，功能有很多，其中比較關鍵的是要證明你滿足資料庫事務的功能，就是原子性、一致性、隔離性和永續性。隔離要求序列化，這也是比較難的事情，尤其是分散式資料庫。今天分散式資料庫中除了 OceanBase 可以做到，還有就是 Google Spanner。

另外，跑效能則有兩個要求：第一，要求8小時穩定執行，沒有任何人工干預的執行；第二，效能採集至少進行2小時且期間的效能波動不超過2%。這些都是實際生產系統的要求。這兩個小時用來做效能採集，看這兩個小時裡必須保持著前面的比例，訂單建立多大的比例，支付多大的比例，在這個前提之下把兩個小時所有訂單建立數給記錄下來，然後再÷2小時得到真正的 tpmC 值。OceanBase 做了8個小時，審計員看到我們的結果覺得太高，所以，OceanBase 整個效能採集跑了8個小時，而且整個波動小於0.5%，因為我們不想留下任何給別人質疑的空間。

現在結果在公示期，有60天，60天別人說這個結果有不符合規範的地方，或者弄虛作假的地方，你必須要站出來證明自己，我確實符合這個規範和符合標準。60天之後結果就是所謂的 Active，這個時候只要在你所在的地區，任何人都可以以公佈的價錢買到這個系統。

很多硬體裝置三年之後都不生產了，所以它三年之後就認為這是一個歷史的記錄，即為 histroy，記錄還在那兒，還是有效合法的，但是你買不到系統。

我們比較一下歷史上最近的三個結果：

第一，2010年8月份，那個時候 OceanBase 剛剛立項，那個時候還想著怎麼樣活起來。在 2010年的時候，DB2 用3臺 Power 和30臺儲存做到了超過1000萬的結果。結果4個月不到，Oracle 用27臺 Sparc 和97臺儲存做到了3000多萬的結果。儲存是一個更大的瓶頸。

很多人也在問：為什麼 Oracle 後來這麼多年沒有做？Oracle 不是沒有做過，Oracle 在2012年做過一個結果，當時拿X86機器做的，做了500多萬。2013年又做過一次，也是單機，拿一個更好的工作站做了800多萬。Oracle 已經做了3000多萬，為什麼做500萬、800萬這個結果呢？其實我自己的看法是對其他廠商起到威懾作用。這個裡面27臺工作站，平均一臺100萬多一點。2012年、2013年做了500萬和800萬如果你再做，我可以用單機800萬做，哪怕不是線性的也是個很可怕的結果。除非分散式有突破，否則沒有單機資料庫能夠達到Oracle這樣的效能結果。

我們還有一個變化，沒有去買大量的硬體，最後用了204臺的資料庫伺服器，還有3臺是管理節點和3臺監控節點，一共210臺。我們用了虛擬機器，虛擬機器跟物理機相比，記憶體、CPU 都提高50%。我們這個結果如果在物理機上跑，會有50%的提升，因為虛擬機器還是有一定的消耗。

應用系統用了64臺的伺服器，這都是要求披露的。有人在質疑你們這麼多錢測試一次3.8億，誰玩得起？3.8億是說假設一個使用者買下系統並且用三年，包括硬體、軟體、技術支援全部在內是3.8億。整個三年的硬體成本是租虛擬機器的成本，整個成本大概在系統裡面只佔五分之一，測試成本大概用租了3個月的機器，找阿里雲租的，本身你的硬體成本只佔3.8億的五分之一不到，這還是36個月的成本，實際上我們只用了3個月的成本。大家其實可以把我們整個硬體投入能估算出來的。

我們這個測試更大的價值不在於 OLTP，是想跟別人證明，我們在分散式資料庫能做交易處理，更重要是想證明這個資料庫既能夠做交易，也能做智慧場景分析。絕大多數場景下，使用者、客戶不再需要搭建一個資料倉儲，去複製資料、去導資料。否則這樣一個系統只是為了做交易，其實它沒有足夠的價值。

最後是一個簡短的小結。80年代後，交易處理和商業智慧就成了關聯式資料庫一個核心需求，但是集中式的架構這麼多年發展下來，擴充套件能力有侷限，尤其有了網際網路、移動網際網路出現以後。TPC-C Benchmark 本身無所謂我們做了什麼，別人做了什麼，它定義的是業務需求。它定義的是訂單建立、訂單支付、訂單查詢、訂單配送，而這些都是業務需求，只要滿足這個業務需求，哪怕拿檔案系統去測並且能夠測出一個好結果也是本事。

透過這個測試，更多是想證明我們是有史以來第一個分散式資料庫具備交易處理的能力，這是以前沒有的。也是曾經80年代、90年代末宣判做不到的，OceanBase 接下來做的最重要事情不僅是關聯式資料庫的功能，要做的是把商業智慧的能力做進來，能夠向客戶提供所需要的交易處理和商業智慧分析。謝謝大家。