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年的今天，作為主流交通工具的馬車已經成為遠古的過去，汽車早就成為了不可逆轉的主流。