(转载)(收藏)OceanBase深度解析
一、OceanBase不需要高可靠服務器和高端存儲
OceanBase是關系型數據庫,包含內核+OceanBase云平臺(OCP)。與傳統關系型數據庫相比,最大的不同點,
是OceanBase是分布式的,支持水平線性擴展;基于PC服務器,無高可靠服務器,無高端存儲(共享存儲)。與一些傳統數據庫背后一定要有共享存儲相比,這是完全不同的。
現在OceanBase已經在天貓、支付寶、淘寶、一淘等多處使用。2014年的雙11交易中,只承擔了10%流量,但是今年雙11中已經承擔國內交易100%流量,國際交易100%流量,會員50%流量,支付充值50%流量等。
要知道,交易多套核心系統在OceanBase之前都是某商業數據庫的,這也是業內廣為流傳的故事了。
(1)2015年雙11:
(2)00:05:01:交易創建達到峰值14萬筆/秒;
(3)00:09:02:支付達到峰值8.59萬筆/秒。
若對這組數字無感,做個對比。Visa支付峰值是1.4萬筆/秒(在實驗室測試是5.6萬筆/秒);MasterCard實驗室測試是4萬筆/秒。
但是現在有個一直困擾業內的問題:支付為何比交易要低?交易創建時,支付寶內部就可以實現。但是要支付,涉及扣款,來源可以是余額寶、花唄與銀行渠道,比如信用卡和儲蓄卡等,尤其銀行渠道方面,其中都需要交互時間。一般來說,傳統銀行峰值多是在幾千筆每秒。
這樣的交易筆數在全球都是遙遙領先的。
當然,過程并非完全一帆風順。例如去年曾經一塊硬盤壞了,還好有容錯,自身屏蔽了。今年沒有硬盤故障,但是有一個業務在壓測環節沒有發現,其查詢量極大,且隨著交易量增加而增加,每整分鐘都會有查詢產生,指向應該是備庫,但是實際是卻是指向了主庫。因此技術工程師發現每個整分鐘都有交易抖動。最后采用了緊急變更的方法,將查詢調到備庫才得以解決。
數據庫有很多技術重點。但有幾點很重要,第一是可靠性。
先分析下傳統方式,如傳統數據庫+高端共享存儲,或冗余方式來實現。服務器也要高可靠。所以要實現5個9,軟件、存儲、服務器都很貴,服務也貴。而為了避免不可控因素,傳統數據庫形成了主備鏡像。有三種方式:
(1)Maximize Protection
(2)Maximize Performance
(30Maximize Availability
上面三種方式各有利弊。事實上,傳統方式的可靠性很好,但是在可擴展能力、成本(性價比)上才是制約。
相比之下,PC服務器集群,性價比高、水平擴展、易于采購和維護等,亮點多多。但制約只有一個,穩定性可用性不如高端服務器和高可靠存儲。如果說高端服務器和存儲可以做到5個9,那x86 PC服務器能做到3個9就不錯了。所以機器不可靠,但系統就必須要可靠。這就是云計算的思路。同一數據存在多地。那么每個事務到達超過半數庫時,少數庫故障肯定就不會影響業務。
再引用一段博客內容的分析,如下所示:
為此,OceanBase引入了Paxos協議,每一筆事務,主庫執行完成后,要同步到半數以上庫(包括主庫自身),例如3個庫中的2個庫,或者5個庫中的3個庫,事務才成功。這樣,少數庫(例如3個庫中的1個庫,或者5個庫中的2個庫)異常后業務并不受影響
如圖1所示:
圖1
那么現在有個問題:存了3份數據,是否只利用了三分之一的服務器?不是的,由于磁盤空間會有浪費,但是比共享存儲要少的多。而且備份服務器也是其他系統的主服務器。要實現高可靠性,這一點浪費是必須的。
二、版本升級是數據庫故障最大發生處
傳統數據庫的版本升級是最要注意的。一些大的故障多是由于這樣。業內有些做法是先升級備庫,升級完成后,將主庫遷移過來。但是這一過程也要打問號。由于版本升級造成數據庫問題,業內屢見不鮮。例如2013年某國有大商業銀行因為數據庫版本升級,造成業務停頓近1小時。再如2014年某國的簽證數據庫罷工(后查明是因為一個小補丁),20萬份簽證被拖延幾星期。
相對這些傳統數據庫,幾年才出一個版本,內核開發測試團隊就有千人,只有覺得很可靠時,才會對外發布。但是互聯網節奏不容許如此,因此OceanBase面臨的挑戰更大。為了快速響應業務需求,OceanBase最初一個星期會發幾個版本,現在則是1-2周發布一個版本。
OceanBase開發之初就開始思考這個問題。即使到現在,從1個測試人員到現在十幾,OceanBase的測試團隊連人家零頭都不算。問題始終存在,辦法總要想去來——灰度升級。
我們來詳細分析下:
與傳統數據庫相比,OceanBase的另外一個關鍵特征是軟件版本的灰度升級。主備方式的傳統數據庫是“單活”的,只有主庫可執行寫事務,盡管維護升級時可以先操作備庫,操作完成后備庫變成主庫并且接受用戶訪問是一步到位的,如果新版本有問題,則業務受到影響。而OceanBase則是“多活”設計,即多個庫(3個,5個等)每個都可以有部分讀寫流量,升級時先把要升級的庫的讀寫流量切走,升級后先進行數據對比,正常后逐步引入讀寫流量(白名單,1%,5%,10%......),一切正常并運行一段時間后再升級其他的庫。如下圖所示:
圖2
圖3
圖4
例如出現新版本異常,趕快將新版本上的流量切走。對業務的影響是可控的。另外,每個事務帶64位校驗碼,每個表及每個列帶64位校驗碼,都來保證事務與表列的正確性。
三、OceanBase與傳統數據庫的技術區別
OceanBase與傳統數據庫(如mysql)的技術區別,有三個問題值得關注,如下所示。
(1)為什么像mysql這樣的傳統數據庫難以灰度升級?因為傳統數據庫備庫就是備庫,不是Active的,只有出現問題或者升級替換時才會變成主庫。而OceanBase每個庫都是Active。
(2)為什么傳統數據庫不可以用PC服務器代替高端服務器和存儲?一方面是一臺普通PC服務器不能撐住傳統數據庫,且出現故障幾率大,另一方面是軟件機制需要做很大更新,而傳統數據庫是將這些硬件可靠性通過高端產品來實現,而專心做SQL優化、IO優化、排序優化等。
(3)為何數十年來,數據庫方面很少有能夠挑戰某商業數據庫的統治地位?由于數據庫事務(ACID)實現非常復雜,業務對數據庫的穩定性要求極高。也因為磁盤IO瓶頸嚴重制約著數據庫的性能,用同樣的技術實現途徑,其他廠商很難超越它,而全內存數據庫成本太高。
那么OceanBase的切入點是在哪里?
隨著發展,現在的數據庫存儲的數據量越來越大,多是以TB來統計。但是一天修改量并不大,增刪改(修改)只是很少的一部分,比如賬務庫、全國人口數據庫、交易庫都是這樣。基于這樣的原則,OceanBase用磁盤存儲數據庫,但是用內存數據庫來存儲修改數據,沒有額外成本。還消除了隨機寫磁盤,批量來寫入,非常適合SSD(固態盤)【進一步解釋下,普通磁盤最怕隨機讀,但SSD很適合。利用這一特性,OceanBase每天一次真正同步修改到磁盤上】。修改增量融合也采用了多庫異步的方式,避免了對業務的影響。我們要知道,以塊為單位來設計的數據庫是很難做到這一點的。
目前,OceanBase已經廣泛使用在阿里集團的金融領域,比如支付、交易、清算等。今年雙11還成功承擔了開篇時提到的任務。
要注意的是OceanBase 1.0還消除了UpdateServer單點,且正從語義+協議方面完全兼容MySQL,DBA可以將MySQL完全替換成OceanBase,但是應用層是完全感知不到的。對業務完全透明,這樣至少能將數據庫服務器減少一半。
OceanBase即將在2016年放到阿里云上對外提供服務。最后,技術同學們喜歡將OceanBase稱為OB。
?
轉載自:(http://transcoder.baidu.com/from=844b/bd_page_type=1/ssid=0/uid=0/pu=sz%401320_2001%2Cta%40iphone_1_10.1_3_602%2Cusm%401/baiduid=CAD12093536B7F67F1A154DC022C9A4F/w=0_10_/t=iphone/l=3/tc?ref=www_iphone&lid=15345513068300911445&order=5&fm=alop&tj=www_normal_5_0_10_title&vit=osres&m=8&srd=1&cltj=cloud_title&asres=1&title=深度解析OceanBase&dict=32&w_qd=IlPT2AEptyoA_yiqH5KgJS1trABVp8Iou6kYfxq&sec=16616&di=8572ff84896d639e&bdenc=1&tch=124.399.96.871.2.565&nsrc=IlPT2AEptyoA_yixCFOxXnANedT62v3IEQGG_89GQTq5jo39h47aUbB3YyPuMnaJJjb9rXGPfQoDln_d_mMskNYWgK&eqid=d4f636d4e430c000100000015826d2b0&wd=&clk_info=%7B%22srcid%22%3A%221599%22%2C%22tplname%22%3A%22www_normal%22%2C%22t%22%3A1478939326718%2C%22xpath%22%3A%22div-a-h3%22%7D)
轉載于:https://www.cnblogs.com/gaoxufei/p/6056983.html
創作挑戰賽新人創作獎勵來咯,堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的(转载)(收藏)OceanBase深度解析的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: PHP获取客户端ip的五种方式
- 下一篇: Bash 入门教程10-处理用户输入