@TOC

1.概述

1.1.分庫(kù)分表是什么

小明是一家初創(chuàng)電商平臺(tái)的開(kāi)發(fā)人員，他負(fù)責(zé)賣(mài)家模塊的功能開(kāi)發(fā)躲撰，其中涉及了店鋪恩伺、商品的相關(guān)業(yè)務(wù)，設(shè)計(jì)如下數(shù)據(jù)庫(kù) ：

在這里插入圖片描述

通過(guò)以下SQL能夠獲取到商品相關(guān)的店鋪信息毛雇、地理區(qū)域信息 ：

SELECT p.*,r.[地理區(qū)域名稱],s.[店鋪名稱],s.[信譽(yù)] FROM [商品信息] p
LEFT JOIN [地理區(qū)域] r ON p.[產(chǎn)地] = r.[地理區(qū)域編碼] LEFT JOIN [店鋪信息] s ON p.id = s.[所屬店鋪]
WHERE p.id = ?

形成類(lèi)似以下列表展示 ：

在這里插入圖片描述

在這里插入圖片描述

1.2.分庫(kù)分表的方式

分庫(kù)分表包括分庫(kù)和分表兩個(gè)部分，在生產(chǎn)中通常包括 ：垂直分庫(kù)骨田、水平分庫(kù)耿导、垂直分表、水平分表四種方式态贤。

1.2.1.垂直分表

下邊通過(guò)一個(gè)商品查詢的案例來(lái)垂直分表 ：
通常在商品列表中是不是顯示商品詳情信息的舱呻，如下圖 ：

在這里插入圖片描述

用戶在瀏覽商品列表時(shí)，只有對(duì)某商品感興趣時(shí)才會(huì)查看商品的詳細(xì)描述悠汽。因此箱吕，商品信息中商品描述字段訪問(wèn)頻次較低，且該字段存儲(chǔ)占用空間較大柿冲，訪問(wèn)單個(gè)數(shù)據(jù)IO時(shí)間較長(zhǎng)茬高；商品信息中商品名稱、商品圖片假抄、商品價(jià)格等其他字段數(shù)據(jù)訪問(wèn)頻次較高雅采。
由于這兩種數(shù)據(jù)的特性不一樣，因此他考慮將商品信息表拆分如下 ：
將訪問(wèn)頻次低的商品描述信息單獨(dú)存放在一張表中慨亲，訪問(wèn)頻次較高的商品基本信息單獨(dú)放在一張表中婚瓜。

在這里插入圖片描述

SELECT p.*,r.[地理區(qū)域名稱],s.[店鋪名稱],s.[信譽(yù)] FROM [商品信息] p
LEFT JOIN [地理區(qū)域] r ON p.[產(chǎn)地] = r.[地理區(qū)域編碼] LEFT JOIN [店鋪信息] s ON p.id = s.[所屬店鋪] WHERE...ORDER BY...LIMIT...

需要獲取商品描述時(shí)，再通過(guò)以下sql獲取 ：

SELECT *
FROM [商品描述] WHERE [商品ID] = ?

小明進(jìn)行的這一步優(yōu)化刑棵，就叫垂直分表巴刻。
垂直分表定義 ：將一個(gè)表按照字段分成多表，每個(gè)表存儲(chǔ)其中一部分字段蛉签。
它帶來(lái)的提升是 ：
1.為了避免IO爭(zhēng)搶并減少鎖表的幾率胡陪，查看詳情的用戶與商品信息瀏覽互不影響。
2.充分發(fā)揮熱門(mén)數(shù)據(jù)的操作效率碍舍，商品信息的操作的高效率不會(huì)被商品描述的低效率所拖累柠座。
注意 ：
為什么大字段IO效率低 ：
第一是由于數(shù)據(jù)量本身大，需要更長(zhǎng)的讀取時(shí)間片橡；
第二是跨頁(yè)妈经，頁(yè)是數(shù)據(jù)庫(kù)存儲(chǔ)單位，很多查找及定位操作都是以頁(yè)為單位，單頁(yè)內(nèi)的數(shù)據(jù)行越多數(shù)據(jù)庫(kù)整體性能越好吹泡，而大字段占用空間大骤星，單頁(yè)內(nèi)存儲(chǔ)行數(shù)少，因此IO效率較低爆哑。
第三洞难，數(shù)據(jù)庫(kù)以行為單位將數(shù)據(jù)加載到內(nèi)存中，這樣表中字段長(zhǎng)度較短且訪問(wèn)頻率較高揭朝，內(nèi)存能加載更多的數(shù)據(jù)队贱，命中率更高，減少來(lái)磁盤(pán)IO潭袱，從而提升來(lái)數(shù)據(jù)庫(kù)性能柱嫌。
一般來(lái)說(shuō)，某業(yè)務(wù)實(shí)體中的各個(gè)數(shù)據(jù)項(xiàng)的訪問(wèn)頻次是不一樣的敌卓，部分?jǐn)?shù)據(jù)項(xiàng)可能是占用存儲(chǔ)空間比較大的BLOB或是TEXT慎式。例如上例中的商品描述。所以趟径，當(dāng)表數(shù)據(jù)量很大時(shí)瘪吏，可以將表按字段切開(kāi)，將熱門(mén)字段蜗巧、冷門(mén)字段分開(kāi)放置在不同庫(kù)中掌眠，這些庫(kù)可以放在不同的存儲(chǔ)設(shè)置上，避免IO爭(zhēng)搶幕屹。垂直切分帶來(lái)的性能提升主要集中在熱門(mén)數(shù)據(jù)的操作效率上蓝丙，而且磁盤(pán)爭(zhēng)用情況減少。
通常我們按以下原則進(jìn)行垂直拆分 ：
1望拖、把不常用的字段單獨(dú)放在一張表渺尘；
2、把text说敏，blob等大字段拆分出來(lái)放在附表中鸥跟；
3、經(jīng)常組合查詢的列放在一張表中盔沫；

1.2.2.垂直分庫(kù)

通過(guò)垂直分表能得到來(lái)一定程度的提升医咨，但是還沒(méi)有達(dá)到要求，并且磁盤(pán)空間也快不夠來(lái)架诞，因?yàn)閿?shù)據(jù)還是始終限制在一臺(tái)服務(wù)器拟淮，庫(kù)內(nèi)垂直分表只解決來(lái)單一表數(shù)據(jù)量過(guò)大的問(wèn)題，但沒(méi)有將表分布到不同的服務(wù)器上谴忧，因此每個(gè)表還是競(jìng)爭(zhēng)同一個(gè)物理機(jī)的CPU很泊、內(nèi)存角虫、網(wǎng)絡(luò)IO
、磁盤(pán)撑蚌。
經(jīng)過(guò)思考上遥，他把原來(lái)的SELLER_DB（賣(mài)家?guī)欤┎迹譃閬?lái)PRODUCT_DB (商品庫(kù))和STORE_DB（店鋪庫(kù)）争涌，并把這兩個(gè)庫(kù)分散到不同服務(wù)器，如下圖 ：

在這里插入圖片描述

• 解決業(yè)務(wù)層面的耦合稀并，業(yè)務(wù)清晰
• 能對(duì)不同業(yè)務(wù)的數(shù)據(jù)進(jìn)行分級(jí)管理、維護(hù)单默、監(jiān)控碘举、擴(kuò)展等
• 高并發(fā)場(chǎng)景下，垂直分庫(kù)一定程度的提升IO搁廓、數(shù)據(jù)庫(kù)連接數(shù)引颈、降低單機(jī)硬件資源的瓶頸
  垂直分庫(kù)通過(guò)將表按業(yè)務(wù)分類(lèi)，然后分庫(kù)在不同數(shù)據(jù)庫(kù)境蜕，并且可以將這些數(shù)據(jù)庫(kù)部署在不同服務(wù)器上蝙场，從而達(dá)到多個(gè)服務(wù)器共同分?jǐn)倝毫Φ男Ч且廊粵](méi)有解決單表數(shù)據(jù)量過(guò)大的問(wèn)題粱年。

1.2.3.水平分庫(kù)

經(jīng)過(guò)垂直分庫(kù)后售滤，數(shù)據(jù)庫(kù)性能問(wèn)題得到一定程度的解決，但是隨著業(yè)務(wù)量的增長(zhǎng)逼泣，PRODUCT_DB（商品庫(kù)）單庫(kù)存儲(chǔ)數(shù)據(jù)已經(jīng)超出預(yù)估趴泌。粗糧統(tǒng)計(jì)，目前有8W店鋪拉庶，每個(gè)店鋪平均150個(gè)不同規(guī)格的商品嗜憔，再算增長(zhǎng)，那商品數(shù)量的往1500w+上預(yù)估氏仗，并且PRODUCT_DB（商品庫(kù)）屬于訪問(wèn)非常頻繁的資源吉捶，單臺(tái)服務(wù)器已經(jīng)無(wú)法支撐夺鲜。此時(shí)該如何優(yōu)化？
再次分庫(kù)呐舔？但是從業(yè)務(wù)角度分析币励，目前情況已經(jīng)無(wú)法再次垂直分庫(kù)∩浩矗可以嘗試水平分庫(kù)食呻，將店鋪ID為單數(shù)的和店鋪ID為雙數(shù)的商品信息分別放在兩個(gè)庫(kù)中。

在這里插入圖片描述

• 解決來(lái)單庫(kù)大數(shù)據(jù)，高并發(fā)的性能瓶頸成艘。
• 提高來(lái)系統(tǒng)的穩(wěn)定性及可用性赏半。
  穩(wěn)定性體現(xiàn)在IO沖突減少，鎖定減少淆两，可用性指某個(gè)庫(kù)出問(wèn)題断箫，部分可用。
  當(dāng)一個(gè)應(yīng)用難以再細(xì)粒度的垂直切分秋冰，或切分后數(shù)據(jù)量行巨大仲义，存在單庫(kù)讀寫(xiě)、存儲(chǔ)性能瓶頸剑勾，這時(shí)候就需要進(jìn)行水平分庫(kù)了埃撵，經(jīng)過(guò)水平切分的優(yōu)化，往往能解決單庫(kù)存儲(chǔ)量及性能瓶頸虽另。但由于同一個(gè)表被分配在不同的數(shù)據(jù)庫(kù)暂刘，需要額外進(jìn)行數(shù)據(jù)操作的路由工作，因此大大提升了系統(tǒng)復(fù)雜度捂刺。

1.2.4.水平分表

按照水平分庫(kù)的思路對(duì)他把PRODUCT_DB_X（商品庫(kù)）內(nèi)的表也可以進(jìn)行水平拆分谣拣，其目的也是為解決單表數(shù)據(jù)量大的問(wèn)題募寨，如下圖 ：

在這里插入圖片描述

• 優(yōu)化單一表數(shù)據(jù)量過(guò)大而產(chǎn)生的性能問(wèn)題
• 避免IO爭(zhēng)搶并減少鎖表的幾率
  庫(kù)內(nèi)的水平分表自沧，解決來(lái)單一表數(shù)據(jù)量過(guò)大的問(wèn)題坟奥，分出來(lái)的小表中只包含一部分?jǐn)?shù)據(jù)，從而使得單個(gè)表的數(shù)據(jù)量變小拇厢，提高檢索性能爱谁。

1.2.5 小結(jié)

介紹來(lái)分庫(kù)分表的幾種方式，它們分別是垂直分表孝偎、垂直分庫(kù)访敌、水平分庫(kù)和水平分表 ：
垂直分表 ：可以把一個(gè)寬表的字段按訪問(wèn)頻次，是否是大字段的原則拆分為多個(gè)表衣盾，這樣既能使業(yè)務(wù)清晰寺旺，還能提升部分性能。拆分后势决，盡量從業(yè)務(wù)角度避免聯(lián)查阻塑，否則性能方面將得不償失。
垂直分庫(kù) ：可以把多個(gè)表按業(yè)務(wù)耦合松緊歸類(lèi)果复，分別存放在不同的庫(kù)陈莽，這些庫(kù)可以分布在不同服務(wù)器，從而使訪問(wèn)壓力被能服務(wù)器負(fù)載虽抄，大大提升性能走搁，同時(shí)能提高整體架構(gòu)的業(yè)務(wù)清晰度，不同的業(yè)務(wù)庫(kù)可根據(jù)自身情況定制優(yōu)化方案迈窟。但是它需要解決跨庫(kù)帶來(lái)的所有復(fù)雜問(wèn)題私植。
水平分庫(kù) ：可以把一個(gè)表的數(shù)據(jù)（按數(shù)據(jù)行）分到多個(gè)不同的庫(kù)，每個(gè)庫(kù)只有這個(gè)表的部分?jǐn)?shù)據(jù)菠隆，這些庫(kù)可以分布在不同服務(wù)器兵琳，從而使訪問(wèn)壓力被多服務(wù)器負(fù)載狂秘，大大提升性能。它不僅需要解決跨庫(kù)帶來(lái)的所有復(fù)雜問(wèn)題躯肌，還要解決數(shù)據(jù)路由的問(wèn)題（數(shù)據(jù)路由問(wèn)題后邊介紹）者春。
水平分表 ：可以把一個(gè)表的數(shù)據(jù)（按數(shù)據(jù)行）分到多個(gè)同一個(gè)數(shù)據(jù)庫(kù)的多張表中，每個(gè)表只有這個(gè)表的部分?jǐn)?shù)據(jù)清女，這樣做能小幅提升性能钱烟，它僅僅作為水平分庫(kù)的一個(gè)補(bǔ)充優(yōu)化。
一般來(lái)說(shuō)嫡丙，在系統(tǒng)設(shè)計(jì)階段就應(yīng)該根據(jù)業(yè)務(wù)耦合松緊來(lái)確定垂直分庫(kù)拴袭，垂直分表方案，在數(shù)據(jù)量及訪問(wèn)壓力不是特別大的情況曙博，首先考慮緩沖拥刻、讀寫(xiě)分離、索引技術(shù)等方案父泳。若數(shù)據(jù)量極大般哼，且持續(xù)增長(zhǎng)，再考慮水平分庫(kù)水平分表方案惠窄。

1.3.分庫(kù)分表帶來(lái)的問(wèn)題

分庫(kù)分表能有效的緩解來(lái)單機(jī)和單庫(kù)帶來(lái)的性能瓶頸和壓力蒸眠，突破網(wǎng)絡(luò)IO、硬件資源杆融、連接數(shù)的瓶頸楞卡，同時(shí)也帶來(lái)了一些問(wèn)題。

1.3.1.事務(wù)一致性問(wèn)題

由于分庫(kù)分表把數(shù)據(jù)分布在不同庫(kù)甚至不同服務(wù)器脾歇，不可避免會(huì)帶來(lái)分布式事務(wù)問(wèn)題蒋腮。

1.3.2.跨節(jié)點(diǎn)關(guān)聯(lián)查詢

在沒(méi)有分庫(kù)前，我們檢索商品時(shí)可以通過(guò)以下SQL對(duì)店鋪信息進(jìn)行關(guān)聯(lián)查詢 ：

SELECT p.*,r.[地理區(qū)域名稱],s.[店鋪名稱],s.[信譽(yù)] FROM [商品信息] p
LEFT JOIN [地理區(qū)域] r ON p.[產(chǎn)地] = r.[地理區(qū)域編碼] LEFT JOIN [店鋪信息] s ON p.id = s.[所屬店鋪] WHERE...ORDER BY...LIMIT...

但垂直分庫(kù)后【商品信息】和【店鋪信息】不在一個(gè)數(shù)據(jù)庫(kù)介劫，甚至不在一臺(tái)服務(wù)器徽惋，無(wú)法進(jìn)行關(guān)聯(lián)查詢。
可將原關(guān)聯(lián)查詢分為兩次查詢座韵，第一次查詢的結(jié)果集中找出關(guān)聯(lián)數(shù)據(jù)id险绘，然后根據(jù)id發(fā)起第二次請(qǐng)求得到關(guān)聯(lián)數(shù)據(jù)，最后將獲得到的數(shù)據(jù)進(jìn)行拼裝誉碴。

1.3.3.跨節(jié)點(diǎn)分頁(yè)宦棺、排序函數(shù)

跨節(jié)點(diǎn)多庫(kù)進(jìn)行查詢時(shí)，limit分頁(yè)黔帕、order by排序等問(wèn)題代咸，就變得比較復(fù)雜了。需要先在不同的分片節(jié)點(diǎn)中將數(shù)據(jù)進(jìn)行排序并返回成黄，然后將不同分片返回的結(jié)果集進(jìn)行匯總和再次排序呐芥。
如逻杖，進(jìn)行水平分庫(kù)后的商品庫(kù)，按ID倒序排序分頁(yè)思瘟，取第一頁(yè) ：

在這里插入圖片描述

以上流程是取第一頁(yè)的數(shù)據(jù)荸百，性能影響不大，但由于商品信息的分布在各數(shù)據(jù)庫(kù)的數(shù)據(jù)可能是隨機(jī)的滨攻，如果是取第N頁(yè)够话，需要將所有節(jié)點(diǎn)前N頁(yè)數(shù)據(jù)都取出來(lái)合并，再進(jìn)行整體的排序光绕，操作效率可想而知女嘲。所以請(qǐng)求頁(yè)數(shù)越大，系統(tǒng)的性能也會(huì)越差诞帐。在使用Max欣尼、Min、Sum景埃、Count之類(lèi)的函數(shù)進(jìn)行計(jì)算的時(shí)候媒至，與排序分頁(yè)同理，也需要先在每個(gè)分片上執(zhí)行相應(yīng)的函數(shù)谷徙，然后將各個(gè)分片的結(jié)果集進(jìn)行匯總和再次計(jì)算，最終將結(jié)果返回驯绎。

1.3.4.主鍵避重

在分庫(kù)分表環(huán)境中完慧，由于表中數(shù)據(jù)同時(shí)存在不同數(shù)據(jù)庫(kù)中，主鍵值平時(shí)使用的自增長(zhǎng)將無(wú)用武之地剩失，某個(gè)分區(qū)數(shù)據(jù)庫(kù)生成的ID無(wú)法保證全局唯一屈尼。因此需要單獨(dú)設(shè)計(jì)全局主鍵，比避免跨庫(kù)主鍵重復(fù)問(wèn)題拴孤。

在這里插入圖片描述

1.3.5.公共表

實(shí)際的應(yīng)用場(chǎng)景中脾歧，參數(shù)表、數(shù)據(jù)字典表等都是數(shù)據(jù)量較小演熟，變動(dòng)少鞭执，而且屬于高頻聯(lián)合查詢的依賴表。例子中地理區(qū)域表也屬于此類(lèi)型芒粹。
可以將這類(lèi)表在每個(gè)數(shù)據(jù)庫(kù)都保存一份兄纺，所有對(duì)公共表的更新操作都同時(shí)發(fā)送到分庫(kù)執(zhí)行。
由于分庫(kù)分表之后化漆，數(shù)據(jù)被分散在不同的數(shù)據(jù)庫(kù)估脆、服務(wù)器。因此座云，對(duì)數(shù)據(jù)的操作也就無(wú)法通過(guò)常規(guī)方式完成疙赠，并且它還帶來(lái)了一系列的問(wèn)題付材。好在，這些問(wèn)題不是所有都需要我們?cè)趹?yīng)用層面上解決圃阳，其中Sharding-JDBC中間件可供選擇伞租。

1.4 Sharding-JDBC介紹

1.4.1 Sharding-JDBC介紹

Sharding-JDBC是當(dāng)當(dāng)網(wǎng)研發(fā)的開(kāi)源分布式數(shù)據(jù)庫(kù)中間件，從 3.0 開(kāi)始Sharding-JDBC被包含在 Sharding-Sphere 中限佩，之后該項(xiàng)目進(jìn)入進(jìn)入Apache孵化器葵诈，4.0版本之后的版本為Apache版本。
ShardingSphere是一套開(kāi)源的分布式數(shù)據(jù)庫(kù)中間件解決方案組成的生態(tài)圈祟同，它由Sharding-JDBC作喘、Sharding- Proxy和Sharding-Sidecar(計(jì)劃中)這3款相互獨(dú)立的產(chǎn)品組成。 他們均提供標(biāo)準(zhǔn)化的數(shù)據(jù)分片晕城、分布式事務(wù)和 數(shù)據(jù)庫(kù)治理功能泞坦，可適用于如Java同構(gòu)、異構(gòu)語(yǔ)言砖顷、容器贰锁、云原生等各種多樣化的應(yīng)用場(chǎng)景。
官方地址:https://shardingsphere.apache.org/document/current/cn/overview/
咱們目前只需關(guān)注Sharding-JDBC滤蝠，它定位為輕量級(jí)Java框架豌熄，在Java的JDBC層提供的額外服務(wù)。 它使用客戶端 直連數(shù)據(jù)庫(kù)物咳，以jar包形式提供服務(wù)锣险，無(wú)需額外部署和依賴，可理解為增強(qiáng)版的JDBC驅(qū)動(dòng)览闰，完全兼容JDBC和各種 ORM框架芯肤。
Sharding-JDBC的核心功能為數(shù)據(jù)分片和讀寫(xiě)分離，通過(guò)Sharding-JDBC压鉴，應(yīng)用可以透明的使用jdbc訪問(wèn)已經(jīng)分庫(kù) 分表崖咨、讀寫(xiě)分離的多個(gè)數(shù)據(jù)源，而不用關(guān)心數(shù)據(jù)源的數(shù)量以及數(shù)據(jù)如何分布油吭。

• 適用于任何基于Java的ORM框架击蹲，如: Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
• 基于任何第三方的數(shù)據(jù)庫(kù)連接池上鞠，如:DBCP, C3P0, BoneCP, Druid, HikariCP等际邻。

• 支持任意實(shí)現(xiàn)JDBC規(guī)范的數(shù)據(jù)庫(kù)。目前支持MySQL芍阎，Oracle世曾，SQLServer和PostgreSQL。

  
  
  在這里插入圖片描述
  
  

  上圖展示了Sharding-Jdbc的工作方式，使用Sharding-Jdbc前需要人工對(duì)數(shù)據(jù)庫(kù)進(jìn)行分庫(kù)分表轮听，在應(yīng)用程序中加入 Sharding-Jdbc的Jar包骗露，應(yīng)用程序通過(guò)Sharding-Jdbc操作分庫(kù)分表后的數(shù)據(jù)庫(kù)和數(shù)據(jù)表，由于Sharding-Jdbc是對(duì) Jdbc驅(qū)動(dòng)的增強(qiáng)血巍，使用Sharding-Jdbc就像使用Jdbc驅(qū)動(dòng)一樣萧锉，在應(yīng)用程序中是無(wú)需指定具體要操作的分庫(kù)和分表 的。

1.4.2 與jdbc性能對(duì)比

1. 性能損耗測(cè)試 ：服務(wù)器資源充足述寡、并發(fā)數(shù)相同柿隙，比較JDBC和Sharding-JDBC性能損耗，Sharding-JDBC相對(duì)JDBC損耗不超過(guò)7%鲫凶。
   基準(zhǔn)測(cè)試性能對(duì)比

   
   
   在這里插入圖片描述
2. 性能對(duì)比測(cè)試:服務(wù)器資源使用到極限禀崖，相同的場(chǎng)景JDBC與Sharding-JDBC的吞吐量相當(dāng)。

3. 性能對(duì)比測(cè)試:服務(wù)器資源使用到極限螟炫，Sharding-JDBC采用分庫(kù)分表后波附，Sharding-JDBC吞吐量較JDBC不分表有接近2倍的提升。

   
   
   在這里插入圖片描述