從瀕臨解散到浴火重生，OceanBase 這十年經歷了什麼？

阿里妹導讀：談及國產自研數據庫，就不得不提 OceanBase。與不少人想象不一樣的是，OceanBase 並不是銜着金鑰匙出生的寵兒。相反，它曾無人看好、困難重重，整個團隊甚至數度瀕臨解散。

從千鈞一髮到浴火重生，OceanBase 這十年經歷了什麼？今天，咱們一塊兒瞭解它背後鮮爲人知的故事。

OceanBase 是徹底由阿里巴巴和螞蟻金服自主研發、全球首個應用於金融核心業務的分佈式關係數據庫。OceanBase 的研發始於 2010 年 6 月，由於選擇從零開始，研發之路從一開始就磨難重重，中途由於找不到願意使用的業務，團隊曾經瀕臨解散。

最終 OceanBase 仍是跨越了死亡之谷，在螞蟻金服實現了全面替代 Oracle，成功支撐了過去 5 年「雙 11」螞蟻金服所有核心業務的重壓，創造了 25.6 萬筆 / 秒支付峯值和 4200 萬筆 / 秒請求數處理峯值這一業內全新的紀錄。自 2017 年開始，OceanBase 開始走向外部商用，目前已經在數十家商業銀行落地，其中包括南京銀行、浙商銀行、蘇州銀行、人保健康險等。OceanBase 幫助南京銀行共同打造「鑫雲 +」互金開放平臺，實現貸款交易處理能力 10 倍提高，輕資產模式顯著下降成本，從原有的 30~50 元 / 帳戶下降到上線後的 4 元 / 帳戶。日處理百萬筆放款，平均處理時間小於 1 秒，讓老百姓借錢更方便，真正實現了普惠金融。

站在如今這個時間點上顧盼今昔，螞蟻金服高級研究員、OceanBase 創始人陽振坤認爲，OceanBase 的成功其實有行業和時代的必然性。

時 機

2009 年開始，大量新的非關係型數據庫如雨後春筍般涌出，在整個數據庫行業掀起了一場空前盛大的 NoSQL 革命，現在赫赫有名的 Redis、MongoDB 皆誕生於那一年。NoSQL 的擁護者們積極提倡使用非關係型的數據存儲，從而得到豐富而隨需應變的可伸縮性。這時候的關係數據庫早已過了而立之年，在此期間雖然曾短暫爆發過一些所謂終結關係數據庫的革命，但最終都失敗了，絲毫沒有動搖到關係數據庫的主導地位。

但這一次彷佛與以往不一樣，火熱發展的雲計算帶來了對更大規模數據庫的需求，而關係數據庫的缺點則相應地被愈來愈多人詬病：不可以擴展、容量小、處理能力不夠、成本又很是高。在當時的不少人看來，關係數據庫的末日是真的要來了。2010 年，NoSQL 革命愈演愈烈，有行業專家發文直指「雲計算時代屬於 NoSQL，關係數據庫已經日薄西山」。

那時陽振坤已經作了兩年多的自研分佈式系統，十分看好雲計算系統的發展機會。同一年，陽振坤加入阿里巴巴，開始了分佈式關係數據庫 OceanBase 的研發。

數據庫從誕生起已經有幾十年的時間了，但基本上它的市場格局就沒有多少變化，最先起來的幾家廠商今天仍是佔據着統治地位。由於數據庫很是難被替換，它處在整個產品或者產業鏈最底層的位置，替換風險很大，但收益相比起來卻小得多。這也是爲何像 IBM、微軟這樣的後來者也沒法取代 Oracle。這就致使了數據庫變成了一個門檻極高、強者恆強的領域，後來者很難居上。前有 Oracle 擋道、後有 NoSQL 數據庫追趕，在大部分人看來，那時候怎麼也不會是自研關係數據庫的好時機，但陽振坤卻不這麼想。

加入阿里以後，陽振坤發現不管對淘寶仍是支付寶，關係數據庫都扮演着十分關鍵的角色，在使用上根本不可能擺脫。但已有的數據庫，不管是商業數據庫仍是開源數據庫，都有很是多的侷限，遠遠沒法知足如淘寶、支付寶這樣的互聯網和金融業務對高擴展、高併發、高可用和低成本的需求。單機數據庫已經走到了盡頭，下一步只能走向分佈式，而分佈式剛好是陽振坤所擅長的。若是能將分佈式技術揉到數據庫裏面，解決單機數據庫存在的各類問題，對當時整個互聯網的基礎設施都會是一個巨大的幫助和進步。陽振坤認爲他們遇上了一個「天時地利人和」的好機會。

「天時」指的是互聯網的爆發式增加對數據庫的高併發、大數據量提出了很大的需求，有了需求去推進就會容易得多；「地利」指的是阿里內部從淘寶到螞蟻金服擁有大量須要使用數據庫的場景，OceanBase 能夠從不是特別重要的應用場景開始嘗試，一步步地將數據庫作成關鍵系統；「人和」指的是當時單機數據庫已經走到了盡頭，下一步必定是走向分佈式，而當時團隊成員大可能是研究分佈式出身，作的就是本身最擅長的工做。用陽振坤的原話就是：「這是百年不遇的機會，咱們必定要作，並且必定能作成。」

選 擇

「其實絕大部分人都很是聰明，或者說智慧都足夠，但最終能把事情作成的人卻很少。有時候你們在想這我的是大聰明那我的是小聰明，不是說他的智慧不夠。若是一我的把他的智慧放在作應該作的事情、須要作的事情、重要的事情上，可能這我的真的就是大聰明。」

「一個不斷破格的人」，這是早前某次採訪中記者對陽振坤的評價。1984 年陽振坤考入北京大學數學系，碩士師從本系的張恭慶院士，後又轉向計算機領域，博士師從計算機系的王選院士。須要強調的是，他修完大學課程只用了 3 年，碩士只用了一年多，成爲王選院士博士生的時候他只有 24 歲。1995 年其所在團隊研究成果獲國家科技進步一等獎（排名第四），1997 年也就是他 32 歲那年被破格晉升爲教授。

回想在北大的那些年，陽振坤以爲特別感激的是，學數學讓他有了一個很好的數學基礎，後來轉到計算機系之後，碰到了王選老師，又打下了一個比較牢靠的計算機基礎，這纔有了他後來的今天。做爲對陽振坤影響最大的人，恩師王選有兩點讓他至今受益：一是如何判斷一件事情是否有價值，二是「頂天立地」的技術理念，「頂天」就是技術上要不斷追求新突破，「立地」就是要把技術作成通用產品，讓整個社會都能廣泛使用。

其實 2010 年去淘寶的時候，陽振坤根本不知道本身會作什麼事情。加入淘寶以後，擺在他面前的有兩個選擇，一個是加入正在快速發展的淘寶業務團隊，去主管技術，這是一條已經能看到很大的發展機會、相對輕鬆的道路；另外一條是陽振坤後來本身選的，從頭組建團隊作一個技術平臺，也就是今天咱們看到的 OceanBase 數據庫。從加入淘寶到選擇作自研數據庫，一共只花了兩個星期的時間。

這不是一個容易的選擇，但陽振坤相信本身的判斷：「2010 年選這個項目的時候，我是以爲這件事情須要作。當時互聯網迅速發展帶來了對大數據量、高併發的需求，你們對傳統單機數據庫有很大的抱怨，以爲它既沒有擴展能力，又沒有高併發的能力，成本還很是高，可是互聯網根本就離不開關係數據庫。這件事情怎麼看都是一件應該要作、須要作的事情。」陽振坤沒有說出來的是，這件事到底有多難。

那時候阿里巴巴剛開始要「去 IOE」，幾乎沒人想着說要本身從頭作一個數據庫。傳統關係數據庫都是經過外部硬件來保證可用性，用便宜的 PC 機替換高端服務器以後，硬件更容易出故障了，如何保證數據庫高可用？高可用和數據一致性如何同時保證？分佈式系統怎麼同時實現 CAP 的要求？幾十年來這麼多作數據庫的廠商，國內國外基本沒有人成功過。並且從公司的業務發展的角度，也不可能等你幾年把數據庫作出來，再去發展業務，更可行的作法是基於開源作出一些東西，讓業務先往前走。所以 OceanBase 立項之初，除了陽振坤和他當時的直屬領導，其餘人對這個項目要麼不關心，要麼不同意。從零開始自研分佈式關係數據庫並全面替換 Oracle，在當時有多少人會相信這真的能作成呢？當時整個淘寶一共只有兩三千人，而 Oracle 有十幾萬人，就算整個淘寶的人所有去作數據庫，跟 Oracle 比起來也只是很小很小的一個比例。

在陽振坤看來，若是一件事情幾乎全部的人都認爲它很重要、須要作，這件事情就已經不是創新了。當全部人都認爲這件事情要作的時候，其實作這件事情的時機已通過去了一大半。做爲最底層的基礎軟件設施，數據庫須要很長時間的積累，不可能今年作，明年就能真正大規模地用起來。雖然在 2010 年選擇作數據庫的時候，沒有太多人看重和支持，對於團隊來講這可能反而是一件好事。無人關注，反倒給了團隊幾年積累發展的時間。

陽振坤不僅要自研，還要把 OceanBase 定位成恩師王選所說的「頂天立地」的技術產品——走標準化的路，作一個通用的關係數據庫產品，而不是一個僅僅在公司內部使用的產品。每一個公司使用任何產品其實都只用了其中很小的一部分功能，若是隻作知足公司自用需求的數據庫，可能只須要投入十分之1、五分之一的人力物力時間。而要作成通用產品就意味着必須實現全部功能，這要困可貴多，團隊的投入、花費的精力和時間也要大好多倍。但也由於陽振坤最初的堅持，今天的 OceanBase 才得以走出螞蟻金服，走進多家銀行系統。不過這都是後話了。

蟄 伏

「若是找不到願意使用的業務，數據庫系統是作不下去的。」

OceanBase 的第一個客戶來自淘寶收藏夾。當時的淘寶收藏夾正處於業務高速發展期，數據庫的訪問量飛快增加，面臨着第二年服務器數量須要翻一倍甚至幾倍的局面。業務方忙於尋找解決方案的時候，陽振坤主動找上門去提出了能夠用 OceanBase 幫他們解決問題，把服務器數量下降一個數量級。四個月出 Demo，八個月出試用版，一年後系統正式上線，淘寶收藏夾就這樣成了第一個吃 OceanBase 螃蟹的業務，新數據庫取得了很是好的效果。這時候是 2011 年，收藏夾項目成爲了 OceanBase 第一個小小的里程碑。

但在後續一年多的時間裏，OceanBase 團隊一直在尋找更多業務，也確實有一些業務用了，卻再也沒有找到像淘寶收藏夾效果這麼顯著的業務。作數據庫難度大、週期長，前幾年的投入也許有那麼一點點產出，但其實跟投入比幾乎微不足道，團隊面臨的壓力可想而知。數據庫少不了人力投入，OceanBase 團隊從最先只有陽振坤一我的，後來發展到 2012 年已經有 30 多我的了。佔了這麼多人頭，但在公司裏卻沒有足夠多、足夠重要的業務，沒能產生足夠大的價值和效益。團隊陷入了一個比較困難的時期，甚至數度瀕臨解散。

當被問及「中間有沒有想過這事若是沒作成，怎麼辦？」，陽振坤回答得雲淡風輕：「不是每件事都能作成，那太難了。若是每件事在作以前都想着它能不能作成，那最後作成的事就會不多。」

作數據庫就像在黑暗中前行，守得住寂寞、擔得了壓力，甚至要有近乎偏執的性格纔可能跨越死亡之谷，到達最終目的地。陽振坤團隊中一位新人曾經向他表達過本身的困惑，當時這位新人入職三個月了，由於有太多東西要學，什麼也沒作出來，而跟他同時入職天貓的新員工纔來了一個月，作的系統就已經在線上使用了。陽振坤當時給新人講了一個故事，他說：「你過三年再看，沒有人還記得那個同窗三年前在天貓上把網頁作了什麼改版，但是三年之後你今天作的東西還會在生產系統中使用。」

破繭

在最困難也最危險的時候，團隊迎來了一絲起色。2012 年末，公司把 OceanBase 整個團隊調到了支付寶。支付寶屬於金融領域，面臨的數據庫挑戰會比其餘業務更大，這至關於給了 OceanBase 團隊一次從頭開始的機會。

2013 年夏天，支付寶也開始啓動「去 IOE」，並但願可以把 Oracle 數據庫替換掉。陽振坤又一次主動出擊，向當時的主管、也是如今螞蟻金服的 CTO 程立自薦了 OceanBase 的解決方案。

金融行業數據庫，最怕的就是突發故障致使數據丟失，涉及到錢的事，多了少了都是不可接受的。爲了解決高可用與主備庫數據一致的矛盾，OceanBase 將可用性作到了數據庫系統內部，用一主兩備或一主多備代替一主一備。主庫到備庫同步的時候不要求同步到每一個備庫，而是同步到包括主庫在內的多數庫（超過半數），也就是說總共三個庫中若是有兩個成功了，這個事務就成功了。若是任何一臺機器出了問題，這個系統的可用性和數據一致性都是能夠保證的。

程立承認了陽振坤提出的方案，OceanBase 團隊開始埋頭開發，第一個要攻克的目標是支付寶交易庫。2014 年雙 11，OceanBase 迎來了第一次大考。

大促開始前的凌晨，各個團隊都在本身的做戰室裏熱火朝天地準備。當時任螞蟻金服董事長的彭蕾去了 OceanBase 團隊的做戰室，問你們：「有沒有信心？」陽振坤跟彭蕾開了個玩笑說：「你看咱們窗子都已經打開了，若是等會出問題，咱們就準備從這跳下去。」

在一開始的計劃裏，雙 11 交易流量的 1% 會切給 OceanBase，但由於當時的 Oracle 數據庫系統支撐不了洶涌而來的巨大流量，最後 OceanBase 成功支撐了 2014 年雙 11 10% 的交易流量。通過了雙 11 的考驗以後，OceanBase 獲得了更多的承認和支持。後來 OceanBase 團隊得到了 2015 年螞蟻金服的 CEO 大獎，這也是第一次由技術團隊拿到這個獎。彭蕾但願借這個獎鼓勵那些可以沉下心來、紮紮實實地把一項技術作好作紮實的技術人們。

2015 年春夏，支付寶交易庫和支付庫都換成了 OceanBase；2016 年，支付寶帳務系統上線，這也標記着 OceanBase 真正在金融系統最核心最關鍵的領域站住了腳。2017 年，OceanBase 開始走出支付寶、走出螞蟻金服，在商業銀行推廣使用，至今已在數十家商業銀行上線運行。

從瀕臨解散到浴火重生，OceanBase 已經走了快十年，但在自研關係數據庫這條漫漫長路上，OceanBase 才僅僅走出了一小步。在陽振坤看來，OceanBase 如今「開了很大的一朵花，可是結了很小的一個果」，雖然它已經向全部人證實了通用的分佈式關係數據庫是可以作成的，並且能真正應用在生產系統中，但今天 OceanBase 的應用還頗有限，遠遠沒有充分發揮它的價值。

變局

現在再回看十年前那場轟轟烈烈的 NoSQL 革命，很難一語斷定它到底成功與否。從好的一面來看，在過去十年裏，NoSQL 數據庫確實取得了很是亮眼的成績，在軟件工程師陣營裏愈來愈受歡迎，其中 MapReduce、Bigtable、Cassandra、MongoDB 等都是其中的佼佼者。然而這兩年，業界也在從新擁抱 SQL，幾乎全部的雲計算服務提供商都在提供備受青睞的關係型數據庫管理服務：例如 Amazon RDS、Google Cloud SQL、Azure PostgreSQL。對於亞馬遜來講，其兼容 PostgreSQL 和 MySQL 的數據庫產品 Aurora 一直是 AWS 歷史上增加最快的服務。

Gartner 在 2018 年的操做型數據庫管理系統（OPDBMS）魔力象限中推測「到 2020 年，關係數據庫技術將繼續用於至少 70% 的新應用和新項目。」

從上到下依次爲201八、201七、201六、2015年Gartner操做型數據庫管理系統魔力象限圖

以上是 Gartner 過去四年對操做型數據庫管理系統的分析，其中頭部領導者 Oracle 和微軟一直穩如磐石。正由於數據庫領域的理論和工程實踐早已成熟，前先後後各家公司作產品和技術的思路都差很少，因此很難突破現有產品的框架，更難以顛覆已有市場上佔領先地位的廠商。

但即便是數據庫這樣很是成熟的細分領域也發生了很多動盪，相比四年前，現在活下來的公司只剩下一半；谷歌憑藉 Spanner 從一招鮮玩家殺入到遠見者，阿里雲一舉躋身遠見者，且擁有最多的 DBMS 服務品種；亞馬遜連年快速上升，現在已經跟 Oracle、微軟很是接近。

陽振坤告訴咱們，OceanBase 當初沒有選擇基於開源或已有的技術思路開發，而是選擇走分佈式自研這條路，雖然走得艱難，但作成以後就會成爲不可替代的優點。過去這十來年正好是分佈式系統發展的十來年，轉型到分佈式已經成爲全部人都承認的一個選擇。現在，以 Google Spanner、螞蟻金服的 OceanBase 爲表明的分佈式關係數據庫，不只解決了關係數據庫的擴展性問題，也極大地下降了關係數據庫的成本（數量級的硬件成本的下降），還提高了可用性。

如今，兼容 Oracle 的工做是 OceanBase 的重中之重。OceanBase 團隊的目標是，用兩年時間作到 Oracle 業務的平滑遷移，不須要修改一行代碼、不須要業務作任何調整就可以將數據庫遷移過來。

對於數據庫的將來，陽振坤錶示：「儘管今天在業界，數據倉庫主要依賴的不是關係數據庫，但能夠看看 Google。今天 Google 的大數據分析 / 數據庫倉庫基本都統一到了 Spanner，這應該是 5-10 年後產業界的寫照。」將來，OceanBase 還會走得更快、更遠。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。