阿里妹導讀：談及國產自研數據庫，就不得不提 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 還會走得更快、更遠。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的从濒临解散到浴火重生，OceanBase 这十年经历了什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。