當前位置:網站首頁>數據庫如何做到永不遷移數據和避免熱點

數據庫如何做到永不遷移數據和避免熱點

2022-01-27 06:02:25 程序員社區

數據庫如何做到永不遷移數據和避免熱點 , 你了解嗎? 本文就為大家帶來了一篇 數據庫如何做到永不遷移數據和避免熱點 一起看看吧!
另外小編還收集了很多不錯的編程資源,希望對你有幫助:點擊查看
祝您生活愉快~

帶著思考去看內容,才能真正的成長。

一、前言

中大型項目中,一旦遇到數據量比較大,小夥伴應該都知道就應該對數據進行拆分了。有垂直和水平兩種

垂直拆分比較簡單,也就是本來一個數據庫,數據量大之後,從業務角度進行拆分多個庫。如下圖,獨立的拆分出訂單庫和用戶庫。

水平拆分的概念,是同一個業務數據量大之後,進行水平拆分。

數據庫如何做到永不遷移數據和避免熱點插圖
數據庫如何做到永不遷移數據和避免熱點插圖1

上圖中訂單數據達到了4000萬,我們也知道mysql單錶存儲量推薦是百萬級,如果不進行處理,mysql單錶數據太大,會導致性能變慢。使用方案可以參考數據進行水平拆分。把4000萬數據拆分4張錶或者更多。當然也可以分庫,再分錶;把壓力從數據庫層級分開。

二、分庫分錶方案

分庫分錶方案中有常用的方案,hash取模和range範圍方案;分庫分錶方案最主要就是路由算法,把路由的key按照指定的算法進行路由存放。下邊來介紹一下兩個方案的特點。

1、hash取模方案

數據庫如何做到永不遷移數據和避免熱點插圖2

在我們設計系統之前,可以先預估一下大概這幾年的訂單量,如:4000萬。每張錶我們可以容納1000萬,也我們可以設計4張錶進行存儲。

那具體如何路由存儲的呢?hash的方案就是對指定的路由key(如:id)對分錶總數進行取模,上圖中,id=12的訂單,對4進行取模,也就是會得到0,那此訂單會放到0錶中。id=13的訂單,取模得到為1,就會放到1錶中。為什麼對4取模,是因為分錶總數是4。

優點:

訂單數據可以均勻的放到那4張錶中,這樣此訂單進行操作時,就不會有熱點問題。

熱點的含義:熱點的意思就是對訂單進行操作集中到1個錶中,其他錶的操作很少。

訂單有個特點就是時間屬性,一般用戶操作訂單數據,都會集中到這段時間產生的訂單。如果這段時間產生的訂單 都在同一張訂單錶中,那就會形成熱點,那張錶的壓力會比較大。

缺點:

將來的數據遷移和擴容,會很難。

如:業務發展很好,訂單量很大,超出了4000萬的量,那我們就需要增加分錶數。如果我們增加4個錶

數據庫如何做到永不遷移數據和避免熱點插圖3

一旦我們增加了分錶的總數,取模的基數就會變成8,以前id=12的訂單按照此方案就會到4錶中查詢,但之前的此訂單時在0錶的,這樣就導致了數據查不到。就是因為取模的基數產生了變化。

遇到這個情况,我們小夥伴想到的方案就是做數據遷移,把之前的4000萬數據,重新做一個hash方案,放到新的規劃分錶中。也就是我們要做數據遷移。這個是很痛苦的事情。有些小公司可以接受晚上停機遷移,但大公司是不允許停機做數據遷移的。

當然做數據遷移可以結合自己的公司的業務,做一個工具進行,不過也帶來了很多工作量,每次擴容都要做數據遷移

那有沒有不需要做數據遷移的方案呢,我們看下面的方案

2、range範圍方案

range方案也就是以範圍進行拆分數據。

數據庫如何做到永不遷移數據和避免熱點插圖4

range方案比較簡單,就是把一定範圍內的訂單,存放到一個錶中;如上圖id=12放到0錶中,id=1300萬的放到1錶中。設計這個方案時就是前期把錶的範圍設計好。通過id進行路由存放。

優點

我們小夥伴們想一下,此方案是不是有利於將來的擴容,不需要做數據遷移。即時再增加4張錶,之前的4張錶的範圍不需要改變,id=12的還是在0錶,id=1300萬的還是在1錶,新增的4張錶他們的範圍肯定是 大於 4000萬之後的範圍劃分的。

缺點

有熱點問題,我們想一下,因為id的值會一直遞增變大,那這段時間的訂單是不是會一直在某一張錶中,如id=1000萬 ~ id=2000萬之間,這段時間產生的訂單是不是都會集中到此張錶中,這個就導致1錶過熱,壓力過大,而其他的錶沒有什麼壓力。

3、總結:

hash取模方案:沒有熱點問題,但擴容遷移數據痛苦

range方案:不需要遷移數據,但有熱點問題。

那有什麼方案可以做到兩者的優點結合呢?,即不需要遷移數據,又能解决數據熱點的問題呢?

其實還有一個現實需求,能否根據服務器的性能以及存儲高低,適當均勻調整存儲呢?

數據庫如何做到永不遷移數據和避免熱點插圖5

三、方案思路

hash是可以解决數據均勻的問題,range可以解决數據遷移問題,那我們可以不可以兩者相結合呢?利用這兩者的特性呢?

我們考慮一下數據的擴容代錶著,路由key(如id)的值變大了,這個是一定的,那我們先保證數據變大的時候,首先用range方案讓數據落地到一個範圍裏面。這樣以後id再變大,那以前的數據是不需要遷移的

但又要考慮到數據均勻,那是不是可以在一定的範圍內數據均勻的呢?因為我們每次的擴容肯定會事先設計好這次擴容的範圍大小,我們只要保證這次的範圍內的數據均勻是不是就ok了。

數據庫如何做到永不遷移數據和避免熱點插圖6

四、方案設計

我們先定義一個group組概念,這組裏面包含了一些分庫以及分錶,如下圖

數據庫如何做到永不遷移數據和避免熱點插圖7

上圖有幾個關鍵點:

1)id=0~4000萬肯定落到group01組中

2)group01組有3個DB,那一個id如何路由到哪個DB?

3)根據hash取模定比特DB,那模數為多少?模數要為所有此group組DB中的錶數,上圖總錶數為10。為什麼要去錶的總數?而不是DB總數3呢?

4)如id=12,id%10=2;那值為2,落到哪個DB庫呢?這是設計是前期設定好的,那怎麼設定的呢?

5)一旦設計定比特哪個DB後,就需要確定落到DB中的哪張錶呢?

數據庫如何做到永不遷移數據和避免熱點插圖8

五、核心主流程

數據庫如何做到永不遷移數據和避免熱點插圖9

按照上面的流程,我們就可以根據此規則,定比特一個id,我們看看有沒有避免熱點問題。

我們看一下,id在【0,1000萬】範圍內的,根據上面的流程設計,1000萬以內的id都均勻的分配到DB_0,DB_1,DB_2三個數據庫中的Table_0錶中,為什麼可以均勻,因為我們用了hash的方案,對10進行取模。

上面我們也提了疑問,為什麼對錶的總數10取模,而不是DB的總數3進行取模?我們看一下為什麼DB_0是4張錶,其他兩個DB_1是3張錶?

在我們安排服務器時,有些服務器的性能高,存儲高,就可以安排多存放些數據,有些性能低的就少放點數據。如果我們取模是按照DB總數3,進行取模,那就代錶著【0,4000萬】的數據是平均分配到3個DB中的,那就不能够實現按照服務器能力適當分配了。

按照Table總數10就能够達到,看如何達到

數據庫如何做到永不遷移數據和避免熱點插圖10

上圖中我們對10進行取模,如果值為【0,1,2,3】就路由到DB_0,【4,5,6】路由到DB_1,【7,8,9】路由到DB_2。現在小夥伴們有沒有理解,這樣的設計就可以把多一點的數據放到DB_0中,其他2個DB數據量就可以少一點。DB_0承擔了4/10的數據量,DB_1承擔了3/10的數據量,DB_2也承擔了3/10的數據量。整個Group01承擔了【0,4000萬】的數據量。

注意:小夥伴千萬不要被DB_1或DB_2中table的範圍也是0~4000萬疑惑了,這個是範圍區間,也就是id在哪些範圍內,落地到哪個錶而已。

上面一大段的介紹,就解决了熱點的問題,以及可以按照服務器指標,設計數據量的分配。

數據庫如何做到永不遷移數據和避免熱點插圖11

六、如何擴容

其實上面設計思路理解了,擴容就已經出來了;那就是擴容的時候再設計一個group02組,定義好此group的數據範圍就ok了。

數據庫如何做到永不遷移數據和避免熱點插圖12

因為是新增的一個group01組,所以就沒有什麼數據遷移概念,完全是新增的group組,而且這個group組照樣就防止了熱點,也就是【4000萬,5500萬】的數據,都均勻分配到三個DB的table_0錶中,【5500萬~7000萬】數據均勻分配到table_1錶中。

七、系統設計

數據庫如何做到永不遷移數據和避免熱點插圖13

思路確定了,設計是比較簡單的,就3張錶,把group,DB,table之間建立好關聯關系就行了。

數據庫如何做到永不遷移數據和避免熱點插圖14

group和DB的關系

數據庫如何做到永不遷移數據和避免熱點插圖15

table和db的關系

上面的錶關聯其實是比較簡單的,只要原理思路理順了,就ok了。小夥伴們在開發的時候不要每次都去查詢三張關聯錶,可以保存到緩存中(本地jvm緩存),這樣不會影響性能。

數據庫如何做到永不遷移數據和避免熱點插圖16

一旦需要擴容,小夥伴是不是要增加一下group02關聯關系,那應用服務需要重新啟動嗎?

簡單點的話,就淩晨配置,重啟應用服務就行了。但如果是大型公司,是不允許的,因為淩晨也有訂單的。那怎麼辦呢?本地jvm緩存怎麼更新呢?

其實方案也很多,可以使用用zookeeper,也可以使用分布式配置,這裏是比較推薦使用分布式配置中心的,可以將這些數據配置到分布式配置中心去

到此為止,整體的方案介紹結束,希望對小夥伴們有所幫助。謝謝!!!

這邊隱含了一個關鍵點,那就是路由key(如:id)的值是非常關鍵的,要求一定是有序的,自增的,這個就涉及到分布式唯一id的方案。


自己的小結:常用的分庫分錶方案主要有兩種。hash取模以及range範圍。前者不會有熱點問題,但是在遷移和擴容時會很繁瑣。後者擴容不需要做數據遷移,但是會導致熱數據的問題。本文的最優方案結合兩者的優點,通過range確定group組、hash定比特DB以及range確定具體table即四步操作來查詢一個id的內容。雖然比前兩種方法多了2次查詢(或使用一個三錶聯查)繁瑣,但是通過緩存或分布式配置對性能影響不大。

有人提出使用一致性hash也可以實現方法三的功能。通過我們對一致性hash的學習,得出結論:一致性hash只能减少數據遷移的數量,但是不能從根本上避免永不數據遷移。

關於一致性hash可參考:一致性hash

如有不對的地方,請指正。謝謝


本文地址:www.toutiao.com/i6677459303055491597

版權聲明
本文為[程序員社區]所創,轉載請帶上原文鏈接,感謝
https://cht.chowdera.com/2022/01/202201270602244010.html

隨機推薦