百家乐必知技巧
數據庫

OceanBase數據庫創始人陽振坤分享征戰6088萬tpmC的艱辛之路

廣告
廣告

前言:中國人民大學常被譽為是“中國人文社會科學的最高學府”,其實人民大學也是“中國數據庫的發源地”。由中國人民大學教授薩師煊與王珊合作編寫的《數據庫系統概論》是國內第一部系統闡明數據庫原理、技術和理論的教材,也被公認為是國內數據庫領域的經典權威教材。

近期,螞蟻金服高級研究員、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是一個很好的起點,我們也希望基于這個起點能夠不斷磨礪產品,讓這樣一款通用型的數據庫未來能夠為整個社會提供更好的服務。

我還沒有學會寫個人說明!

數據分析利器之Pandas

上一篇

又一知名公司炸雷,大量公司員工被帶走調查

下一篇

你也可能喜歡

OceanBase數據庫創始人陽振坤分享征戰6088萬tpmC的艱辛之路

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
百家乐必知技巧 012彩票网群 快3赚钱技巧 山东群英会走势图46 百人牛牛作弊器下截 天津时时彩 捕鱼游戏截图 广西快三遗漏值统计 河南22选5今晚开奖结果 波克棋牌最新版本2016 什么软件可以合买双色球