這四種情況下，才是考慮分庫分表的時(shí)候！

來源：https://juejin.im/post/6844903992909103117

數(shù)據(jù)庫瓶頸

IO瓶頸

• 第一種：磁盤讀IO瓶頸，熱點(diǎn)數(shù)據(jù)太多，數(shù)據(jù)庫緩存放不下，每次查詢會(huì)產(chǎn)生大量的IO，降低查詢速度->分庫和垂直分表
• 第二種：網(wǎng)絡(luò)IO瓶頸，請求的數(shù)據(jù)太多，網(wǎng)絡(luò)帶寬不夠 ->分庫

CPU瓶頸

• 第一種：SQl問題：如SQL中包含join,group by, order by，非索引字段條件查詢等，增加CPU運(yùn)算的操作->SQL優(yōu)化，建立合適的索引，在業(yè)務(wù)Service層進(jìn)行業(yè)務(wù)計(jì)算。
• 第二種：單表數(shù)據(jù)量太大，查詢時(shí)掃描的行太多，SQl效率低，增加CPU運(yùn)算的操作。->水平分表。

水平分庫

• 1、概念：以字段為依據(jù)，按照一定策略（hash、range等），將一個(gè)庫中的數(shù)據(jù)拆分到多個(gè)庫中。
• 2、結(jié)果：
• 每個(gè)庫的結(jié)構(gòu)都一樣
• 每個(gè)庫中的數(shù)據(jù)不一樣，沒有交集
• 所有庫的數(shù)據(jù)并集是全量數(shù)據(jù)
• 3、場景：系統(tǒng)絕對并發(fā)量上來了，分表難以根本上解決問題，并且還沒有明顯的業(yè)務(wù)歸屬來垂直分庫的情況下。
• 4、分析：庫多了，io和cpu的壓力自然可以成倍緩解

水平分表

• 1、概念：以字段為依據(jù)，按照一定策略（hash、range等），講一個(gè)表中的數(shù)據(jù)拆分到多個(gè)表中。
• 2、結(jié)果：
• 每個(gè)表的結(jié)構(gòu)都一樣
• 每個(gè)表的數(shù)據(jù)不一樣，沒有交集，所有表的并集是全量數(shù)據(jù)。
• 3、場景：系統(tǒng)絕對并發(fā)量沒有上來，只是單表的數(shù)據(jù)量太多，影響了SQL效率，加重了CPU負(fù)擔(dān)，以至于成為瓶頸，可以考慮水平分表。
• 4、分析：單表的數(shù)據(jù)量少了，單次執(zhí)行SQL執(zhí)行效率高了，自然減輕了CPU的負(fù)擔(dān)。

垂直分庫

• 1、概念：以表為依據(jù)，按照業(yè)務(wù)歸屬不同，將不同的表拆分到不同的庫中。
• 2、結(jié)果：
• 每個(gè)庫的結(jié)構(gòu)都不一樣
• 每個(gè)庫的數(shù)據(jù)也不一樣，沒有交集
• 所有庫的并集是全量數(shù)據(jù)
• 3、場景：系統(tǒng)絕對并發(fā)量上來了，并且可以抽象出單獨(dú)的業(yè)務(wù)模塊的情況下。
• 4、分析：到這一步，基本上就可以服務(wù)化了。例如：隨著業(yè)務(wù)的發(fā)展，一些公用的配置表、字典表等越來越多，這時(shí)可以將這些表拆到單獨(dú)的庫中，甚至可以服務(wù)化。再者，隨著業(yè)務(wù)的發(fā)展孵化出了一套業(yè)務(wù)模式，這時(shí)可以將相關(guān)的表拆到單獨(dú)的庫中，甚至可以服務(wù)化。

垂直分表

• 1、概念：以字段為依據(jù)，按照字段的活躍性，將表中字段拆到不同的表中（主表和擴(kuò)展表）。
• 2、結(jié)果：
• 每個(gè)表的結(jié)構(gòu)不一樣。
• 每個(gè)表的數(shù)據(jù)也不一樣，一般來說，每個(gè)表的字段至少有一列交集，一般是主鍵，用于關(guān)聯(lián)數(shù)據(jù)。
• 所有表的并集是全量數(shù)據(jù)。
• 3、場景：系統(tǒng)絕對并發(fā)量并沒有上來，表的記錄并不多，但是字段多，并且熱點(diǎn)數(shù)據(jù)和非熱點(diǎn)數(shù)據(jù)在一起，單行數(shù)據(jù)所需的存儲空間較大，以至于數(shù)據(jù)庫緩存的數(shù)據(jù)行減少，查詢時(shí)回去讀磁盤數(shù)據(jù)產(chǎn)生大量隨機(jī)讀IO，產(chǎn)生IO瓶頸。
• 4、分析：可以用列表頁和詳情頁來幫助理解。垂直分表的拆分原則是將熱點(diǎn)數(shù)據(jù)（可能經(jīng)常會(huì)查詢的數(shù)據(jù)）放在一起作為主表，非熱點(diǎn)數(shù)據(jù)放在一起作為擴(kuò)展表，這樣更多的熱點(diǎn)數(shù)據(jù)就能被緩存下來，進(jìn)而減少了隨機(jī)讀IO。拆了之后，要想獲取全部數(shù)據(jù)就需要關(guān)聯(lián)兩個(gè)表來取數(shù)據(jù)。

分庫分表工具

• sharding-jdbc（當(dāng)當(dāng)）
• TSharding（蘑菇街）
• Atlas（奇虎360）
• Cobar（阿里巴巴）
• MyCAT（基于Cobar）
• Oceanus（58同城）
• Vitess（谷歌） 各種工具的利弊自查

分庫分表帶來的問題

需要先在不同的分片節(jié)點(diǎn)中將數(shù)據(jù)進(jìn)行排序并返回，然后將不同分片返回的結(jié)果集進(jìn)行匯總和再次排序，最終返回給用戶 如下圖：上圖只是取第一頁的數(shù)據(jù)，對性能影響還不是很大。但是如果取得頁數(shù)很大，情況就變得復(fù)雜的多，因?yàn)楦鞣制?jié)點(diǎn)中的數(shù)據(jù)可能是隨機(jī)的，為了排序的準(zhǔn)確性，需要將所有節(jié)點(diǎn)的前N頁數(shù)據(jù)都排序好做合并，最后再進(jìn)行整體排序，這樣的操作很耗費(fèi)CPU和內(nèi)存資源，所以頁數(shù)越大，系統(tǒng)性能就會(huì)越差。

????CREATE?TABLE?`sequence`?(??
??????`id`?bigint(20)?unsigned?NOT?NULL?auto_increment,??
??????`stub`?char(1)?NOT?NULL?default?'',??
??????PRIMARY?KEY??(`id`),??
??????UNIQUE?KEY?`stub`?(`stub`)??
????)?ENGINE=MyISAM;

????REPLACE?INTO?sequence?(stub)?VALUES?('a');??
????SELECT?1561439;??

Snowflake分布式自增ID算法

Twitter的snowfalke算法解決了分布式系統(tǒng)生成全局ID的需求，生成64位Long型數(shù)字，組成部分：

• 第一位未使用
• 接下來的41位是毫秒級時(shí)間，41位的長度可以表示69年的時(shí)間
• 5位datacenterId,5位workerId。10位長度最多支持部署1024個(gè)節(jié)點(diǎn)
• 最后12位是毫秒內(nèi)計(jì)數(shù)，12位的計(jì)數(shù)順序號支持每個(gè)節(jié)點(diǎn)每毫秒產(chǎn)生4096個(gè)ID序列。

數(shù)據(jù)遷移、擴(kuò)容問題

什么時(shí)候考慮分庫分表

• 能不分就不分

• 數(shù)據(jù)量過大，正常運(yùn)維影響業(yè)務(wù)訪問

• 隨著業(yè)務(wù)發(fā)展，需要對某些字段垂直拆分

• 數(shù)據(jù)量快速增長

---END---
文末福利