建站
咨詢
售后
建站咨詢
新聞中心
中大型項目中，一旦遇到數(shù)據(jù)量比較大，小伙伴應(yīng)該都知道就應(yīng)該對數(shù)據(jù)進(jìn)行拆分了。有垂直和水平兩種。
創(chuàng)新互聯(lián)主營河津網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,App定制開發(fā),河津h5小程序制作搭建,河津網(wǎng)站營銷推廣歡迎河津等地區(qū)企業(yè)咨詢
垂直拆分比較簡單，也就是本來一個數(shù)據(jù)庫，數(shù)據(jù)量大之后，從業(yè)務(wù)角度進(jìn)行拆分多個庫。
如下圖，獨(dú)立的拆分出訂單庫和用戶庫：
水平拆分的概念，是同一個業(yè)務(wù)數(shù)據(jù)量大之后，進(jìn)行水平拆分。
上圖中訂單數(shù)據(jù)達(dá)到了 4000 萬，我們也知道 MySQL 單表存儲量推薦是百萬級，如果不進(jìn)行處理，MySQL 單表數(shù)據(jù)太大，會導(dǎo)致性能變慢。
使用方案可以參考數(shù)據(jù)進(jìn)行水平拆分。把 4000 萬數(shù)據(jù)拆分 4 張表或者更多。當(dāng)然也可以分庫，再分表;把壓力從數(shù)據(jù)庫層級分開。
分庫分表方案
分庫分表方案中有常用的方案，hash 取模和 range 范圍方案;分庫分表方案最主要就是路由算法，把路由的 key 按照指定的算法進(jìn)行路由存放。下邊來介紹一下兩個方案的特點(diǎn)。
①hash 取模方案
在我們設(shè)計系統(tǒng)之前，可以先預(yù)估一下大概這幾年的訂單量，如：4000 萬。每張表我們可以容納 1000 萬，也我們可以設(shè)計 4 張表進(jìn)行存儲。
那具體如何路由存儲的呢?hash 的方案就是對指定的路由 key(如：id)對分表總數(shù)進(jìn)行取模。
上圖中：
- id=12 的訂單，對 4 進(jìn)行取模，也就是會得到 0，那此訂單會放到 0 表中。
- id=13 的訂單，取模得到為 1，就會放到 1 表中。為什么對 4 取模，是因為分表總數(shù)是 4。
優(yōu)點(diǎn)：訂單數(shù)據(jù)可以均勻的放到那 4 張表中，這樣此訂單進(jìn)行操作時，就不會有熱點(diǎn)問題。
熱點(diǎn)的含義：熱點(diǎn)的意思就是對訂單進(jìn)行操作集中到 1 個表中，其他表的操作很少。
訂單有個特點(diǎn)就是時間屬性，一般用戶操作訂單數(shù)據(jù)，都會集中到這段時間產(chǎn)生的訂單。
如果這段時間產(chǎn)生的訂單都在同一張訂單表中，那就會形成熱點(diǎn)，那張表的壓力會比較大。
缺點(diǎn)：將來的數(shù)據(jù)遷移和擴(kuò)容，會很難。如：業(yè)務(wù)發(fā)展很好，訂單量很大，超出了 4000 萬的量，那我們就需要增加分表數(shù)。
如果我們增加 4 個表：
一旦我們增加了分表的總數(shù)，取模的基數(shù)就會變成 8，以前 id=12 的訂單按照此方案就會到 4 表中查詢，但之前的此訂單時在 0 表的，這樣就導(dǎo)致了數(shù)據(jù)查不到。就是因為取模的基數(shù)產(chǎn)生了變化。
遇到這個情況，我們小伙伴想到的方案就是做數(shù)據(jù)遷移，把之前的 4000 萬數(shù)據(jù)，重新做一個 hash 方案，放到新的規(guī)劃分表中。也就是我們要做數(shù)據(jù)遷移。
這個是很痛苦的事情。有些小公司可以接受晚上停機(jī)遷移，但大公司是不允許停機(jī)做數(shù)據(jù)遷移的。
當(dāng)然做數(shù)據(jù)遷移可以結(jié)合自己的公司的業(yè)務(wù)，做一個工具進(jìn)行，不過也帶來了很多工作量，每次擴(kuò)容都要做數(shù)據(jù)遷移。
那有沒有不需要做數(shù)據(jù)遷移的方案呢，我們看下面的方案。
②range 范圍方案
range 方案也就是以范圍進(jìn)行拆分?jǐn)?shù)據(jù)：
range 方案比較簡單，就是把一定范圍內(nèi)的訂單，存放到一個表中;如上圖 id=12 放到 0 表中，id=1300 萬的放到 1 表中。設(shè)計這個方案時就是前期把表的范圍設(shè)計好。通過 id 進(jìn)行路由存放。
優(yōu)點(diǎn)：我們小伙伴們想一下，此方案是不是有利于將來的擴(kuò)容，不需要做數(shù)據(jù)遷移。
即使再增加 4 張表，之前的 4 張表的范圍不需要改變，id=12 的還是在 0 表，id=1300 萬的還是在 1 表，新增的 4 張表他們的范圍肯定是大于 4000 萬之后的范圍劃分的。
缺點(diǎn)：有熱點(diǎn)問題，我們想一下，因為 id 的值會一直遞增變大，那這段時間的訂單是不是會一直在某一張表中。
如 id=1000萬～id=2000 萬之間，這段時間產(chǎn)生的訂單是不是都會集中到此張表中，這個就導(dǎo)致 1 表過熱，壓力過大，而其他的表沒有什么壓力。
總結(jié)：
- hash 取模方案：沒有熱點(diǎn)問題，但擴(kuò)容遷移數(shù)據(jù)痛苦。
- range 方案：不需要遷移數(shù)據(jù)，但有熱點(diǎn)問題。
那有什么方案可以做到兩者的優(yōu)點(diǎn)結(jié)合呢?即不需要遷移數(shù)據(jù)，又能解決數(shù)據(jù)熱點(diǎn)的問題呢?
其實還有一個現(xiàn)實需求，能否根據(jù)服務(wù)器的性能以及存儲高低，適當(dāng)均勻調(diào)整存儲呢?
方案思路
hash 是可以解決數(shù)據(jù)均勻的問題，range 可以解決數(shù)據(jù)遷移問題，那我們可以不可以兩者相結(jié)合呢?利用這兩者的特性呢?
我們考慮一下數(shù)據(jù)的擴(kuò)容代表著，路由 key(如 id)的值變大了，這個是一定的，那我們先保證數(shù)據(jù)變大的時候，首先用 range 方案讓數(shù)據(jù)落地到一個范圍里面。這樣以后 id 再變大，那以前的數(shù)據(jù)是不需要遷移的。
但又要考慮到數(shù)據(jù)均勻，那是不是可以在一定的范圍內(nèi)數(shù)據(jù)均勻的呢?因為我們每次的擴(kuò)容肯定會事先設(shè)計好這次擴(kuò)容的范圍大小，我們只要保證這次的范圍內(nèi)的數(shù)據(jù)均勻是不是就 ok 了。
方案設(shè)計
我們先定義一個 group 組概念，這組里面包含了一些分庫以及分表，如下圖：
上圖有幾個關(guān)鍵點(diǎn)：
- id=0～4000 萬肯定落到 group01 組中。
- group01 組有 3 個 DB，那一個 id 如何路由到哪個 DB?
- 根據(jù) hash 取模定位 DB，那模數(shù)為多少?模數(shù)要為所有此 group 組 DB 中的表數(shù)，上圖總表數(shù)為 10。為什么要去表的總數(shù)?而不是 DB 總數(shù) 3 呢?
- 如 id=12，id%10=2;那值為 2，落到哪個 DB 庫呢?這是設(shè)計是前期設(shè)定好的，那怎么設(shè)定的呢?
- 一旦設(shè)計定位哪個 DB 后，就需要確定落到 DB 中的哪張表呢?
核心主流程
按照上面的流程，我們就可以根據(jù)此規(guī)則，定位一個 id，我們看看有沒有避免熱點(diǎn)問題。
我們看一下，id 在【0，1000 萬】范圍內(nèi)的，根據(jù)上面的流程設(shè)計，1000 萬以內(nèi)的 id 都均勻的分配到 DB_0，DB_1，DB_2 三個數(shù)據(jù)庫中的 Table_0 表中，為什么可以均勻，因為我們用了 hash 的方案，對 10 進(jìn)行取模。
上面我們也提了疑問，為什么對表的總數(shù) 10 取模，而不是 DB 的總數(shù) 3 進(jìn)行取模?我們看一下為什么 DB_0 是 4 張表，其他兩個 DB_1 是 3 張表?
在我們安排服務(wù)器時，有些服務(wù)器的性能高，存儲高，就可以安排多存放些數(shù)據(jù)，有些性能低的就少放點(diǎn)數(shù)據(jù)。
如果我們?nèi)∧Ｊ前凑?DB 總數(shù) 3，進(jìn)行取模，那就代表著【0，4000 萬】的數(shù)據(jù)是平均分配到 3 個 DB 中的，那就不能夠?qū)崿F(xiàn)按照服務(wù)器能力適當(dāng)分配了。
按照 Table 總數(shù) 10 就能夠達(dá)到，看如何達(dá)到。
上圖中我們對 10 進(jìn)行取模，如果值為【0，1，2，3】就路由到 DB_0，【4，5，6】路由到 DB_1，【7，8，9】路由到 DB_2。
現(xiàn)在小伙伴們有沒有理解，這樣的設(shè)計就可以把多一點(diǎn)的數(shù)據(jù)放到 DB_0 中，其他 2 個 DB 數(shù)據(jù)量就可以少一點(diǎn)。
DB_0 承擔(dān)了 4/10 的數(shù)據(jù)量，DB_1 承擔(dān)了 3/10 的數(shù)據(jù)量，DB_2 也承擔(dān)了 3/10 的數(shù)據(jù)量。整個 Group01 承擔(dān)了【0，4000 萬】的數(shù)據(jù)量。
注意：小伙伴千萬不要被 DB_1 或 DB_2 中 table 的范圍也是 0～4000 萬疑惑了，這個是范圍區(qū)間，也就是id在哪些范圍內(nèi)，落地到哪個表而已。
上面一大段的介紹，就解決了熱點(diǎn)的問題，以及可以按照服務(wù)器指標(biāo)，設(shè)計數(shù)據(jù)量的分配。
如何擴(kuò)容
其實上面設(shè)計思路理解了，擴(kuò)容就已經(jīng)出來了;那就是擴(kuò)容的時候再設(shè)計一個 group02 組，定義好此 group 的數(shù)據(jù)范圍就 ok 了。
因為是新增的一個 group01 組，所以就沒有什么數(shù)據(jù)遷移概念，完全是新增的 group 組，而且這個 group 組照樣就防止了熱點(diǎn)。
也就是【4000 萬，5500 萬】的數(shù)據(jù)，都均勻分配到三個 DB 的 table_0 表中，【5500 萬～7000 萬】數(shù)據(jù)均勻分配到 table_1 表中。
系統(tǒng)設(shè)計
思路確定了，設(shè)計是比較簡單的，就 3 張表，把 group，DB，table 之間建立好關(guān)聯(lián)關(guān)系就行了。
group 和 DB 的關(guān)系
table 和 db 的關(guān)系
上面的表關(guān)聯(lián)其實是比較簡單的，只要原理思路理順了，就 ok 了。小伙伴們在開發(fā)的時候不要每次都去查詢?nèi)龔堦P(guān)聯(lián)表，可以保存到緩存中(本地 JVM 緩存)，這樣不會影響性能。
一旦需要擴(kuò)容，小伙伴是不是要增加一下 group02 關(guān)聯(lián)關(guān)系，那應(yīng)用服務(wù)需要重新啟動嗎?
簡單點(diǎn)的話，就凌晨配置，重啟應(yīng)用服務(wù)就行了。但如果是大型公司，是不允許的，因為凌晨也有訂單的。那怎么辦呢?本地 JVM 緩存怎么更新呢?
其實方案也很多，可以使用用 Zookeeper，也可以使用分布式配置，這里是比較推薦使用分布式配置中心的，可以將這些數(shù)據(jù)配置到分布式配置中心去。
到此為止，整體的方案介紹結(jié)束，希望對小伙伴們有所幫助。謝謝!!!
PS：這邊隱含了一個關(guān)鍵點(diǎn)，那就是路由 key(如：id)的值是非常關(guān)鍵的，要求一定是有序的，自增的，這個就涉及到分布式唯一 id 的方案。
作者：老顧聊技術(shù)
編輯：陶家龍
征稿：有投稿、尋求報道意向技術(shù)人請?zhí)砑有【幬⑿?gordonlonglong
分享文章：數(shù)據(jù)庫|“分庫分表”，還能這么玩！
網(wǎng)頁地址：http://www.5511xx.com/article/ccssseg.html
