一、什么是分庫分表？

分庫：從單個(gè)數(shù)據(jù)庫拆分成多個(gè)數(shù)據(jù)庫的過程，將數(shù)據(jù)散落在多個(gè)數(shù)據(jù)庫中。
分表：從單張表拆分成多張表的過程，將數(shù)據(jù)散落在多張表內(nèi)。

二、為什么分庫分表？

隨著平臺(tái)的業(yè)務(wù)發(fā)展，數(shù)據(jù)可能會(huì)越來越多，甚至達(dá)到億級(jí)。以MySQL為例，單庫數(shù)據(jù)量在5000萬以內(nèi)性能比較好，超過閾值后性能會(huì)隨著數(shù)據(jù)量的增大而明顯降低。單表的數(shù)據(jù)量超過1000w，性能也會(huì)下降嚴(yán)重。這就會(huì)導(dǎo)致查詢一次所花的時(shí)間變長(zhǎng)，并發(fā)操作達(dá)到一定量時(shí)可能會(huì)卡死，甚至把系統(tǒng)給拖垮。

三、怎么選擇分庫分表策略？

四、分庫分表方式及帶來的問題？

分庫分表有效的緩解了大數(shù)據(jù)、高并發(fā)帶來的性能和壓力，也能突破網(wǎng)絡(luò)IO、硬件資源、連接數(shù)的瓶頸，但同時(shí)也帶來了一些問題。

4.1、事務(wù)一致性問題

由于分庫分表把數(shù)據(jù)分布在不同庫甚至不同服務(wù)器，不可避免會(huì)帶來分布式事務(wù)問題，我們需要額外編程解決該問題。

4.2、跨節(jié)點(diǎn)join

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

SELECT p.*,s.[店鋪名稱],s.[信譽(yù)]
FROM [商品信息] p 
LEFT JOIN [店鋪信息] s ON p.id = s.[所屬店鋪]
WHERE...ORDER BY...LIMIT...

但經(jīng)過分庫分表后，[商品信息]和[店鋪信息]不在一個(gè)數(shù)據(jù)庫或一個(gè)表中，甚至不在一臺(tái)服務(wù)器上，無法通過sql語句進(jìn)行關(guān)聯(lián)查詢，我們需要額外編程解決該問題。

4.3、跨節(jié)點(diǎn)分頁、排序和聚合函數(shù)

跨節(jié)點(diǎn)多庫進(jìn)行查詢時(shí)，limit分頁、order by排序以及聚合函數(shù)等問題，就變得比較復(fù)雜了。需要先在不同的分片節(jié)點(diǎn)中將數(shù)據(jù)進(jìn)行排序并返回，然后將不同分片返回的結(jié)果集進(jìn)行匯總和再次排序。例如，進(jìn)行水平分庫后的商品庫，按ID倒序排序分頁，取第一頁：

以上流程是取第一頁的數(shù)據(jù)，性能影響不大，但由于商品信息的分布在各數(shù)據(jù)庫的數(shù)據(jù)可能是隨機(jī)的，如果是取第N頁，需要將所有節(jié)點(diǎn)前N頁數(shù)據(jù)都取出來合并，再進(jìn)行整體的排序，操作效率可想而知，所以請(qǐng)求頁數(shù)越大，系統(tǒng)的性能也會(huì)越差。

在使用Max、Min、Sum、Count之類的函數(shù)進(jìn)行計(jì)算的時(shí)候，與排序分頁同理，也需要先在每個(gè)分片上執(zhí)行相應(yīng)的函數(shù)，然后將各個(gè)分片的結(jié)果集進(jìn)行匯總和再次計(jì)算，最終將結(jié)果返回。

4.4、主鍵避重

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

由于分庫分表之后，數(shù)據(jù)被分散在不同的服務(wù)器、數(shù)據(jù)庫和表中。因此，對(duì)數(shù)據(jù)的操作也就無法通過常規(guī)方式完成，并且它還帶來了一系列的問題。我們?cè)陂_發(fā)過程中需要通過一些中間件解決這些問題，市面上有很多中間件可供我們選擇，其中Sharding-JDBC和mycat較為流行。

五、使用分庫分表組件幫我們解決一些問題

分庫分表的技術(shù)方案總體上來講分為兩大類：應(yīng)用層依賴類中間件、中間層代理類中間件。

我們選擇技術(shù)方案時(shí)主要考慮的是，開源、開發(fā)成本、學(xué)習(xí)成本、技術(shù)復(fù)雜度，技術(shù)使用人數(shù)，參考資料的多少等方面。

由于我本人也不是每樣技術(shù)都有用過。所以在這里只是在能力范圍內(nèi)做一個(gè)初步了解，并進(jìn)行選型。目前這些組件對(duì)于分庫分表的一些主要問題都有相對(duì)完善的解決方案，區(qū)別的只是一些細(xì)節(jié)的問題。又結(jié)合目前項(xiàng)目所在只需要輕量級(jí)的分庫分表。所以我還是比較偏向成本較低，復(fù)雜度較低的方案。

目前市面上使用較多的是，mycat及sharding-jdbc。mycat屬于中間層代理類中間件、sharding-jdbc屬于應(yīng)用層依賴類中間件

5.1. Atlas

奇虎360
關(guān)鍵詞：分庫分表 Atlas
百度為您找到相關(guān)結(jié)果約707,000個(gè)
中間層代理類中間件

https://github.com/Qihoo360/Atlas github上最后維護(hù)時(shí)間為4年前

• 優(yōu)點(diǎn)

  實(shí)現(xiàn)了讀寫分離(并通過hint/master/可強(qiáng)制?主庫，并且加?了權(quán)重配置可進(jìn)?讀的負(fù)載均衡

  ??維護(hù)了?套連接池，減少了創(chuàng)建連接帶來的性能消耗

  ?持DB動(dòng)態(tài)上下線，?便橫向擴(kuò)展

  ?持ip過濾，實(shí)現(xiàn)了簡(jiǎn)單的權(quán)限控制

  可記錄所有sql，實(shí)現(xiàn)了簡(jiǎn)單的審計(jì)功能

• 缺點(diǎn)

  使?atlas?直連DB，性能損耗?概是30%-35%左右

  使?atlas?直連DB，響應(yīng)時(shí)間?概是直連DB的1.5~2倍

  對(duì)分表的?持不是太好，不支持不同庫間分表

  atlas配置暫時(shí)不?持配置參數(shù)的動(dòng)態(tài)加載，如果修改了配置需要重啟atlas，這可能會(huì)對(duì)業(yè)務(wù)有?點(diǎn)的影響(不過?般可以做ha或者業(yè)務(wù)低峰進(jìn)?重啟，這個(gè)問題不是特別迫切)總的來說作為?款開源mysql proxy，atlas總體表現(xiàn)還是不錯(cuò)的，持續(xù)壓測(cè)3天都?較穩(wěn)定，只是對(duì)分表的?持不是太好(?如不?持基于時(shí)間的分表模式)，?般沒有太?并發(fā)和對(duì)響應(yīng)時(shí)間嚴(yán)格要求的業(yè)務(wù)可以考慮嘗試使?

5.2. Cobar

阿里
關(guān)鍵詞：分庫分表 Cobar
百度為您找到相關(guān)結(jié)果約936,000個(gè)
中間層代理類中間件

https://github.com/alibaba/cobar/ github上最后維護(hù)時(shí)間為3年前

5.3. TDDL

阿里 關(guān)鍵詞：分庫分表 TDDL 百度為您找到相關(guān)結(jié)果約1,080,000個(gè) 應(yīng)用層依賴類中間件

https://github.com/alibaba/tb_tddl

github上TDDL處于停滯狀態(tài)，應(yīng)該是部分功能不開源了吧。

TDDL 必須要依賴 diamond 配置中心（ diamond 是淘寶內(nèi)部使用的一個(gè)管理持久配置的系統(tǒng)，目前淘寶內(nèi)部絕大多數(shù)系統(tǒng)的配置）

5.4. heisenberg

百度
關(guān)鍵詞：分庫分表 heisenberg
百度為您找到相關(guān)結(jié)果約74,900個(gè)
中間層代理類中間件

資料少之又少，不考慮。

5.5. Oceanus

58同城
關(guān)鍵詞：分庫分表 Oceanus
百度為您找到相關(guān)結(jié)果約118,000個(gè)

https://github.com/wuba/Oceanus github上最后維護(hù)時(shí)間為3年前

資料較少，不考慮。

5.6. OneProxy

原支付寶首席架構(gòu)師樓方鑫開發(fā)
關(guān)鍵詞：分庫分表 OneProxy
百度為您找到相關(guān)結(jié)果約139,000個(gè)
應(yīng)該是不開源的

5.7. vitess

YouTube
關(guān)鍵詞：分庫分表 vitess
百度為您找到相關(guān)結(jié)果約177,000個(gè)
中間層代理類中間件

https://github.com/vitessio/vitess github當(dāng)前活躍

Vitess是一個(gè)用于部署、擴(kuò)展和管理大型MySQL實(shí)例集群的數(shù)據(jù)庫解決方案。是開源的，在github上有很多星星，但是國(guó)內(nèi)的應(yīng)用較少，資料不多。技術(shù)架構(gòu)復(fù)雜，這位更是重量級(jí)。

5.8. TSharding

蘑菇街
關(guān)鍵詞：分庫分表 TSharding
百度為您找到相關(guān)結(jié)果約100,000個(gè)

https://github.com/baihui212/tsharding github上最后維護(hù)時(shí)間為5年前
應(yīng)該也是不開源了

資料少之又少，不考慮

5.9. dal

攜程
關(guān)鍵詞：分庫分表 dal
百度為您找到相關(guān)結(jié)果約315,000個(gè)
應(yīng)用層依賴類中間件

https://github.com/ctripcorp/dal github當(dāng)前活躍，提供部分教程及demo（需要科學(xué)上網(wǎng)）

開源范圍包括代碼生成器，Java客戶端和C#客戶端。
國(guó)內(nèi)資料少，需要科學(xué)上網(wǎng)。

5.10. zdal

支付寶
關(guān)鍵詞：分庫分表 zdal
百度為您找到相關(guān)結(jié)果約30,600個(gè)
中間層代理類中間件

國(guó)內(nèi)資料少，應(yīng)該不開源。

5.11.MyCat

基于cobar社區(qū)開源
關(guān)鍵詞：分庫分表 MyCat
百度為您找到相關(guān)結(jié)果約9,030,000個(gè)
中間層代理類中間件
http://mycatone.top/社區(qū)當(dāng)前活躍，無需科學(xué)上網(wǎng)
資料很多也開源，可以考慮。

5.11.1不支持項(xiàng)

• DDL語句

  • 不支持修改拆分鍵
  • 支持物理庫的視圖視為普通表來使用
  • 僅普通表支持外鍵
  • DML語句

• DELETE語句

  • 不支持涉及分布式運(yùn)算的子查詢。
  • 不支持多表delete。

• UPDATE語句

  • 不支持涉及分布式運(yùn)算的子查詢。
  • 不支持多表update。

• SELECT語句

  • 對(duì)于for update語句會(huì)把sql中出現(xiàn)的表都加鎖。
  • 具體是行鎖還是表鎖要看sql語句。
  • 不支持SELECT INTO OUTFILE。

• SET語句

  • 支持SET SESSION級(jí)別的變量,但是不能被預(yù)處理語句引用變量,只有autocommit變量具有正確語義
  • 不支持SET GLOBAL級(jí)別的變量
  • 不支持SET USER級(jí)別的變量

• SHOW語句

  • 所有SHOW語句都視為兼容性SQL進(jìn)行處理,發(fā)往prototype節(jié)點(diǎn)處理,所以不具備分布式語義高級(jí)功能
  • 不支持用戶自定義數(shù)據(jù)類型(改代碼), 自定義函數(shù)(改代碼)
  • 支持物理視圖,但是不支持Mycat中的邏輯視圖
  • 有限支持存儲(chǔ)過程
  • 不支持游標(biāo)
  • 不支持觸發(fā)器

5.12.Sharding-jdbc

當(dāng)當(dāng)開源，已加入apache豪華套餐
關(guān)鍵詞：分庫分表 Sharding-jdbc
百度為您找到相關(guān)結(jié)果約4,240,000個(gè)
應(yīng)用層依賴類中間件

https://shardingsphere.apache.org/ 社區(qū)當(dāng)前活躍，無需科學(xué)上網(wǎng)

5.12.1不支持項(xiàng)

• DataSource 接口

  • 不支持 timeout 相關(guān)操作。

• Connection 接口

  • 不支持存儲(chǔ)過程，函數(shù)，游標(biāo)的操作；
  • 不支持執(zhí)行 native SQL；
  • 不支持 savepoint 相關(guān)操作；
  • 不支持 Schema/Catalog 的操作；
  • 不支持自定義類型映射。

• Statement 和 PreparedStatement 接口

  • 不支持返回多結(jié)果集的語句（即存儲(chǔ)過程，非 SELECT 多條數(shù)據(jù)）；
  • 不支持國(guó)際化字符的操作。

• ResultSet 接口

  • 不支持對(duì)于結(jié)果集指針位置判斷；
  • 不支持通過非 next 方法改變結(jié)果指針位置；
  • 不支持修改結(jié)果集內(nèi)容；
  • 不支持獲取國(guó)際化字符；
  • 不支持獲取 Array。

• JDBC 4.1

  • 不支持 JDBC 4.1 接口新功能。

六、詳細(xì)比較

總結(jié)

挑選了兩個(gè)使用最多的進(jìn)行了比較，綜合來看的話感覺還是Sharding-jdbc更省事一些，無需部署中間件，只通過引入jar包進(jìn)行分庫分表操作，省去一些事情。而且多一個(gè)中間件的話系統(tǒng)穩(wěn)定性也會(huì)降低了。對(duì)與目前來說，只需要輕量級(jí)的分庫分表，功能不需要太多，所以還是選擇Sharding-jdbc合適些。

以上就是MySQL數(shù)據(jù)庫分庫分表的方案的詳細(xì)內(nèi)容，更多關(guān)于MySQL數(shù)據(jù)庫分庫分表的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論