一、什么是分庫分表？

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

二、為什么分庫分表？

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

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

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

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

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

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

4.2、跨節(jié)點join

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

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

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

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

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

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

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

4.4、主鍵避重

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

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

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

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

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

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

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

5.1. Atlas

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

https://github.com/Qihoo360/Atlas github上最后維護時間為4年前

• 優(yōu)點

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

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

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

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

  可記錄所有sql，實現(xiàn)了簡單的審計功能

• 缺點

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

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

  對分表的?持不是太好，不支持不同庫間分表

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

5.2. Cobar

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

https://github.com/alibaba/cobar/ github上最后維護時間為3年前

5.3. TDDL

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

https://github.com/alibaba/tb_tddl

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

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

5.4. heisenberg

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

資料少之又少，不考慮。

5.5. Oceanus

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

https://github.com/wuba/Oceanus github上最后維護時間為3年前

資料較少，不考慮。

5.6. OneProxy

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

5.7. vitess

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

https://github.com/vitessio/vitess github當前活躍

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

5.8. TSharding

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

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

資料少之又少，不考慮

5.9. dal

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

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

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

5.10. zdal

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

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

5.11.MyCat

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

5.11.1不支持項

• DDL語句

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

• DELETE語句

  • 不支持涉及分布式運算的子查詢。
  • 不支持多表delete。

• UPDATE語句

  • 不支持涉及分布式運算的子查詢。
  • 不支持多表update。

• SELECT語句

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

• SET語句

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

• SHOW語句

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

5.12.Sharding-jdbc

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

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

5.12.1不支持項

• DataSource 接口

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

• Connection 接口

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

• Statement 和 PreparedStatement 接口

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

• ResultSet 接口

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

• JDBC 4.1

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

六、詳細比較

總結(jié)

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

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

最新評論