OceanBase性能測試成績超過Oracle的原因

代碼兩邊都沒開源,git上面有三年前的OceanBase代碼垂涯,感興趣的可以研究一下颖侄,這篇文章主要就從架構上面分析OceanBase跟Oracle的區(qū)別,找到OB勝出最本質的原因室抽,OB這邊的資料主要來源是官方文檔https://oceanbase.alipay.com/docs/oceanbase/OceanBase%E6%A6%82%E8%A7%88

1.分布式架構

Oracle使用最廣的RAC集群是一種基于share disk的架構,多實例跑在不同的服務器上靡努,共享數(shù)據(jù)存儲坪圾。


oracle rac

OB的分布式架構,我覺得跟kafka的思想類似(OB的開發(fā)者更多的去類比google的F1等)惑朦,是一種分區(qū)+副本的架構兽泄,每個分區(qū)有多個副本,副本分leader漾月,follower病梢,主副本所在的zone,被稱為Primary Zone 梁肿,選主和日志同步采用的也是paxos算法蜓陌,機制跟kafka如出一轍。


屏幕快照 2019-10-17 下午4.10.47.png

小結:在架構上吩蔑,oracle rac是一種share disk的模式钮热,這種集群可以支持的節(jié)點數(shù)是有限的。
OceanBase是一種share nothing的模式烛芬,是真正的分布式霉旗,分區(qū)數(shù)可以成千上萬,每個分區(qū)可以三副本蛀骇,可以五副本(對于普通單表厌秒,OB的一個分區(qū)就是一張表,而對于分區(qū)表擅憔,OB的一個分區(qū)對應表的一個分區(qū))鸵闪。在高可用方面,OceanBase在架構層面就天然比oracle要強暑诸,之前的云棲大會也演示過現(xiàn)場把某個節(jié)點的服務器網(wǎng)線剪斷蚌讼,服務在26秒之內恢復正常辟灰。Oracle集群如果存儲服務掛掉,那么整個集群都將不可用篡石。

2.存儲

Oracle采用的是內存bufferCache+磁盤IO的模式芥喇。對數(shù)據(jù)的讀寫盡量在內存bufferCache中進行,會有進程負責將bufferCache中的冷數(shù)據(jù)和臟數(shù)據(jù)寫入到磁盤中凰萨。


oracle存儲

OB把數(shù)據(jù)分成基線數(shù)據(jù)和增量數(shù)據(jù)继控,增量數(shù)據(jù)放在內存中,叫MemTable胖眷,基線數(shù)據(jù)放在ssd盤中武通,叫SSTable,大部分dml操作都在內存中完成(官網(wǎng)文檔不是很嚴謹珊搀,說所有DML操作都在內存中完成)冶忱,性能會非常高。內存中的增量數(shù)據(jù)達到一定規(guī)模后境析,觸發(fā)增量數(shù)據(jù)和基線數(shù)據(jù)的合并囚枪,即增量數(shù)據(jù)落盤。


ob存儲

寫操作完全是內存操作比較好理解劳淆,寫完內存中的MemTable返回即可眶拉,后續(xù)再異步的跟基線數(shù)據(jù)合并落盤。
為了增加讀操作的性能憔儿,會有Block Cache和Row Cache兩層內存cache,對于不存在的行的空查放可,會有布隆過濾器過濾谒臼。但是讀操作不能保證是完全的內存操作,比如基線和增量里面都有id=1的數(shù)據(jù)記錄耀里,基線數(shù)據(jù)中該記錄為A蜈缤,C,D冯挎,增量數(shù)據(jù)中該記錄為B底哥,C,F(xiàn)房官。按照上圖趾徽,會有Block Cache和Row Cache,如果這兩層Cache中包含id=1的數(shù)據(jù)記錄翰守,那么這個查詢是內存操作可以理解孵奶,內存中一合并就好了。但是如果這兩層Cache不包含id=1的數(shù)據(jù)記錄呢蜡峰,那么肯定是要對基線數(shù)據(jù)直接進行一次合并的了袁,那就會有磁盤IO朗恳,因為Cache不可能包含全量的基線數(shù)據(jù)。之前看到文章說载绿,單機的情況下粥诫,OceanBase性能是不如Oracle的。

3.總結

個人理解崭庸,OB之所以在性能測試上面能擊敗Oracle怀浆,最主要還是依賴分布式的架構,其他的點:比如存儲冀自,sql揉稚,分布式事務等都是為此服務的。而且單機的Oracle性能比OB要強熬粗,這點上搀玖,OB提升的空間還很大,如果將來OB的單機性能能夠接近或者超過Oracle驻呐,那么OB的性能還將上升一個臺階灌诅。
絕大多數(shù)的互聯(lián)網(wǎng)公司發(fā)展到一定規(guī)模,出于性能和成本的考慮含末,會有去Oracle的計劃(淘寶也有這個過程猜拾,CBU的總裁七公就是淘寶的Oracle元老),替代者往往是Mysql佣盒。這么做的問題點就是Mysql在做分布式的架構時挎袜,需要中間件的輔助,同時需要運維人員比較強的能力肥惭,OceanBase最大的優(yōu)勢就是可以直接提供出一個商業(yè)化盯仪、分布式的關系型數(shù)據(jù)庫,配合上云蜜葱,那么對于去O的公司來說全景,OceanBase絕對會是個非常有競爭優(yōu)勢的產品,期待OB外部商業(yè)化的成功牵囤。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末爸黄,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子揭鳞,更是在濱河造成了極大的恐慌炕贵,老刑警劉巖,帶你破解...
    沈念sama閱讀 210,978評論 6 490
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件野崇,死亡現(xiàn)場離奇詭異鲁驶,居然都是意外死亡,警方通過查閱死者的電腦和手機舞骆,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 89,954評論 2 384
  • 文/潘曉璐 我一進店門钥弯,熙熙樓的掌柜王于貴愁眉苦臉地迎上來径荔,“玉大人,你說我怎么就攤上這事脆霎∽艽Γ” “怎么了?”我有些...
    開封第一講書人閱讀 156,623評論 0 345
  • 文/不壞的土叔 我叫張陵睛蛛,是天一觀的道長鹦马。 經常有香客問我,道長忆肾,這世上最難降的妖魔是什么荸频? 我笑而不...
    開封第一講書人閱讀 56,324評論 1 282
  • 正文 為了忘掉前任,我火速辦了婚禮客冈,結果婚禮上旭从,老公的妹妹穿的比我還像新娘。我一直安慰自己场仲,他們只是感情好和悦,可當我...
    茶點故事閱讀 65,390評論 5 384
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著渠缕,像睡著了一般鸽素。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上亦鳞,一...
    開封第一講書人閱讀 49,741評論 1 289
  • 那天馍忽,我揣著相機與錄音,去河邊找鬼燕差。 笑死遭笋,一個胖子當著我的面吹牛,可吹牛的內容都是我干的谁不。 我是一名探鬼主播,決...
    沈念sama閱讀 38,892評論 3 405
  • 文/蒼蘭香墨 我猛地睜開眼徽诲,長吁一口氣:“原來是場噩夢啊……” “哼刹帕!你這毒婦竟也來了?” 一聲冷哼從身側響起谎替,我...
    開封第一講書人閱讀 37,655評論 0 266
  • 序言:老撾萬榮一對情侶失蹤偷溺,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后钱贯,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體挫掏,經...
    沈念sama閱讀 44,104評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 36,451評論 2 325
  • 正文 我和宋清朗相戀三年秩命,在試婚紗的時候發(fā)現(xiàn)自己被綠了尉共。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片褒傅。...
    茶點故事閱讀 38,569評論 1 340
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖袄友,靈堂內的尸體忽然破棺而出殿托,到底是詐尸還是另有隱情,我是刑警寧澤剧蚣,帶...
    沈念sama閱讀 34,254評論 4 328
  • 正文 年R本政府宣布支竹,位于F島的核電站,受9級特大地震影響鸠按,放射性物質發(fā)生泄漏礼搁。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,834評論 3 312
  • 文/蒙蒙 一目尖、第九天 我趴在偏房一處隱蔽的房頂上張望馒吴。 院中可真熱鬧,春花似錦卑雁、人聲如沸募书。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,725評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽莹捡。三九已至,卻和暖如春扣甲,著一層夾襖步出監(jiān)牢的瞬間篮赢,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 31,950評論 1 264
  • 我被黑心中介騙來泰國打工琉挖, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留启泣,地道東北人。 一個月前我還...
    沈念sama閱讀 46,260評論 2 360
  • 正文 我出身青樓示辈,卻偏偏與公主長得像寥茫,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子矾麻,可洞房花燭夜當晚...
    茶點故事閱讀 43,446評論 2 348