OB君：中國人民大學常被譽為是“中國人文社會科學的最高學府”，其實人民大學也是“中國資料庫的發源地”。由中國人民大學教授薩師煊與王珊合作編寫的《資料庫系統概論》是國内第一部系統闡明資料庫原理、技術和理論的教材，也被公認為是國内資料庫領域的經典權威教材。近期，螞蟻金服進階研究員、OceanBase團隊創始人陽振坤受邀在人民大學分享了分布式關系資料庫OceanBase如何登頂國際TPC-C benchmark排行榜，并對這一突破背後的技術創新進行了深入的解析。
資料庫：技術和市場的“死亡之谷”
資料庫的概念最早源自上個世紀60年代。到了70年代，關系模型已經誕生。80年代關系資料庫逐漸成為整個社會的資訊基礎設施。2000年伊始，随着網際網路的發展，業務系統對資料庫的需求發生了很大的變化。在過去，傳統的資料庫并發通路量從幾百到幾千。進入網際網路時代後，并發通路量驟增，達到百萬至千萬的級别。越來越多的公司發現根據現有的并發量和資料量，不僅他們買不起傳統商業資料庫，而且傳統商業資料庫也無法容納和處理他們的資料量和通路量。
從2006年開始，大量新的非關系型資料庫如雨後春筍般湧出，在整個資料庫行業掀起了一場空前盛大的NoSQL革命。最早在 2006年，Google Bigtable發表，随後HBase，HyperTable，MongoDB，Redis相繼問世。
火熱發展的雲計算帶來了對更大規模資料庫的需求。過去的業務大多類似商場開業，從選址、裝修到IT裝置的采購，至少需要一個季度甚至半年時間。如今業務部門從采購到上線，時間縮短至數小時，甚至很多業務要求像租用雲計算服務一樣，能夠即拿即用。
雲計算改變了已有模式，這時候傳統關系資料庫的缺點也進一步凸顯：不能水準擴充、容量小、處理能力不夠、成本又非常高。甚至很多人斷言，關系資料庫正在走向末路，然而時至今日，關系資料庫依然是整個社會的資訊基礎設施，承載着整個社會重要程度最高、通路量最大的資料。
關系資料庫從誕生起已經有幾十年的時間了，但基本上它的市場格局沒有太大的變化。最早的幾家霸主直至今天依然占據着統治地位。關系資料庫雖然很重要，但是它在整個IT系統的成本裡卻并占據非常大的比例。關系資料庫處在整個産品或者産業鍊最底層的位置，替換風險很大，遷移的成本很高，是以非常難以被替換。這就導緻了資料庫變成了一個門檻極高、強者恒強的領域，後來者很難居上。
談到關系資料庫，準确地說用于線上交易處理的關系資料庫，在我看來這是所有軟體中最難的。首先一個重要的難點在于它需要支援資料庫事務即ACID，其次在于SQL優化器，這兩點就占據了資料庫中很大部分的工作量。同時，線上交易處理關系資料庫的技術門檻也非常高，我們常說有三個“要”：1）既要：資料一條不能錯；2）又要：服務片刻不能停；3）還要：交易處理高并發。基于如此高的技術門檻，這也意味着線上交易處理資料庫注定是一個非常艱難的領域。
前有先行者擋道、後有NoSQL追趕，在大部分人看來，很多人都覺得這不是做自研關系資料庫的好時機。但仔細分析後，會發現這是個千載難逢的好機會。
天時地利人和鑄就OceanBase開創性的革新
2010年加入阿裡巴巴後，當時很多人都看到單機資料庫已經走到了盡頭，我想如果能将分布式的核心理論揉到資料庫裡，解決單機資料庫的水準擴充問題，對當時整個網際網路的基礎設施乃至整個社會的資訊基礎設施都會是一個非常好的機會。我當時找了幾個同學想要一起做這件事，跟我一樣，這幾個同學都有分布式背景。
盡管研制關系資料庫充滿了挑戰，但我們得到了千載難逢的天時地利與人和的機遇。“天時”是網際網路的爆發式增長對資料庫的高并發、大資料量提出了很高的需求，而傳統關系資料庫難以滿足這個需求；“地利”是阿裡巴巴内部從淘寶到支付寶擁有大量使用資料庫的場景，OceanBase可以從不是特别關鍵的應用場景開始嘗試，一步步地将資料庫做到關鍵系統；“人和”是當時單機資料庫已經走到了盡頭，下一步一定是走向分布式，而當時團隊成員大多是分布式技術背景，做的就是自己最擅長的工作。
2010年6月25号OceanBase項目正式立項。項目創立之初，我們給自己定了兩個小目标：第一是硬體成本效益做到Oracle的十倍，第二是做到可水準擴充，因為這是OceanBase的根基。
傳統資料庫常常被人诟病，因為它有兩個本質的缺陷：首先是傳統的OLTP資料庫不能水準擴充。由于不能水準擴充，機器隻能越做越大，價格甚至幾何級數的增長。
第二就是主庫備庫的資料不一緻。主備鏡像無法做到資料可用性跟一緻性兩全：主庫備庫的完全一緻意味着每一筆事務都得從主庫同步到備庫，備庫确認後才能應答。假如這中間網絡出現問題，或者備庫出現問題，所有的同步都會被堵塞，也就是所有的寫操作都無法進行。是以主庫一旦出問題，資料是有損的，是以企業隻能買最可靠的裝置，從四個九到五個九，就是為了讓這些機器不出一點問題，可想而知這樣的裝置肯定便宜不了。不論是軟體還是硬體都便宜不了，服務自然也便宜不了，這就導緻資料庫成本非常高。
如果分布式資料庫是一條康莊大道，這條路可能早就被無數人踏過。分布式OLTP資料庫其實是一條非常難走的路，因為分布式資料庫的一個核心問題就是單機故障會引起整庫故障。随着機器規模的增大，機群故障率會指數級的提高。由于主備鏡像無法做到資料可用性跟一緻性兩全，是以無法采用主備鏡像或類似手段解決分布式資料庫的節點故障的問題。
對于銀行和企業的業務來說，可用性跟一緻性是一個生死兩難的問題，要保證同步，就面臨着業務不可用的風險。是以銀行往往會購買可靠性更高的存儲和伺服器等硬體。可靠性高的硬體自然價錢也非常高昂。
因為分布式裡每一個節點在任何時刻都可能會故障，不管這個節點本身的可靠性有多高，它都有故障的可能性。一直以來，我們工作的重點之一，就是圍繞如何提升分布式整體的可用性。如果解決了這個問題，不再需要高可靠的硬體，也不用在意主備庫是否一緻和水準擴充的問題，很多問題都能引刃而解。
是以OceanBase采用了Paxos分布式一緻性協定，它也是OceanBase整個分布式資料庫裡最核心的基礎之一。它本質上解決的一個問題就是用不可靠的成員來提供可靠的服務。也就是哪怕單個節點不可靠，隻要大部分節點正常工作時這個系統就能正常工作。傳統資料庫中五個九的裝置非常昂貴，OceanBase則基于普通的PC伺服器，且不要求裝置有很高的可靠性，隻要兩個九到三個九，整個系統就能夠工作得很好，這一創新的技術突破大大提升了成本效益。
那麼，OceanBase是如何用Paxos協定來做成這件事？我們前面簡單分析過，不可能既保證高可用，又保證主備庫完全一緻，因為這兩個需求是沖突的。然而Paxos協定卻提供了一個迂回的解決方案，即多數派。舉例說明，主庫中的每一條日志會同步給兩個備庫，隻要有一個備庫收到，就能達成一個多數派協定。簡而言之就是三者中有兩個同意，少數服從多數，就認為這件事情成功了。那麼這種情況下，任何一個節點壞掉，剛才的這筆事務也至少會在剩下兩個節點中的其中一個節點有。是以哪怕是主庫故障了，那麼兩個備庫會互相握手，互相把缺失的資料快速補齊。這個恢複的時間，OceanBase通常不會超過30秒。
有同學肯定會問，你們用的都是廉價的伺服器，萬一三台中壞了兩台怎麼辦？雖然在實際生産中三台壞兩台的機率特别小，但是其實也有過類似的事故。是以接下來在生産系統中，大部分都換成了五節點。五個節點裡需要有三個日志寫成功，這種情況下，即使同時壞了兩個節點，生産系統也完全不受影響。雖然提高了成本，但是比起整個系統的可用性來說，是一個能夠接受的代價。
接下來就是怎麼解決分布式事務的問題。分布式事務兩階段送出模型雖然看起來相當美好，但是實際上一旦節點在第二階段出現故障，則事務既無法送出也無法復原，隻能被挂起，在實際生産系統中，這會導緻資料庫的連接配接迅速被耗盡，進而使得服務中斷。OceanBase做了一個小小的改變：我們把原來的每一個實體節點換成一個Paxos組，相當于換成一個虛拟節點，這個虛拟節點背後有三/五個實體節點。根據多數派成功協定，三/五個節點裡有兩/三個節點寫成功這個事務就被判定為成功。實際上使用了這樣一種方式解決了我們提到的萬一有一台機器故障，兩階段送出就沒辦法推進下去的問題。我們就是通過這樣一些看上去相對簡單的方式解決了分布式事務的問題。
其實，無論是主庫備庫不一緻還是分布式事務的缺陷，根本的原因是傳統關系資料庫軟體自身高可用的缺失，即傳統關系資料庫都是通過外部硬體來保證可用性，而沒有從資料庫系統内部來解決問題。
OceanBase征戰TPC-C的艱辛之路
TPC-C benchmark誕生于上個世紀80年代，ATM自動提款機問世以後，資料庫廠商都希望推銷自家的線上交易處理系統。各個資料庫廠商在線上交易處理的benchmark上各自為政，一直沒有一個統一的規範，既缺乏足夠的說服力，使用者也無法在各個系統之間進行參照和對比。
就在這時，Jim Gray聯合多位學術界、工業界的權威人士提出了DebitCredit标準。标準雖然出台了，但是資料庫廠商卻并沒有嚴格按照标準測試，而是肆意篡改标準讓自己跑出更高的結果。這就好比有了法律卻沒有執法的隊伍，每個人都按照自己的了解來解釋法律和執行法律。
Omri Serlin非常了不起，他說服了8家公司成立TPC組織，并且制定了TPC系列标準，相當于立法；同時TPC組織還負責監督稽核測試過程和測試結果，相當于執法。從這之後，資料庫領域各自為政的benchmark才有了一個統一的标準。
目前，TPC-C benchmark在國際上被認為是最重要、最權威的标準之一。TPC-C模型本身看起來很簡單，就是五種事務的模型。但即使在今天在各個行業，包括電子商務、銀行、商場、交通、通信、政府、企業裡等等這些業務的抽象依然都是TPC-C模型。
當我們完成了TPC-C的優化工作以後，我們發現今年雙11的OceanBase的性能目标已經提前達成，這也是因為TPC-C是實際生産系統很好的抽象，盡管實際的生産系統更複雜。TPC-C制定了五種事務的百分比，分别是：訂單建立(<=45%)和訂單支付(>=43%)以及訂單查詢、訂單配送和庫存查詢各(>=4%)。其中，還有一些限制，比如規定每個Warehouse最多隻能貢獻12.86tpmC（tpmC即訂單建立每分鐘所執行的數量）。是以這會導緻一個直接的結果，性能與資料量成正比，也就是要跑更高的性能，自然需要更多的倉庫。每個倉庫的資料大概是70MB，同時TPC-C還要求滿足60天壓測的存儲容量。OceanBase跑了6088萬tpmC，對應的存儲空間是PB級别的。
TPC-C的測試和審計是一個特别嚴格的過程，OceanBase團隊前前後後花了接近一年的時間才完成。TPC-C審計要求首先做功能的驗證，也就是資料庫事務的ACID。等功能驗證通過了以後，才能跑性能。跑性能則有兩個要求：第一，要求8小時穩定運作，沒有任何人工幹預的運作；第二，性能采集至少進行2小時且期間的性能波動不超過2%。這些都是實際生産系統的要求。
整個測試不限硬體和軟體，隻要能夠通過測試（需要公開系統組成和價格）。
TPC-C benchmark記錄分為幾種：in-review，active，history。當結果剛做出來，審計通過之後，在網站上的狀态是in-review，即公示期，這個公示期是60天。在公示期之内，任何人都可以對該結果提出質疑，測試廠商必須要解釋清楚這個質疑，甚至有可能再跑一遍benchmark。與此同時，TPC也規定一旦進入in-review的狀态，廠商已經可以對外宣傳。當然與此同時，廠商也需要承擔一定的風險：如果最後的結果被人質疑并且沒有通過，這個結果是會被撤銷的，被撤銷的結果在TPC網站上是查不到的。
是以在整個測試過程中，OceanBase用的都是最最保守的方式，用最高的要求，比如性能采集，OceanBase使用的不是2小時而是8小時，在整個8小時中性能波動不是<2%而是<0.5%，這使得OceanBase最後測出的性能曲線幾乎是一條直線。全球一共有3位TPC-C的審計員，都在美國，這次OceanBase的TPC-C測試是由其中的兩位審計員聯合審計通過。
還有一種記錄是active，就是公示期結束之後的結果，這時使用者可以用披露書上價格買到整套系統。另外一種記錄是history，記錄依然是有效的，但由于時間等原因系統的部分元件（特别是硬體）不再有售，是以整套系統不再完整有售。
肯定會有人好奇，在整個TPC-C的曆史上， IBM也曾經高居榜首幾個月，然後很快被Oracle超過了。為什麼Oracle結果已經出來九年多了，這個期間沒有廠商測出更高的tpmC，包括Oracle自己？
第一個原因是測試TPC-C benchmark的投入。進行TPC-C測試需要投入人力和物力，傳統資料庫廠商要測出一個較高的tpmC，高端伺服器和高端存儲是一筆不小的投入。這個投入不是披露書中的成本，後者是整個系統三年的總體擁有成本，比如OceanBase披露的大約是3.8億，這實際上是整個系統三年所有的成本，包括軟體、硬體和服務的總體擁有成本。得益于阿裡雲公有雲虛拟機的按需租賃，OceanBase實際的測試成本跟這個三年總體擁有成本相比有不止一個數量級的差距。
第二個原因是即便參與，如果最後的結果依然不如Oracle，主流廠商很可能甯可不測。沒有挑戰，那麼Oracle自己也沒有必要和動力去重新整理這個記錄，況且做更高的tpmC至少要花千萬計的美元，是一個不菲的成本。Oracle在這9年多的時間也不是什麼都不做，它至少做了兩件事：第一，2012年Oracle用X2-8 x86Server單機測出500萬tpmC，第二，又過了一年，2013年Oracle用T5-8 SparcServer單機測出850萬tpmC。Oracle在測出3000萬tpmC時用了27台伺服器的RAC，500萬tpmC乘以27，甚至850萬乘以27，哪怕結果做不到線性，也會是一個上億的結果。競争對手如果沒有把握，就不會輕易去挑戰。OceanBase之是以敢于挑戰，就是因為自身的分布式水準擴充能力，而RAC的有效節點數是十分有限的。
坦率的說，OceanBase跟Oracle比在功能上還有不小的差距，單機的性能也有距離， OceanBase最大的優勢是可以用多個廉價的伺服器達到昂貴高端硬體所能達到的極緻性能以及更高的可用性。
從OceanBase立項第一天起，我們的目标就是做一款通用的資料庫。當我們在解決了内部用得好的問題以後，我們就把更多的精力投入到外部市場上。是以OceanBase自2017年對外商用以後，今天已經在幾十家商業銀行落地應用。
未來，OceanBase還有很長的路要走，比如在走訪客戶的過程中我們發現，絕大部分業務既需要OLTP又需要OLAP，而這正是OceanBase的産品目标：同時支援OLAP和OLTP，即HTAP。TPC-C是一個很好的起點，我們也希望基于這個起點能夠不斷磨砺産品，讓這樣一款通用型的資料庫未來能夠為整個社會提供更好的服務。
《OceanBase TPC-C測試技術解析》電子書
OceanBase 登頂TPC-C測試榜實作中國資料庫零的突破，想要了解背後的技術細節？
歡迎下載下傳電子書《OceanBase TPC-C測試技術解析》
長按識别以下二維碼，關注“OceanBase”官方公衆号并在對話框内回複“TPCC”即可免費下載下傳