阿里妹導讀：談及國產自研資料庫，就不得不提 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 定位成恩師王選所說的“頂天立地”的技術產品——走標準化的路，做一個通用的關係資料庫產品，而不是一個僅僅在公司內部使用的產品。每個公司使用任何產品其實都只用了其中很小的一部分功能，如果只做滿足公司自用需求的資料庫，可能只需要投入十分之一、五分之一的人力物力時間。而要做成通用產品就意味著必須實現所有功能，這要困難得多，團隊的投入、花費的精力和時間也要大好多倍。但也因為陽振坤最初的堅持，今天的 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% 的新應用和新專案。”

從上到下依次為2018、2017、2016、2015年Gartner操作型資料庫管理系統魔力象限圖

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

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

陽振坤告訴我們，OceanBase 當初沒有選擇基於開源或已有的技術思路開發，而是選擇走分散式自研這條路，雖然走得艱難，但做成之後就會成為不可替代的優勢。過去這十來年正好是分散式系統發展的十來年，轉型到分散式已經成為所有人都認可的一個選擇。如今，以 Google Spanner、螞蟻金服的 OceanBase 為代表的分散式關係資料庫，不僅解決了關係資料庫的擴充套件性問題，也極大地降低了關係資料庫的成本（數量級的硬體成本的降低），還提升了可用性。

現在，相容 Oracle 的工作是 OceanBase 的重中之重。OceanBase 團隊的目標是，用兩年時間做到 Oracle 業務的平滑遷移，不需要修改一行程式碼、不需要業務做任何調整就能夠將資料庫遷移過來。

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

原文連結
本文為雲棲社群原創內容，未經