年夜家好,給年夜家介紹一下,這是我男神@VAGE

呂海波

國內知名數據庫技術專家、數據架構師

曾任阿里/京東/ebay高級專家、首席DBA

Oracle傳奇技術年夜師

ITPUB Oracle 管理版版主

噔噔噔,呂年夜主筆數據庫系列文章——《數據庫傳奇》,從數據庫選型例子入手,介紹SQL和NoSQL數據庫的特點,把所有數據庫的特性、適用范圍,加上一些業內故事、傳說,寫上一遍.

本著“一般不出手,出手便是大作”的原則,文章更新不定期.本期推出《數據庫傳奇》第一章：Digg啟示錄----你選對數據庫了嗎?

未來的世界是屬于數據的,而數據則存儲在數據庫中.數據庫,無疑是企業所有應用的基石.數據庫種類有很多,你選對數據庫了嗎?

美國有一家互聯網公司,Digg.創辦于2004年,又叫掘客,便是個新聞網站,但不同于傳統的新聞門戶,Digg根據用戶的行為(差不多便是評論、點贊之類的),決定那些新聞顯示在首頁.這在當年叫做Web2.0,由用戶決定顯示什么東西,火的不得了.

它開創了Web2.0概念,首創“用戶創造內容”先河,在美國互聯網公司中,曾一度排名第24位,其地位相當于中國的知乎和豆瓣.Google曾想花5億美元收購它,但被其開創人拒絕.

Digg之前一直在使用MySQL數據庫,直到遇到了這個人

約翰·奎恩(John Quinn),曾在Oracle但任工程師,是數據庫老鳥一枚.

2010年時,Digg發展一路高歌大進,相應的,數據庫的壓力,自然也是高歌大進.

數據庫壓力年夜,怎么破?

現在地球人都知道,分庫分表啊.

糾正一下,“分庫分表”其實不是學術上的叫法,專業術語叫“數據分區”,也便是Partition.不過,咱們也不是要討論特理論的學術問題,什么CAP之類的.咱們還是沿用“分庫分表”的叫法.

分庫分表可不是你說想分就分的,涉及應用改造、一致性、數據同步等等一系列繁雜無比的問題.

業內第一家分庫分表的公司,是美國電商ebay.ebay的架構師早在2003年,率先提出了分庫分表的方案,并勝利實施.

不外,要說影響力最大的,還是阿里巴巴.

阿里巴巴利用分庫分表技術,實現了超大規模分布式數據庫,將絕大部分數據移到了開源的MySQL,或自研的OceanBase(當然,仍有少量關鍵數據在Oracle).而且多年來成功應對超高并發的“雙十一”,讓美國同行都為之驚訝不已.其推出的名詞“去IOE”,甚至上了央視某新聞頻道.

所以從影響力上說,阿里巴巴讓分庫分表成為了專有名詞,牛.

轉過頭再說約翰·奎恩.2010年初,奎恩此時已經在Digg高居VP(副總裁),并剛剛擔任CTO不久.Digg的數據層辦理方案,使用的是MySQL,本來也是分庫分表的,只是分的不徹底,面對數據庫壓力逐步增大的情況,需要進一步的、更加徹底的分庫分表,這就要求對應用進行大范圍的改造.

2010年,彼時國內NoSQL如清風拂面,但在太平洋對面的美國西海岸,世界第一大灣區——舊金山灣,美國的高科技產業聚集地,也便是硅谷,NoSQL已如颶風般摧枯拉朽.

奎恩顯然沒有經受住颶風的吹拂.

2010年初,圣誕節的假期剛結束,Digg的員工意猶未盡地回到工作崗位,去MySQL換Cassandra的工作就正式開始了.

Digg并不是第一家嘗試Cassandra的公司.Cassandra,作為當年炙手可熱的NoSQL數據庫,誕生自社交巨頭FaceBook,而后另一個社交巨頭Twitter也采納了Cassandra.當年可謂是最成功的NoSQL數據庫.

有別人家的勝利經驗,再加上自家數據庫團隊的充分測試,奎恩終于決定動手了.

根據數據庫團隊的測試結果,Cassandra性能更快,而且擴容更加便利.

打動奎恩的,正是擴容便利.

好比,有一個集群中有20臺主機,現在由于性能不足,需要擴展到30臺.基于MySQL的分布式當然也可以擴容,但每次擴容都是傷筋動骨的大動作,搞的數據庫團隊人困馬乏.

相比之下,性能表現更加出色的Cassandra,擴容是非常便利的.有了這個特性,數據庫壓力增大多少,就擴多少臺主機,甚至還可以減少壓力不高集群的主機數量,這才是真正的動態擴展啊.

有了Cassandra,工作更輕松.

為什么MySQL的分布式擴容復雜,而NoSQL的Cassandra分布式擴容就簡單呢?這個問題并不容易答復,我抖膽為大家解讀一下.(以下滿滿都是干貨)

這個問題,是公眾認為“NoSQL是散布式、SQL型數據庫不是散布式”的重要原因之一.

分布式,最關鍵的部件是“路由”,它相當于“轉達室”.

假如這家單位有100間辦公室,你要找老張,但你并不知道老張在哪兒,你先到轉達室問了一下：“同志,老張在那個辦公室”.

傳達室告訴你,“老張在二樓左邊第二個辦公室.”然后,你去找老張做事.

這里,傳達室就是一個“路由”,或叫做“轉發器”.他并不能為你做事,他只是告訴你,你要找的人在哪兒.

分布式數據庫中的路由部件同樣,它不克不及執行你的操作,他只是告訴你,你要操作的數據應該在哪里,哪個sub database(子數據庫)可以完成你的操作.

更進一步,為了優化人員結構,這家單位裁撤了傳達室,設置一種規則,根據規則一下子就可以算出要找的人在哪里.好比說,有一家單位

(對,便是白宮,看圖片一點都不宏偉)假設一共有30個辦公室,規則如下,按人名筆畫數,除以30,余數為幾,就在幾號辦公室工作.

好比,總統先生,唐納德·特朗普,應該在幾號辦公室?

唐納德·特朗普,筆畫數一共64,除以30,余數為4.

總統先生在4號辦公室辦公.

前總統奧巴馬呢,貝拉克·侯賽因·奧巴馬,筆畫數一共68,除以30,余數為8,依照我們的規則,前總統先生在8號辦公室.

怎么樣,這樣一來,每次你去白宮找人做事,只需要根據人名筆劃數計算一下,就知道要找的人在哪里了.通過這種方式,不再有“傳達室”,可以少花納稅人的錢.路由方式,則變成了“規則”(即筆劃數除以30取余).

規則式路由,是分布式數據庫最常采納的.而“筆劃數除以30取余”這樣的規則,則屬于HASH規則類.

在IT領域中,根據某種確定的方式,將一個數字進行計算,得到另一個數字,這就是HASH算法的本色,對HASH在這里不必深究,以后再專門開篇文章好好講講這些著名的算法.

我們例子中的HASH規則,像不像一樣生活中常見的東東,給你三秒想一下,是什么：

目錄

沒猜出來,對嗎!沒關系,翻開一本新華字典,它的目錄編排方式,便是一種HASH規則.

Oracle、MySQL等SQL型數據庫的分布式便是這樣,基于某種HASH規則,將數據存儲在某一個Sub Database(子數據庫中).操作數據時,同樣根據HASH規則,計算得出數據存儲在哪一個Sub Database中,然后到相應的Sub database中執行操作.

說白了,便是先查一下目錄再翻書.

這里有一個問題,好比隨著人員的擴展,白宮的辦公室不夠用了,預算部門決定明年新增1間辦公室.這就是分布式數據庫的擴容了.也叫橫向擴展.

辦公室數量增加到31之后,本來的規則“筆劃數除以30取余”,要改為“筆劃數除以31取余”了,除以30,要改為除以31了.因為現在辦公室數量已經由30增至31了.

總統先生唐納德·特朗普的筆劃數是64,基于本來的HASH規則,是在4號辦公室,但現在,他應該在2號辦公室.64除以31余數是2了.

前總統奧巴馬呢,貝拉克·侯賽因·奧巴馬,筆畫數一共68,除以31,余數為6.前總統先生的新方法室在6號.

不只總統先生,副總統、各位參贊、秘書,所有人的辦公室都變了.除以30取余,和除以31取余,結果將大不相同.

這就是為什么分布式數據庫擴容這么難了.原來30個子庫,擴展到31個子庫,所有數據要全部改變一下它所屬的子庫.所有數據都要輾轉騰挪一邊,這當然是個大工程了.

而Cassandra有一個非常好的特性,它的分布式是依照一致性HASH算法,計算數據應該存儲在哪個Sub Database(子數據庫).一致性HASH,英文名稱Consistent Hashing.它是普通HASH算法的修正,目的就是為了解決HASH算法在擴容(或縮容)時,要對所有數據重新計算HASH值的問題.

說到Consistent Hashing,不克不及不上一張圖：

所有介紹Consistent Hashing的文章,都必須祭出這張圖,才能顯得本身專業.我們就不照這個圖解說了,來個簡單的.

這次咱們又要到五角年夜樓找人了.假設五角年夜樓只有5個辦公室,分別分布在5個角上.

這次又要怎么支配辦公室呢?姓名筆畫數除以5取余嗎?先別急做除法,雖然目前五角大樓辦公室數少,但它目標宏大：

據說,很快就會發展到30間辦公室.可目前只有5間,不要緊,要面向未來嗎!

具體怎么做呢?先把5間辦公室的編號改的年夜氣點：

1號辦公室就不叫“1號”了,為了面向未來,直接叫“6號辦公室”.然后,2號改為12號,3號改為18號,以此類推.

好了,現在五角年夜樓已經有30號辦公室了.

看圖片,沒有1、2、3……直接蹦出來個6,然后是12,等等,這多別扭啊.不要緊,可以發揚無產階級空想精神,假想在6號前面,有1、2、3、4、5號辦公室存在.當然,它們現在還不存在,可以稱它們為虛擬辦公室,如下圖：

(圖中的1到5,7到11,都是虛擬辦公室)

現在,每名五角大樓工作人員,按姓名筆畫數除以30別的,余數為1到6的,在6號辦公室(原1號).余數為7到12的,在12號辦公室(原2號)等等,以此類推.

除以30其余,計算出的是虛擬辦公室編號,只要順時針向后找,找到的第一個實際辦公室,便是真正所在的辦公室.

如果兩位總統先生到了五角年夜樓,應該在哪個辦公室呢?

現總統先生唐納德?特朗普的筆劃數是64,除以30取余是4,也便是虛擬辦公室編號為4,順時針向后找,第一個大于4的實際辦公室是6號.所以特朗普在6號辦公室.

而前總統貝拉克?侯賽因?奧巴馬先生,筆畫數一共68,除以30取余是8.

如上圖,從8開始,順時針向后找,奧巴馬在12號辦公室.

這就是一致性HASH的計算過程.現在,讓我們把配景礙眼的五角大樓圖去掉：

是不是和下面官方資料中的圖比擬像了?

(特別闡明：文中虛擬辦公室和Cassandra中的虛擬節點并不是一個概念).

相較普通的HASH,一致性HASH的優點是擴/縮容的時候影響小,這一點如何表示出來的呢?看下圖：

現在要在18到24之間增加一間實際辦公室.原來19到23號虛擬辦公室的人,都按排在24號實際辦公室辦公的.或者說,19到23,屬于24.

假設21變為了實際辦公室：

原來都屬于24號,19到23,又如何支配呢?很簡單啊,原則一樣,“順時針向后找,第一個實際辦公室就是最終位置”.按照新的辦公室數量,22號、23號虛擬辦公室,還屬24號實際辦公室不變.19號、20號則屬于新的21號辦公室.

重點是,在18和24號辦公室之間新增一個辦公室,只影響在24號辦公室中的人.其他實際辦公室的人不會有任何變化.這便是一致性HASH的獨特之處.

在只有5個實際辦公室的情況下,使用普通HASH算法,增加一個辦公室,影響所有人.所有人都要重新計算地位.一致性HASH算法,只有五分之一的人受影響.

我們把“辦公室”換成節點,把“人”換成數據,再把實際辦公室數量增年夜.如果有500個節點,節點擴容時,使用一致性HASH算法,只有五百分之一的數據受影響.怎么樣,節點數量一多,擴容或縮容受影響的數據就越少.而普通HASH算法,無論有多少節點,每次擴/縮容都要影響全部數據.

因此,采用了一致性HASH的Cassandra的,理論上擴/縮容的影響會比擬小.正是這個特性,深深的打動了奎恩.在奎恩的推動下,Digg的應用開發部門,重寫了所有的應用代碼,以適應NoSQL的Cassandra數據庫.

不再有SQL,這會使應用的開發更加復雜,但好處也是顯而易見的.橫向擴展(也就是擴容)更加便利、更好的性能……

故事繼續.至2010年8月,Digg的技術團隊完成了這次購模浩大的重構.底層數據庫,勝利換為了NoSQL的Cassandra.

從年初到8月份,年夜半年的時間,對于替換所有底層數據庫這樣的年夜動作來說,還算是快的了.

故事到這里,是不是聽起來像“從此公主與王子幸福的生活在城堡中”?

但可惜,幸福總是短暫的,奎恩很快就會明白這一點.雖然其時,他還不明白.

完成了這次基礎數據庫改造,奎恩已經變身為硅谷科技界紅人,他相當于在硅谷動員了一場去IOE的運動.

時間到了2010年9月份,“去M”(去MySQL)才剛一個月.在這一個月內,Digg最繁忙的部分,是客服部.

自從改版之后,Digg的網站一直處于非常不穩定的狀態,各種功能頻繁出錯,很多時候站點干脆就沒法拜訪.

怒火高漲的用戶打爆Digg的客戶電話,然而,既使把客服人員爆打一頓,仍然沒什么卵用,網站依舊頻繁失足.

最危險的情況出現了,大量用戶棄Digg,開始玩起了類似的Reddit.想象一下,豆瓣由于網站經常打不開,大量用戶棄豆瓣轉向知乎.(免責聲明,此處只是比方,此種情況并沒發生在豆瓣和知乎之間).

9月份時,Digg的拜訪量跌到了谷底.而競爭對手Reddit的拜訪量再創新高,并在12月份超過Digg,從此把 Digg 遠遠地甩在了后面,絕塵而去.

有些東西,失去了就再也不會回來.Digg便是這樣,后來又經歷了一系列的調整,Digg才終于明白,應該讓合適的場景使用合適的數據庫.但一切都為時已晚,機會窗口已經關閉.

Digg勉強維持了將近兩年,到2012年7月,被Betaworks 收購,收購價僅為 50 萬美元.與顛峰時期 Google 接近 5 億美元的收購意向相比,其縮水水平令人瞠目結舌.

這么大的錯誤,總要有人背鍋,約翰·奎恩自然難逃其咎.在成功改換數據庫一個月后,也便是當年9月份,奎恩就從高點跌到低點,面對憤怒的用戶,和頻繁出錯的網站,奎恩不得不黯然離開Digg.

但數據庫團隊的大部分人都沒動,雖然數據架構的負責人是最直接的責任人.但由于接下來數據架構的調整還是必要他們,這個時候辭退數據庫部門的重要技術人員,不單于事無補,反而更加雪上加霜.

數據架構人,只是結合Digg的場景,對Cassandra進行了測試.測試是大量的、復雜的,而且耗時必定不短,最終得出了相對于MySQL,Cassandra性能更佳、擴容更方便的結論.但實際應用場景的復雜度,是測試無法模擬的.

而且,NoSQL并不是解決所有問題的銀彈.幻想有一種辦法,可以解決一切問題,這本身就違背了系統架構師的基本法則.

“合適的場景,使用合適的數據庫”,才是真正的王道!

一個“慘痛”的數據庫選型的例子,告訴我們,數據庫選擇的重要性.那如何選擇得當的數據庫,SQL和NoSQL數據庫各有什么特點?

欲知后事如何,請聽下回分化!