面試官：談?wù)劄槭裁匆鸱謹(jǐn)?shù)據(jù)庫？有哪些方法？
1. 為什么要拆分?jǐn)?shù)據(jù)庫？
單體項(xiàng)目在構(gòu)建之初，數(shù)據(jù)庫的負(fù)載和數(shù)據(jù)量都不大，所以不需要對數(shù)據(jù)庫做拆分，小型財務(wù)系統(tǒng)、文書系統(tǒng)、ERP系統(tǒng)、OA系統(tǒng)，用一個MySQL數(shù)據(jù)庫實(shí)例基本就夠用了。
就像《淘寶技術(shù)這十年》里面說到的，電商業(yè)務(wù)的數(shù)據(jù)量增長飛快，所以最開始的PHP+MySQL的架構(gòu)已經(jīng)不能滿足實(shí)際要求了，于是淘寶想到的第一個辦法就是把MySQL替換成Oracle。但是沒過了多久，在08年前后，單節(jié)點(diǎn)的Oracle數(shù)據(jù)庫也不好用了，于是淘寶終于告別了單節(jié)點(diǎn)數(shù)據(jù)庫，開始拆分?jǐn)?shù)據(jù)庫。從一個節(jié)點(diǎn)，變成多個節(jié)點(diǎn)。
拆分?jǐn)?shù)據(jù)庫是有講究的，比如說拆分方法有兩種：垂直切分和水平切分。那你是先水平切分還是垂直切分呢？順序無所謂？不，順序有所謂，次序絕對不能錯：先水平切分，然后垂直切分。
2. 什么是垂直切分？
垂直切分是根據(jù)業(yè)務(wù)來拆分?jǐn)?shù)據(jù)庫，同一類業(yè)務(wù)的數(shù)據(jù)表拆分到一個獨(dú)立的數(shù)據(jù)庫，另一類的數(shù)據(jù)表拆分到其他數(shù)據(jù)庫。
比如說一個新零售的電商數(shù)據(jù)庫，我們可以把跟商品相關(guān)的數(shù)據(jù)表拆分成一個數(shù)據(jù)庫，然后在這些數(shù)據(jù)表的基礎(chǔ)之上，構(gòu)建出商品系統(tǒng)。比如用JAVA或者PHP語言，創(chuàng)建出一個商城系統(tǒng)。然后把跟進(jìn)銷存相關(guān)的數(shù)據(jù)表拆分到另外一個數(shù)據(jù)庫上，再用程序構(gòu)建出倉庫系統(tǒng)。
垂直切分解決了什么問題
垂直切分可以降低單節(jié)點(diǎn)數(shù)據(jù)庫的負(fù)載。原來所有數(shù)據(jù)表都放在一個數(shù)據(jù)庫節(jié)點(diǎn)上，無疑所有的讀寫請求也都發(fā)到這個MySQL上面，所以數(shù)據(jù)庫的負(fù)載太高。如果把一個節(jié)點(diǎn)的數(shù)據(jù)庫拆分成多個MySQL數(shù)據(jù)庫，這樣就可以有效的降低每個MySQL數(shù)據(jù)庫的負(fù)載。
垂直切分不能解決什么問題
垂直切分不能解決的是縮表，比如說商品表無論劃分給哪個數(shù)據(jù)庫節(jié)點(diǎn)，商品表的記錄還是那么多，不管你把數(shù)據(jù)庫垂直拆分的有多細(xì)致，每個數(shù)據(jù)表里面的數(shù)據(jù)量是沒有變化的。
MySQL單表記錄超過2000萬，讀寫性能會下降的很快，因此說垂直切分并不能起到縮表的效果。
3. 什么是水平切分？
水平切分是按照某個字段的某種規(guī)則，把數(shù)據(jù)切分到多張數(shù)據(jù)表。一張數(shù)據(jù)表化整為零，拆分成多張數(shù)據(jù)表，這樣就可以起到縮表的效果了。
很多人，都會水平切分存在誤解，以為水平切分出來的數(shù)據(jù)表必須保存在不同的MySQL節(jié)點(diǎn)上。其實(shí)水平切分出來的數(shù)據(jù)表也可以保存在一個MySQL節(jié)點(diǎn)上面。不是水平切分一定需要多個MySQL節(jié)點(diǎn)。為什么這么說呢？
許多人不知道MySQL自帶一種數(shù)據(jù)分區(qū)的技術(shù)，可以把一張表的數(shù)據(jù)，按照特殊規(guī)則，切分存儲在不同的目錄下。如果我們給Linux主機(jī)掛載了多塊硬盤，我們完全可以利用MySQL分區(qū)技術(shù)，把一張表的數(shù)據(jù)切分存儲在多個硬盤上。這樣就由原來一塊硬盤有限的IO能力，升級成了多個磁盤增強(qiáng)型的IO。
水平切分的用途
水平切分可以把數(shù)據(jù)切分到多張數(shù)據(jù)表，可以起到縮表的作用。
但是也不是所有的數(shù)據(jù)表都要做水平切分。數(shù)據(jù)量較大的數(shù)據(jù)表才需要做數(shù)據(jù)切分，比如說電商系統(tǒng)中的，用戶表、商品表、產(chǎn)品表、地址表、訂單表等等。有些數(shù)據(jù)表就不需要切分，因?yàn)閿?shù)據(jù)量不多，比如說品牌表、供貨商表、倉庫表，這些都是不需要切分的。
水平切分的缺點(diǎn)
不同數(shù)據(jù)表的切分規(guī)則并不一致，要根據(jù)實(shí)際業(yè)務(wù)來確定。所以我們在選擇數(shù)據(jù)庫中間件產(chǎn)品的時候，就要選擇切分規(guī)則豐富的產(chǎn)品。常見的數(shù)據(jù)庫中間件有：MyCat、Atlas、ProxySQL等等。有些人覺得MyCat是Java語言開發(fā)的，就懷疑MyCat運(yùn)行效率。其實(shí)數(shù)據(jù)庫中間件的作用相當(dāng)于SQL語句的路由器。你家路由器硬件配置不怎么高，但是不影響你享用百兆寬帶。MyCat也是一個道理，它僅僅是起到SQL語句轉(zhuǎn)發(fā)的作用，并不會實(shí)際執(zhí)行SQL語句。我推薦使用MyCat最主要的原因是它自帶了非常多的數(shù)據(jù)切分規(guī)則，我們可以按照主鍵求模切分?jǐn)?shù)據(jù)，可以按照主鍵范圍切分?jǐn)?shù)據(jù)，還可以按照日期切分?jǐn)?shù)據(jù)等等。因此說，為了滿足業(yè)務(wù)的需要，MyCat目前來說算是非常不錯的中間件產(chǎn)品。
水平切分的另一個缺點(diǎn)就是擴(kuò)容比較麻煩，日積月累，分片遲早有不夠用的時候。這時候不是首先選擇增加新的集群分片。因?yàn)橐粋€MySQL分片，需要4~8個MySQL節(jié)點(diǎn)（最小規(guī)模），增加一個分片的投入成本是很高的。所以正確的做法是做冷熱數(shù)據(jù)分離，定期對分片中的數(shù)據(jù)歸檔。把過期的業(yè)務(wù)數(shù)據(jù)，從分片中轉(zhuǎn)移到歸檔庫。目前來說數(shù)據(jù)壓縮比最高的MySQL引擎是TokuDB，而且?guī)е挛锏膶懭胨俣仁荌nnoDB引擎的6-14倍。用TokuDB作為歸檔數(shù)據(jù)庫最適合不過。
4. 為什么先做水平切分，后作垂直切分？
隨著數(shù)據(jù)量的增加，最先應(yīng)該做的是數(shù)據(jù)分片，利用多塊硬盤來增大數(shù)據(jù)IO能力和存儲空間，這么做的成本是最低的。幾塊硬盤的錢就能收獲不錯的IO性能。
進(jìn)入到下一個階段，數(shù)據(jù)量繼續(xù)增大，這時候我們應(yīng)該把數(shù)據(jù)切分到多個MySQL節(jié)點(diǎn)上，用MyCat管理數(shù)據(jù)切分。當(dāng)然還要做數(shù)據(jù)的讀寫分離等等，這里不展開討論。在后臺做水平切分的同時，業(yè)務(wù)系統(tǒng)也可以引入負(fù)載均衡、分布式架構(gòu)等等。理論上，使用了冷熱數(shù)據(jù)分離之后，水平切分這種方式可以繼續(xù)維持很長一段時間，數(shù)據(jù)量再大也不怕，定期歸檔就好了。
數(shù)據(jù)庫到了水平切分的階段，數(shù)據(jù)量的增加已經(jīng)不是更改架構(gòu)設(shè)計的主要原因了。反而這個階段業(yè)務(wù)系統(tǒng)承受不住了，如果再不對系統(tǒng)做模塊拆分，業(yè)務(wù)系統(tǒng)也撐不下去了，所以按照模塊和業(yè)務(wù)，把一個系統(tǒng)拆分成若干子系統(tǒng)。若干子系統(tǒng)之間，數(shù)據(jù)相對獨(dú)立。比如淘寶不會跟支付支付寶分享全部數(shù)據(jù)，共享同一套數(shù)據(jù)表，這也影響各自業(yè)務(wù)的發(fā)展。所以就要弄垂直切分了，把數(shù)據(jù)表歸類，拆分成若干個數(shù)據(jù)庫系統(tǒng)。
講到這里，你仔細(xì)想想。如果過早的對數(shù)據(jù)庫做了垂直切分，勢必要重新構(gòu)建若干獨(dú)立的業(yè)務(wù)系統(tǒng)，工作量太巨大。水平切分并不需要業(yè)務(wù)系統(tǒng)做大幅度的修改，因此說應(yīng)該先從水平切分開始做。
來源：http://www.imooc.com/article/288363
往期資源 需要請自取
喜歡就"在看"唄^_^