【SQLServer】如何設(shè)計(jì)日增幾十萬(wàn)數(shù)據(jù)量的業(yè)務(wù)分庫(kù)分表方案
當(dāng)前位置:點(diǎn)晴教程→知識(shí)管理交流
→『 技術(shù)文檔交流 』
隨著公司的業(yè)務(wù)發(fā)展不斷的壯大,像一些核心的業(yè)務(wù)(如訂單)數(shù)據(jù)量會(huì)越來(lái)越大,此時(shí)就需要考慮分庫(kù)分表方案來(lái)應(yīng)對(duì)業(yè)務(wù)的發(fā)展。今天就來(lái)聊聊分庫(kù)分表的一些設(shè)計(jì)方案。 1、冷熱數(shù)據(jù)分離方案 在我們業(yè)務(wù)中有些數(shù)據(jù)只是最近一段時(shí)間使用比較頻繁,過(guò)著這段時(shí)間就基本上不用了,如龍蝦之前負(fù)責(zé)的物流系統(tǒng)中的物流軌跡數(shù)據(jù),一條物流單號(hào)對(duì)應(yīng)著若干條物流軌跡數(shù)據(jù),如下所示的物流軌跡: 一個(gè)物流單號(hào)(如YT20241234569)對(duì)應(yīng)的軌跡有6條數(shù)據(jù)數(shù)據(jù)了,假設(shè)一天的訂單量有2萬(wàn)單,此時(shí)至少有12萬(wàn)條物流軌跡產(chǎn)生, 日復(fù)一日的數(shù)據(jù)量積累,那么物流軌跡表的數(shù)據(jù)也是非常的龐大的。 從業(yè)務(wù)角度分析,按照用戶(hù)的習(xí)慣來(lái)講,某個(gè)訂單待收貨與交易成功之間的這段時(shí)間中我們是比較關(guān)心物流的軌跡的,一旦收到貨之后基本很少再去看這單的物流軌跡信息,所以針對(duì)這種數(shù)據(jù)量大(物流軌跡數(shù)據(jù))、只在某段時(shí)間內(nèi)頻繁關(guān)心的數(shù)據(jù),我們可以使用冷熱數(shù)據(jù)隔離的方案來(lái)解決數(shù)據(jù)量大的問(wèn)題。下圖使用物流軌跡數(shù)據(jù)冷熱分離方案為案例分析: (1)物流單號(hào)訂閱物流系統(tǒng),物流系統(tǒng)將物流單號(hào)訂閱三方快遞,一旦訂閱成功之后,三方快遞收到物流軌跡變動(dòng)就會(huì)推送給物流系統(tǒng),然后物流系統(tǒng)將數(shù)據(jù)存放到熱表中; (2)用戶(hù)查詢(xún)的時(shí)候優(yōu)先從熱表先查詢(xún)數(shù)據(jù),如果熱表有物流軌跡的數(shù)據(jù)就直接返回?cái)?shù)據(jù)給用戶(hù);如果熱表中不存在物流數(shù)據(jù),那么再去冷表中查詢(xún)數(shù)據(jù),將冷表的查詢(xún)結(jié)果給用戶(hù); (3)每天夜里(如凌晨?jī)牲c(diǎn))采用定時(shí)任務(wù)將一個(gè)月之前的數(shù)據(jù)都遷移到冷表中,這樣可以保持熱表中都是最近的數(shù)據(jù)。 至此就完成了一套使用通過(guò)冷熱分離的方案實(shí)現(xiàn)對(duì)日增幾十萬(wàn)條業(yè)務(wù)數(shù)據(jù)的處理。 2、分庫(kù)分表方案 公司現(xiàn)有的業(yè)務(wù)體量非常大的,在讀寫(xiě)分離、主從架構(gòu)都無(wú)法滿(mǎn)足現(xiàn)有的業(yè)務(wù)的時(shí)候,我們就可以考慮分庫(kù)分表,為什么不優(yōu)先考慮分庫(kù)分表方案呢?因?yàn)闃I(yè)務(wù)數(shù)據(jù)越分散,開(kāi)發(fā)和維護(hù)成本就越高,并且系統(tǒng)的不穩(wěn)定性又多一些威脅因素。 分庫(kù)分表是應(yīng)對(duì)業(yè)務(wù)數(shù)據(jù)量大、高并發(fā)的重要手段之一,我們要搞清楚何時(shí)分庫(kù),何時(shí)分表,何時(shí)既分庫(kù)也分表呢? (a)分庫(kù)的場(chǎng)景:在高并發(fā)下,數(shù)據(jù)庫(kù)的連接不夠用的時(shí)候,此時(shí)可以通過(guò)增加數(shù)據(jù)庫(kù)的實(shí)例來(lái)增加數(shù)據(jù)庫(kù)的連接數(shù)。如下所示的分庫(kù)方式: (b)分表的場(chǎng)景:如果單表的數(shù)據(jù)量很龐大,此時(shí)數(shù)據(jù)庫(kù)的連接是夠用的,但是存儲(chǔ)和查詢(xún)的性能已經(jīng)成為業(yè)務(wù)瓶頸,那么就考慮分表。如下圖所示的分片: (c)既分庫(kù)也分表的場(chǎng)景:數(shù)據(jù)庫(kù)的連接不夠,并且表數(shù)據(jù)量很龐大此時(shí)一般需要考慮既要分庫(kù)也要分表。但是具體分多少庫(kù)分多少表實(shí)際的業(yè)務(wù)預(yù)估數(shù)據(jù)量來(lái)做決定,如下圖所示的既分庫(kù)也分表的圖: 在確定了需要分庫(kù)分表后就需要考慮將數(shù)據(jù)分到哪個(gè)庫(kù)或者哪張表中,下面介紹4種主流的切分: (1)Range法 此算法是按照某個(gè)字段(如訂單id、用戶(hù)id)的數(shù)據(jù)區(qū)間來(lái)進(jìn)行切分的,可以將數(shù)據(jù)切分到同一個(gè)數(shù)據(jù)庫(kù)的不同表中,如下所示: 也可以將數(shù)據(jù)切分到不同庫(kù)的不同表中,如下所示: Range算法對(duì)于需要擴(kuò)容來(lái)說(shuō)是非常的友好的,因?yàn)橹恍枰砑右粡垟?shù)據(jù)表,通過(guò)算法就可以自動(dòng)實(shí)現(xiàn)擴(kuò)容機(jī)制。同時(shí)Range算法也存在寫(xiě)偏移和熱點(diǎn)數(shù)據(jù)問(wèn)題。 (2)hash分片算法 該方案是通過(guò)對(duì)分表鍵key進(jìn)行某種運(yùn)算(如取模運(yùn)算),然后通過(guò)運(yùn)算結(jié)果來(lái)決定路由的庫(kù)和表,如下圖所示: hash分片方案可以使得數(shù)據(jù)分片比較均勻,大大降低數(shù)據(jù)傾斜和熱點(diǎn)數(shù)據(jù)的問(wèn)題; hash分片方案的缺點(diǎn)也很明顯,如后期擴(kuò)容存在一定的難度,需要遷移數(shù)據(jù);數(shù)據(jù)被切分到不同的庫(kù)和表中,存在查詢(xún)和分頁(yè)等問(wèn)題; (3)查表映射法 此方案的實(shí)現(xiàn)原理是將決定某個(gè)sharding key落在哪個(gè)分片上靠人為的預(yù)先制定的策略(策略記錄在數(shù)據(jù)表中)來(lái)分配,如下所示的分配流程: 查表映射法可以靈活設(shè)置路由規(guī)則,但是要求映射表本身的數(shù)據(jù)不能太多,否則映射表反而成為性能瓶頸了。 查表映射法相對(duì)其他兩種分片算法來(lái)說(shuō),它需要二次查詢(xún)、實(shí)現(xiàn)上也更加的復(fù)雜一些。 (4)一致性hash 一致性hash可以按照普通的hash算法對(duì)key哈希到一個(gè)圓環(huán)空間上,形成一個(gè)順時(shí)針的首位閉合的環(huán)形,如下圖所示: 此時(shí)key1順時(shí)針?lè)旁诠?jié)點(diǎn)A上,同理key放在B節(jié)點(diǎn)上,如果A、B、C節(jié)點(diǎn)假設(shè)分布不均勻,我們可以使用虛擬節(jié)點(diǎn)的方案來(lái)處理,之前龍蝦也介紹過(guò)一致性hash,有興趣的朋友可以在看下: 3、分庫(kù)分表帶來(lái)的問(wèn)題 (1)分布式id 單庫(kù)單表的時(shí)代,我們可以直接使用表自增主鍵保證全局唯一,分庫(kù)分表后,需要自己維護(hù)全局唯一的ID。生成全局唯一id的方案如下整理: (2)分布式事務(wù) 分庫(kù)分表之后可能就需要引入分布式事務(wù)的問(wèn)題,解決方案如下整理: (3)分頁(yè)查詢(xún)問(wèn)題 單庫(kù)單表的時(shí)候我們可以使用數(shù)據(jù)的limit來(lái)進(jìn)行分頁(yè)查詢(xún),但是分庫(kù)分表后就出現(xiàn)分頁(yè)查詢(xún)的問(wèn)題了,常見(jiàn)的處理方案如下: (a)使用Elasticsearch; (b)特定的條件先分頁(yè)查詢(xún);按照某個(gè)字段先分頁(yè)查詢(xún)數(shù)據(jù),查詢(xún)好之后再去查詢(xún)組裝其他的數(shù)據(jù)。 該文章在 2024/7/22 9:30:56 編輯過(guò) |
關(guān)鍵字查詢(xún)
相關(guān)文章
正在查詢(xún)... |