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 接下來做的最重要事情不僅是關係數據庫的功能，要做的是把商業智能的能力做進來，能夠向客戶提供所需要的交易處理和商業智能分析。謝謝大家。