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項目一開始的時候，就設定了兩個重要的目标：
- 這個系統要能夠水準擴充；
- 這個系統必須高可用的，盡管使用普通的硬體。
現在讓我們看看 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 接下來做的最重要事情不僅是關系資料庫的功能，要做的是把商業智能的能力做進來，能夠向客戶提供所需要的交易處理和商業智能分析。謝謝大家。
《OceanBase 企業級分布式關系資料庫白皮書》釋出啦！！！
OceanBase 現已釋出産品白皮書，面向所有企業客戶、資料庫一線開發及運維，内容涵蓋五大章節，從趨勢、觀點，到産品介紹及重磅客戶案例。
以下是目錄概覽：
點選連結檢視：
https://gw.alipayobjects.com/os/basement_prod/93057529-9069-43c1-b7f9-78c52056b51e.pdf