小螞蟻說：
2018年10月15日，北京交通大學計算機與資訊技術學院第71期CIT名師大講堂在第九教學樓中心報告廳舉行。螞蟻金服進階研究員、OceanBase團隊負責人陽振坤在本次學術報告中發表了題為《OceanBase：跨越關系資料庫的死亡之谷》的主題演講。陽振坤向同學介紹了OceanBase從創新到産品的飛躍式發展，分享了網際網路時代下技術和産品如何跨越“死亡之谷”的經驗和心得。
相關閱讀：《
迎雙11十周年，OceanBase 2.0挑戰新巅峰 》、《 厲害了，螞蟻金服！創造了中國自己的資料庫OceanBase 》 資料庫：技術和市場的“死亡之谷” 資料庫在每個人的生活裡無處不在，不管是通訊、交通、金融行業，抑或是每天大家都在接觸的網際網路，所有這些業務的背後都是資料庫在支撐。
- 事務須并發處理： 資料庫要支援事務，所有人都希望用最小的處理資源，做到最大價值的事情。是以事務持續要做大量的并發處理。
- 資料一條不能錯： 一個資料庫如果資料錯了，就永遠沒有機會了。對于使用者而言，如果你會錯一條，你就有可能會錯一千、一萬條，這是沒有公司願意承擔的風險。
- 服務片刻不能停： 通訊系統、列車系統，甚至飛機航行系統的背後都是資料庫在支撐，這些系統一旦啟動，一分一秒都是不能終止的。
上面提到的這三條要求，任何兩個其實都好滿足。但是大家仔細想一想，這三個要求如果要同時滿足，就會變得極其困難。
同時，資料庫又是一個巨大的市場，對國家、對整個社會都非常重要。這就導緻很多國家、很多企業都想做也正在做這件事，但是結果大家都做到了同一個思路上。後來者都成了先行者的模仿者，那麼這個模仿的代價就會變得很大。
今天作為一個後來者，你再去做這麼一套資料庫系統的時候，就真的很難說清楚你與先行者相比有多大的優勢。
這也就造成了強者恒強、寡頭壟斷的局面，後來者很難居上。資料庫同樣也有開源這條路徑，比如大家都了解的MySQL。開源是免費的，對于很多對成本敏感的公司而言開源資料庫成為了替代商業資料庫的另一種選擇。
那麼在面對資料庫的“死亡之谷”這樣的困境下，為什麼我們還去花這麼多錢，投入這麼多裝置，花這麼多年時間和人力再去做一個資料庫，究竟它的意義在哪兒？它又能夠産生多大的經濟價值？
既然有了開源的資料庫，阿裡巴巴和螞蟻金服還要做這麼一個商業資料庫産品，其實這裡面是有本質原因的。很多人知道阿裡巴巴今天已經
全面去IOE：去掉了Oracle資料庫、IBM小型機、 EMC存儲。那麼很多人就在想，能不能在其他的行業，在鐵路、交通，電信、政府這些行業推而廣之，全部完成去O的程序呢？這個答案是否定的。
因為像阿裡巴巴發展的這一套系統是基于MySQL的開源資料庫，跟商業資料庫在功能和性能上其實是有很大差距的。阿裡巴巴當時在用它的時候，有很多事情資料庫是做不了的，那麼這些做不了的事情當時就放在應用軟體裡做。是以阿裡巴巴在資料庫和應用軟體上都投入了很大的技術力量。這套系統拿到外部業務去用是不能徹底解決問題的。
本質上這套系統是服務于阿裡巴巴的專用系統，而不是一個通用的系統。那麼有人會問，在我的企業裡，如果真的想去掉IOE，該怎麼辦？你同樣要投入兩撥人，一撥人要去做資料庫，針對你的企業的需求來做相應的修改；還有一撥人要去做應用系統。但是問題是并不是所有的企業都像阿裡巴巴有這麼多優秀的技術人員，這套東西其實很難去直接推廣應用。
是以，從一開始我們做OceanBase的目标就是——
我們不想隻做一個專用的系統，要做就一定要做一個通用的系統。我們希望今後OceanBase能夠服務于各行各業，再也不需要企業投入幾十幾百甚至幾千個人去改造、去重新做一套業務系統。
OceanBase的機遇與創新 當時做OceanBase資料庫一個最根本性的原因就是需求的變化。因為這麼一套基礎系統，如果背後沒有需求的變化，從0到1自己做出來基本是不可能的。
2010年春夏之際，我來到了阿裡巴巴。去了之後發現當時有兩個因素影響了阿裡巴巴關系資料庫的應用。
一個因素是
并發，資料庫它是按照并發量來賣錢的。說直接點，就是按照處理器來賣錢。之是以要買這麼多處理器就是因為業務有這麼大的需求。那麼傳統的業務比如商場，一個商場就那麼幾個收銀台，它是一個相對穩定而且比較小的并發量，大多數情況就是幾十幾百的并發量。
随着網際網路的高速發展，阿裡巴巴天貓雙11幾乎完全改變了過去行業内相對穩定的并發量，突破了幾百萬人甚至是千萬人的同時線上購買。這個并發量跟過去的傳統業務場景相比是幾個數量級的增長，按照這個數量級去買商業資料庫，沒有一家企業買得起。
還有一個因素，當時我們叫它
建站，其實就是搭建一個資料庫。過去建一個商場，建一個銀行的分店，這個周期是非常長的，有足夠的時間來規劃IT業務系統。網際網路業務是等不了的，就像當時OceanBase接的第一個業務給到我們的時間就是最多一個星期。現實是一個星期的時間根本連小型機的安裝調試都完不成。
原來的模式已經完全無法支撐網際網路快速發展的業務。是以這兩個需求的變化，是催生我們自己來做資料庫的很關鍵的因素。 OceanBase關鍵性的技術革新當時我找了幾個同僚商量這個事情，我跟大家說，我們是天時地利人和都趕上，這件事情除非是被拍死掉，否則我們是肯定要把它做成的。
這個過程真的非常艱辛，我們花了差不多五年的時間，才真正讓OceanBase有了關鍵的應用。過去做資料庫的公司，不管是國内還是國外，大家都是為了做資料庫而做資料庫，那麼最後結果就是所有做傳統資料庫的廠商，大家的方案都很像。
因為資料庫有很成熟的理論和工程的方法，那麼如果我們按照以往的原則做過去，結果肯定也是一樣的。是以，
其實我們走了另外一條路——做分布式。最早做這個東西可能都不叫資料庫，它更像是一個分布式系統，但是支援了事務的特性。這條路後來被證明确實是具有特别大的價值和意義。
當時我們在做OceanBase的時候，首先确定了幾件事情。
第一件事就是我們要做分布式，因為我們的業務要建站，不做分布式靠大型機和小型機是不可能做得到的。
另外一件事是成本，什麼東西最便宜，量最大最主流的東西最便宜，它就是PC伺服器。小型機少則幾十萬，多則幾百萬，PC伺服器頂多就是幾千幾萬塊的成本。
第三個要解決的就是可靠性問題。大家對資料庫的期望是永不當機，永遠不出問題。可是PC伺服器到處都有，成本效益也非常好，但是不容忽視的是它的故障率高。普通PC伺服器它遠遠達不到資料庫所要求的年可靠性五個九的要求。對普通PC伺服器而言，差的可能是兩個或者三個數量級，是以我們得首先把這個問題解決掉。我們用的就是分布式的辦法來解決。
我們運用的是分布式的一緻性協定，直白一點就是一個多數派的選舉和投票協定。同時，我們把修改的增量直接放在記憶體裡，每次要查詢的時候，把記憶體硬碟的資料做一個merge，那麼每天在業務相對的低谷期，再把記憶體中的資料整理回硬碟去。
做到了這幾件事情，這個系統就有了很好的成本效益，
我們的成本比傳統的資料庫至少低一個數量級，你隻需要用普通的PC機，不需要用昂貴的硬體設施。同時，擴充能力會也變得很好。 OceanBase的第一個業務：淘寶收藏夾理想看起來很美好，但是現實特别骨感。這個項目剛啟動的時候，我們好不容易才找到了幾個人，人手是嚴重不足的。另外一個更大的挑戰是時間：在做OceanBase資料庫之前，我去找我的老闆，他說給你
兩年時間如果能把一個資料庫做出來就可以。當時我心裡想兩年雖然對于做資料庫來說時間确實太短，但是這兩年對于那時候的我們而言已經足夠支撐起最初的想法了。
技術最終還是需要通過業務落實下去，是以我找了一批業務方，花了很長時間跟對方溝通，最後終于有一個業務願意用我們的資料庫。當時他給我的時間期限是——
兩個星期。
當時我就傻了，兩個星期要做個資料庫，這可怎麼辦？後來跟業務的同學反複讨論，最後他們同意說，你們先做個demo出來。于是我們就花了兩個月吭哧吭哧的做了一個demo出來。他們看了以後覺得比較滿意，後來這個事情就一直堅持做下去了。
最後，我記得是到了第八個月的時候，系統上線了。這個業務就是現在大家都在用的——
淘寶收藏夾，這是OceanBase的第一個業務。如果沒有這個業務，我們現在也活不下來。
那麼這個業務到底有什麼特殊的地方？每個人都用過淘寶收藏夾，每次你打開收藏夾的時候，資料庫在背後其實做了很多事情：我們以單個商品為例，它需要到一個叫商品庫的地方，逐條紀錄核對，看看商品有沒有下架，有沒有參與促銷，有沒有參加其他的返點活動等等。
假如你收藏了100多件商品，它就要進去一條條的取出來看。本質上來講，這就意味着一百多次的随機IO。那麼當很多人同時來看的時候，其實一個IO就被放大了幾百倍，這時候有多少個硬碟都不夠用。
當時他們已經用了幾十台伺服器了，按照業務的預估，第二年他們要買400台機器，第三年的數量都不敢想象。當時我們想了一個辦法——我們做了一個
寬表，确切的講應該稱為
物化視圖 首先我們把每個使用者收藏的資訊聚集起來，這樣可以減少IO，然後把收藏的商品放在這個清單裡。但是我們怎麼避免去通路一百多次IO呢？我們的辦法就是找到一個時間點，當時是設定在每天晚上淩晨兩點。在這之前，我們就把這些資訊全部merge到硬碟，然後從兩點開始，我們把新的修改都放在記憶體裡面。
是以每到兩點的時候，我們把兩點之前所有的資訊都合到這張表裡，那麼這張表裡的資訊在兩點整的時候是準确的，這時候我們不需要去通路商品庫。兩點之後的修改，包括商品庫的修改是在記憶體裡進行的，這時候如果要看這些商品有哪些修改，商品隻需通路記憶體中的更新即可。
是以其實我們就是通過這樣一個手段，把每次收藏夾的展示，
由原來的一百多次IO變成了一次。我們一下子就把淘寶收藏夾業務的整個IO降下來了。當時OceanBase确實是幫助業務實際解決了他們的問題，使得業務能夠更好的快速的發展。業務是一定要發展的，是以隻有我們真正能夠解決他們的問題，我們這些做基礎系統做底層的人，才能活下去。
這是當時給淘寶收藏夾做的一個架構，中間是一個做修改的伺服器，所有的修改都在這一台機器上進行。旁邊的機器是基線資料，就是分片切片以後，放到周圍這一圈進行。是以當時我們就用這個看上去很簡陋的一個方案來真正解決了淘寶收藏夾的問題。
當時收藏夾用了這個方案之後，伺服器的數量從原來預計的第二年要用幾百台，最後其實隻用了差不多二十幾台伺服器，就把整個問題解決掉了。 OceanBase 0.3-0.4版本：團隊面臨解散從淘寶收藏夾項目之後，我們陸陸續續也做了不少項目，但是沒有一個項目能像淘寶收藏夾這樣對業務有明顯的價值和貢獻。
從那之後的整整兩年，我們找不到對OceanBase資料庫而言特别有價值的業務。那兩年對于我們而言特别特别困難，甚至整個團隊随時面臨着解散。
底，公司把我們從淘寶調到支付寶，當時預估到支付寶在資料庫方面所面對的挑戰更大，後來證明确實如此。即使是這樣，當時仍然還處在一個非常困難的時期。到了支付寶一年多的時間，我們仍然很難找到新的業務，或者說價值比較大的業務來證明我們的價值。
OceanBase 0.5版本：成功抗住10%流量 2013年的夏天，支付寶希望全面去掉IOE——去掉IBM的小型機，Oracle的資料庫和EMC的存儲。當時面臨了一個問題，就是去掉之後是可以用MySQL來代替Oracle，但是MySQL的主備鏡像其實是做不到主備完全一緻的。
這個時候我們意識到：OceanBase的機會來了。因為我們可以通過分布式的選舉跟投票來做，哪怕硬體本身不可靠，我們也能保證資料的不丢失。傳統資料庫本質上是借助硬體的可靠性，也就是硬體需要達到五個九的可靠性來實作高可用的。就算出了故障，它的資料也能救得回來。但是這種手段需要非常高的成本，同時沒有足夠的擴充能力。
銀行雖然有很高的可用性，但是它的高可用性是用很高的硬體成本換來的。
我們建議一定要淘汰這些高可靠的硬體，因為他們的成本實在太高了。一旦真的使用了高性能，高成本效益的PC伺服器，那麼你就不可能再花那麼多錢去買高端的硬體。
是以我當時心裡很明白，如果這件事情我們做不成，這個項目就隻有死路一條。 那麼，OceanBase到底如何做到主備完全一緻的呢？理論上我們也沒有辦法說完全做到主庫備庫的一緻。我們用了另外一個辦法：
主庫還是主庫，還是需要它快速的做事務，但同時主庫還要把事務的日志同步給至少兩個備庫。兩個備庫中至少有一個收到了，那麼加上它自己就超過了半數，或者我們叫多數派。當多數的節點收到了這個事務，并且把它持久化到硬碟了，我們就認為這個事務是成功的。
是以這時候任何一台機器壞掉，每筆事務在剩下兩台機器裡面至少一台存在。是以說即使主庫突然壞掉，另外兩台機器經過握手，它們再選舉出一個新的主庫，那麼肯定可以繼續工作下去，同時可以保證資料是沒有損失的。
2014年的時候，我們在會議室裡讨論
支付寶交易庫的上線，當時吵得面紅耳赤，争論了很久别人就是不願意上OB。他們原來的交易、支付系統全都在Oracle上，當時的Oracle無論是在穩定性、可靠性還是性能方面，肯定比OceanBase要好得多。是以沒有人願意用。
最後，在
魯肅的力挺下決定切給 OceanBase 1%的流量試試。因為那幾年業務發展的太快，當時Oracle的共享存儲已經扛不住這個流量，按照當時的業務流量去做壓測的時候，幾分鐘就要壞一塊盤。最後發現，把業務切掉10%，才能勉強扛得住。
是以那一年的雙11就把10%的流量切到了OceanBase。OceanBase也成功扛過去了那一年的雙11。 OceanBase 1.0版本：唯一支援分布式事務的商業資料庫但是其實在0.5這個版本上線的時候，我們心裡非常清楚，這個版本是臨時的。我們當時選擇做多數派協定的時候，還是用了原來的想法，每個叢集還是中間有一個中心節點。這個事情一定不會是長久持續下去的，我們知道這個一定會遇到問題。是以當時其實交易庫還沒有完全上線，我們就已經啟動了1.0版本的開發。
2014年到2016年，整整兩年的時間，我們投入了40多個人，全部投在OceanBase 1.0版本的開發上。整整兩年，這40多個人沒幹任何别的事情。所有的線上問題，版本修改、更新都是我們調出來的五個同學全部扛下來的。
有人會問什麼樣的因素讓這麼多人做了兩年才能把這個版本做出來？這個版本裡面我們主要做的一件事就是分布式。
如果你問分布式事務有這麼難嗎？我可以自豪的回答你：
今天的商業資料庫裡有且隻有一個是能夠支援分布式事務的，它就是OceanBase。OceanBase通過分布式的一緻性協定做到了系統的高可用性，就是說哪怕我們今天用的是比較廉價的，可靠性比較低的PC伺服器，但是我們的可用性其實會變得更高。因為單機的故障我們完全能夠自動的容忍掉，而且我們做到了現在的資料做不到的一件事情——
哪怕主庫出故障，我們能夠保證資料沒有任何損失。今天的銀行每年國家都要求他們至少做一次消防演習，銀行要到最前端的網關把交易紀錄撈出來核對，把這些賬對平了，備庫才能繼續服務。我們今天根本沒有這個問題，主庫出故障了，也就是幾十秒以後，新的主庫就會被選出來。因為隻要剩下的機器超過半數，他們互相之間會通過握手把資料補齊，很快就能工作。其實這30秒大部分還是消耗在确定主庫是否真的有故障。
是以，我們用不可靠的硬體反而做到了更高的可用性，而且做到了資料真正的一緻。
傳統的資料庫因為涉及到共享存儲，共享存儲是一個單一的裝置，你隻能放在一個機房。是以一旦那個機房出現了故障，你就隻能靠備庫容災把系統恢複起來。
OceanBase通過“三地五中心”部署實作城市級故障自動無損容災。比方說相當于你一共寫了五份日志，放在三個不同的城市裡。任何一個城市哪怕出故障，比方說杭州斷網了，那麼剩下的依然超過半數，這個系統還是可以恢複工作的。這也是原來的傳統資料庫，不管想什麼辦法，都做不到的事情。
前段時間，大家可能也看到了雲栖大會的新聞。螞蟻金服副CTO胡喜在ATEC主論壇現場模拟挖斷支付寶近一半伺服器的光纜。
結果隻過了26秒，模拟環境中的支付寶就完全恢複了正常。而這場26秒自斷伺服器現場示範的技術核心其實正是基于
OceanBase的三地五中心架構方案 2017年，天貓雙11中螞蟻金服的全部核心系統，包括很多業務系統都放在了OceanBase上。去年我們創造了
25.6萬筆/秒支付峰值的世界紀錄，這下面還有一個資料，就是說我們為了要執行這25.6萬筆的支付，執行了
4200萬條SQL 新的曆史機遇：走出去是以從今天來看，OceanBase在過去的曆史程序中面臨了一個個新的機遇，無論是處理器、作業系統還是資料庫，這些都是非常大的挑戰。
從2016年底，我們就開始做準備，OceanBase一定要走出去。從我們成立的第一天起，團隊裡的每個成員的目标都是一緻的：
我們不是想做一個資料庫隻是給自己用，我們要做一個資料庫真的去推動整個社會的進步，能夠讓整個社會的生産力發生變化。是以，2017年我們正式開始服務于外部，最早的兩家客戶是
浙商銀行和
南京銀行，我們現在的客戶要多很多。從内部的應用到真正走出去服務于外部，真的是一個很大的挑戰，是一件很困難的事情。
回想這八年多來，OceanBase走過的路：開始的頭兩三年，我們真的每天都在掙紮，每分每秒都在想着怎麼能讓自己活下來。到了2013、2014年，我們終于找到了一個真正的立足點，就是支付寶的交易庫。然後我們接着花了整整兩年的時間，真正在OceanBase 1.0 版本把分布式做出來。在接下來的一到兩年時間裡，我們把支付寶的核心業務全部搬到OceanBase上。
關系資料庫确實是個門檻很高的東西，但是凡事有利有弊。門檻高意味着我們進來很難，别人進來一樣難。我們集中精力在做事務處理這一塊，它的門檻是很高，很不容易進去，但我們恰恰有這個機會能進去。我們費了很大的力氣跨進來了，别人可能費了全部力氣也進不來。
現在回想起來，能夠把最早的一些想法一些創新變成産品，真的是非常辛苦或者說非常痛苦的一條道路。但是我們做的所有事情其實還是從業務、從客戶中出發，隻有技術真的能夠落到生産中去，落到使用者中去才是真正有價值的，否則你做得再好也是一個空中樓閣。
到了今天，當我們走出阿裡巴巴，走出螞蟻金服再來看，發現
當你做的事情能夠提供十倍成本效益的時候，其實真的有機會去颠覆一個産業，重新塑造一個行業。 OceanBase TechTalk · 北京站10月27日（本周六），OceanBase TechTalk 第二期線下技術交流活動将在北京啟動。
屆時，OceanBase三大重量級嘉賓：陳萌萌（酒滿）、韓富晟（顔然）、喬國治（鸷騰）将跟大家一起聊聊支撐了今年天貓雙11的 OceanBase 2.0版本的産品新特性和重大的技術革新。北京中關村，我們不見不散！
— END —