Mysql的分库分表(基于shardingsphere)
生活随笔
收集整理的這篇文章主要介紹了
Mysql的分库分表(基于shardingsphere)
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
一、名詞解釋
庫：database；表：table；分庫分表：sharding
二、數(shù)據(jù)庫架構(gòu)演變
剛開始我們只用單機數(shù)據(jù)庫就夠了，隨后面對越來越多的請求，我們將數(shù)據(jù)庫的寫操作和讀操作進行分離， 使用多個從庫副本（Slaver Replication）負責讀，使用主庫（Master）負責寫， 從庫從主庫同步更新數(shù)據(jù)，保持數(shù)據(jù)一致。架構(gòu)上就是數(shù)據(jù)庫主從同步。 從庫可以水平擴展，所以更多的讀請求不成問題。但是當用戶量級上來后，寫請求越來越多，該怎么辦？加一個Master是不能解決問題的， 因為數(shù)據(jù)要保存一致性，寫操作需要2個master之間同步，相當于是重復(fù)了，而且更加復(fù)雜。這時就需要用到分庫分表（sharding），對寫操作進行切分。
三、分庫分表前的問題
任何問題都是太大或者太小的問題，我們這里面對的數(shù)據(jù)量太大的問題。
因為單服務(wù)器TPS，內(nèi)存，IO都是有限的。 解決方法：分散請求到多個服務(wù)器上； 其實用戶請求和執(zhí)行一個sql查詢是本質(zhì)是一樣的，都是請求一個資源，只是用戶請求還會經(jīng)過網(wǎng)關(guān)，路由，http服務(wù)器等。
單個數(shù)據(jù)庫處理能力有限；單庫所在服務(wù)器上磁盤空間不足；單庫上操作的IO瓶頸 解決方法：切分成更多更小的庫
CRUD都成問題；索引膨脹，查詢超時 解決方法：切分成多個數(shù)據(jù)集更小的表。
四、分庫分表的方式方法
一般就是垂直切分和水平切分，這是一種結(jié)果集描述的切分方式，是物理空間上的切分。 我們從面臨的問題，開始解決，闡述： 首先是用戶請求量太大，我們就堆機器搞定（這不是本文重點）。然后是單個庫太大，這時我們要看是因為表多而導致數(shù)據(jù)多，還是因為單張表里面的數(shù)據(jù)多。 如果是因為表多而數(shù)據(jù)多，使用垂直切分，根據(jù)業(yè)務(wù)切分成不同的庫。如果是因為單張表的數(shù)據(jù)量太大，這時要用水平切分，即把表的數(shù)據(jù)按某種規(guī)則切分成多張表，甚至多個庫上的多張表。 分庫分表的順序應(yīng)該是先垂直分，后水平分。 因為垂直分更簡單，更符合我們處理現(xiàn)實世界問題的方式。
1. 垂直拆分- 垂直分表
也就是“大表拆小表”，基于列字段進行的。一般是表中的字段較多，將不常用的， 數(shù)據(jù)較大，長度較長（比如text類型字段）的拆分到“擴展表“。 一般是針對那種幾百列的大表，也避免查詢時，數(shù)據(jù)量太大造成的“跨頁”問題。
- 垂直分庫（就是每個業(yè)務(wù)專門建庫，不要把多個業(yè)務(wù)的表糅合在一個庫里）
垂直分庫針對的是一個系統(tǒng)中的不同業(yè)務(wù)進行拆分，比如用戶User一個庫，商品Producet一個庫，訂單Order一個庫。切分后，要放在多個服務(wù)器上，而不是一個服務(wù)器上。為什么？我們想象一下，一個購物網(wǎng)站對外提供服務(wù)，會有用戶，商品，訂單等的CRUD。沒拆分之前，全部都是落到單一的庫上的，這會讓數(shù)據(jù)庫的單庫處理能力成為瓶頸。按垂直分庫后，如果還是放在一個數(shù)據(jù)庫服務(wù)器上，隨著用戶量增大，這會讓單個數(shù)據(jù)庫的處理能力成為瓶頸，還有單個服務(wù)器的磁盤空間，內(nèi)存，tps等非常吃緊。所以我們要拆分到多個服務(wù)器上，這樣上面的問題都解決了，以后也不會面對單機資源問題。數(shù)據(jù)庫業(yè)務(wù)層面的拆分，和服務(wù)的“治理”，“降級”機制類似，也能對不同業(yè)務(wù)的數(shù)據(jù)分別的進行管理，維護，監(jiān)控，擴展等。 數(shù)據(jù)庫往往最容易成為應(yīng)用系統(tǒng)的瓶頸，而數(shù)據(jù)庫本身屬于“有狀態(tài)”的，相對于Web和應(yīng)用服務(wù)器來講，是比較難實現(xiàn)“橫向擴展”的。數(shù)據(jù)庫的連接資源比較寶貴且單機處理能力也有限，在高并發(fā)場景下，垂直分庫一定程度上能夠突破IO、連接數(shù)及單機硬件資源的瓶頸。
- 水平分表
針對數(shù)據(jù)量巨大的單張表（比如訂單表），按照某種規(guī)則（RANGE,HASH取模等），切分到多張表里面去。 但是這些表還是在同一個庫中，所以庫級別的數(shù)據(jù)庫操作還是有IO瓶頸。不建議采用。 - 水平分庫分表
將單張表的數(shù)據(jù)切分到多個服務(wù)器上去，每個服務(wù)器具有相應(yīng)的庫與表，只是表中數(shù)據(jù)集合不同。 水平分庫分表能夠有效的緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數(shù)、硬件資源等的瓶頸。 - 水平分庫分表切分規(guī)則
- RANGE
從0到10000一個表，10001到20000一個表； - HASH取模
一個商場系統(tǒng)，一般都是將用戶，訂單作為主表，然后將和它們相關(guān)的作為附表，這樣不會造成跨庫事務(wù)之類的問題。 取用戶id，然后hash取模，分配到不同的數(shù)據(jù)庫上。 - 地理區(qū)域
比如按照華東，華南，華北這樣來區(qū)分業(yè)務(wù)，七牛云應(yīng)該就是如此。 - 時間
按照時間切分，就是將6個月前，甚至一年前的數(shù)據(jù)切出去放到另外的一張表，因為隨著時間流逝，這些表的數(shù)據(jù) 被查詢的概率變小，所以沒必要和“熱數(shù)據(jù)”放在一起，這個也是“冷熱數(shù)據(jù)分離”。
- RANGE
- 水平分庫
- 水平分表（這些表還是在同一個庫中，所以庫級別的數(shù)據(jù)庫操作還是有IO瓶頸）
注意：隨著數(shù)據(jù)庫數(shù)據(jù)量增加，不要馬上考慮做水平切分，首先考慮緩存處理，讀寫分離，使用索引等等方式，如果這些方式不能根本解決問題了，再考慮做水平分庫和水平分表
五、分庫分表后面臨的問題
分庫分表后，就成了分布式事務(wù)了。如果依賴數(shù)據(jù)庫本身的分布式事務(wù)管理功能去執(zhí)行事務(wù)，將付出高昂的性能代價； 如果由應(yīng)用程序去協(xié)助控制，形成程序邏輯上的事務(wù)，又會造成編程方面的負擔。
分庫分表后表之間的關(guān)聯(lián)操作將受到限制，我們無法join位于不同分庫的表，也無法join分表粒度不同的表， 結(jié)果原本一次查詢能夠完成的業(yè)務(wù)，可能需要多次查詢才能完成。 粗略的解決方法： 全局表：基礎(chǔ)數(shù)據(jù)，所有庫都拷貝一份。 字段冗余：這樣有些字段就不用join去查詢了。 系統(tǒng)層組裝：分別查詢出所有，然后組裝起來，較復(fù)雜。
六、Mysql分庫分表例子(shardingsphere)
shardingsphere官網(wǎng)
數(shù)據(jù)庫創(chuàng)建兩張一樣結(jié)構(gòu)的表
application.properties配置
測試：
@SpringBootTest class ShardingApplicationTests {@AutowiredCourseMapper courseMapper;@Testvoid contextLoads() {for (long i = 0 ; i<20; i++){courseMapper.insert(new Course(null,String.valueOf(i+1),i,String.valueOf(i)));}} }course_1
course_2
分別創(chuàng)建sharding_1庫，sharding_2庫，每個庫下再創(chuàng)建course_1表，course_2表，course_3表
application.properties配置
# shardingjdbc分片策略 # 配置數(shù)據(jù)源，給數(shù)據(jù)源起名稱, # 水平分庫，配置兩個數(shù)據(jù)源(分別對應(yīng)shardin_g1,sharding_2) spring.shardingsphere.datasource.names=m1,m2#配置第一個數(shù)據(jù)源具體內(nèi)容，包含連接池，驅(qū)動，地址，用戶名和密碼 spring.shardingsphere.datasource.m1.type=com.alibaba.druid.pool.DruidDataSource spring.shardingsphere.datasource.m1.driver-class-name=com.mysql.cj.jdbc.Driver spring.shardingsphere.datasource.m1.url=jdbc:mysql://localhost:63306/sharding_1?useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=GMT%2B8&useSSL=true&characterEncoding=UTF-8&rewriteBatchedStatements=true spring.shardingsphere.datasource.m1.username=root spring.shardingsphere.datasource.m1.password=root#配置第二個數(shù)據(jù)源具體內(nèi)容，包含連接池，驅(qū)動，地址，用戶名和密碼 spring.shardingsphere.datasource.m2.type=com.alibaba.druid.pool.DruidDataSource spring.shardingsphere.datasource.m2.driver-class-name=com.mysql.cj.jdbc.Driver spring.shardingsphere.datasource.m2.url=jdbc:mysql://localhost:63306/sharding_2?useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=GMT%2B8&useSSL=true&characterEncoding=UTF-8&rewriteBatchedStatements=true spring.shardingsphere.datasource.m1.username=root spring.shardingsphere.datasource.m1.password=root#指定數(shù)據(jù)庫分布情況，數(shù)據(jù)庫里面表分布情況 # m1 m2 course_1 course_2 course_3 spring.shardingsphere.sharding.tables.course.actual-data-nodes=m$->{1..2}.course_$->{1..3}# 指定course表里面主鍵cid 生成策略 SNOWFLAKE spring.shardingsphere.sharding.tables.course.key-generator.column=cid spring.shardingsphere.sharding.tables.course.key-generator.type=SNOWFLAKE# 指定表分片策略 約定cid%3=0加到course_1表，如果cid%3=1添加到course_2表, 如果cid%3=2添加到course_3表 spring.shardingsphere.sharding.tables.course.table-strategy.inline.sharding-column=cid spring.shardingsphere.sharding.tables.course.table-strategy.inline.algorithm-expression=course_$->{cid % 3 + 1}# 指定庫分片策略 約定user_id是偶數(shù)添加m1，是奇數(shù)添加m2 spring.shardingsphere.sharding.tables.course.database-strategy.inline..sharding-column=user_id spring.shardingsphere.sharding.tables.course.database-strategy.inline.algorithm-expression=m$->{user_id % 2 + 1}# 打開sql輸出日志 spring.shardingsphere.props.sql.show=true測試：
@SpringBootTest class ShardingApplicationTests {@AutowiredCourseMapper courseMapper;@Testvoid contextLoads() {for (long i = 0 ; i<20; i++){courseMapper.insert(new Course(null,String.valueOf(i+1),i,String.valueOf(i)));}} }這里只展示userid為偶數(shù)的數(shù)據(jù)（完美實現(xiàn)分庫分表）
測試獲取一條數(shù)據(jù)
@Testvoid get(){Course course = courseMapper.selectById(631501645238239232L);}
可以看到，因為無法確定該數(shù)據(jù)是在哪個庫（因為我們查詢的時候并沒有指定分庫時用的userid），所以shardingproxy就到兩個庫里找，但是根據(jù)cid，shardingproxy能確定在course_3庫，所以，只在course_3里查找。
參考文章
公共表屬于系統(tǒng)中數(shù)據(jù)量較小，變動少，而且屬于高頻聯(lián)合查詢的依賴表。參數(shù)表、數(shù)據(jù)字典表等屬于此類型。可以將這類表在每個數(shù)據(jù)庫都保存一份，所有更新操作都同時發(fā)送到所有分庫執(zhí)行。
- 創(chuàng)建dict表
添加以下配置：
# 添加公共表 spring.shardingsphere.sharding.broadcast-tables=dict spring.shardingsphere.sharding.tables.dict.key-generator.column=dict_id spring.shardingsphere.sharding.tables.dict.key-generator.type=SNOWFLAKE測試
@Testvoid insertCommon(){dictMapper.insert(new Dict(null,"1","1","1"));}結(jié)果可以看到，兩個數(shù)據(jù)源中都插了該信息
刪除的時候也是全部刪除
可以看到，讀寫分離需要配合數(shù)據(jù)庫的主從復(fù)制，而Sharding-JDBC讀寫分離則是根據(jù)SQL語義的分析，將讀操作（select）和寫操作(insert update)分別路由至主庫與從庫，它提供透明化的讀寫分離，讓使用方盡量使用一個數(shù)據(jù)庫一樣使用主從數(shù)據(jù)庫集群。
在這里我部署了兩臺mysql從機，和一臺mysql主機，主機負責寫，兩臺從機同步主機數(shù)據(jù)并負責讀。
結(jié)構(gòu)如下：
數(shù)據(jù)分離+讀寫分離的配置文件
- 查詢：
可以看到，由于是使用user_id進行查詢的，sharding根據(jù)43自然知道只需要在user_id為單數(shù)的那個庫查找即可，而且由于查詢是輪詢的，所以可以看到兩個從庫被輪詢查找，但是每次查找的表是不一樣的
- 插入
可以看到，只在m1，m2之間輪詢插入數(shù)據(jù)，而不會在從庫(s1,s2,s3,s4)進行插入
更詳細的配置文件參考官網(wǎng)
總結(jié)
以上是生活随笔為你收集整理的Mysql的分库分表(基于shardingsphere)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 产品经理如何洞察人性？
- 下一篇： mysql 查询有 float 类型的字