mysql分庫(kù)分表一般有如下場(chǎng)景

創(chuàng)新互聯(lián)公司是專業(yè)的廣豐網(wǎng)站建設(shè)公司,廣豐接單;提供成都網(wǎng)站建設(shè)、成都網(wǎng)站制作,網(wǎng)頁(yè)設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行廣豐網(wǎng)站開發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來(lái)合作!
其中1,2相對(duì)較容易實(shí)現(xiàn),本文重點(diǎn)講講水平拆表和水平拆庫(kù),以及基于mybatis插件方式實(shí)現(xiàn)水平拆分方案落地。
在 《聊一聊擴(kuò)展字段設(shè)計(jì)》 一文中有講解到基于KV水平存儲(chǔ)擴(kuò)展字段方案,這就是非常典型的可以水平分表的場(chǎng)景。主表和kv表是一對(duì)N關(guān)系,隨著主表數(shù)據(jù)量增長(zhǎng),KV表最大N倍線性增長(zhǎng)。
這里我們以分KV表水平拆分為場(chǎng)景
對(duì)于kv擴(kuò)展字段查詢,只會(huì)根據(jù)id + key 或者 id 為條件的方式查詢,所以這里我們可以按照id 分片即可
分512張表(實(shí)際場(chǎng)景具體分多少表還得根據(jù)字段增加的頻次而定)
分表后表名為kv_000 ~ kv_511
id % 512 = 1 .... 分到 kv_001,
id % 512 = 2 .... 分到 kv_002
依次類推!
水平分表相對(duì)比較容易,后面會(huì)講到基于mybatis插件實(shí)現(xiàn)方案
場(chǎng)景:以下我們基于博客文章表分庫(kù)場(chǎng)景來(lái)分析
目標(biāo):
表結(jié)構(gòu)如下(節(jié)選部分字段):
按照user_id sharding
假如分1024個(gè)庫(kù),按照user_id % 1024 hash
user_id % 1024 = 1 分到db_001庫(kù)
user_id % 1024 = 2 分到db_002庫(kù)
依次類推
目前是2個(gè)節(jié)點(diǎn),假如后期達(dá)到瓶頸,我們可以增加至4個(gè)節(jié)點(diǎn)
最多可以增加只1024個(gè)節(jié)點(diǎn),性能線性增長(zhǎng)
對(duì)于水平分表/分庫(kù)后,非shardingKey查詢首先得考慮到
基于mybatis分庫(kù)分表,一般常用的一種是基于spring AOP方式, 另外一種基于mybatis插件。其實(shí)兩種方式思路差不多。
為了比較直觀解決這個(gè)問(wèn)題,我分別在Executor 和StatementHandler階段2個(gè)攔截器
實(shí)現(xiàn)動(dòng)態(tài)數(shù)據(jù)源獲取接口
測(cè)試結(jié)果如下
由此可知,我們需要在Executor階段 切換數(shù)據(jù)源
對(duì)于分庫(kù):
原始sql:
目標(biāo)sql:
其中定義了三個(gè)注解
@useMaster 是否強(qiáng)制讀主
@shardingBy 分片標(biāo)識(shí)
@DB 定義邏輯表名 庫(kù)名以及分片策略
1)編寫entity
Insert
select
以上順利實(shí)現(xiàn)mysql分庫(kù),同樣的道理實(shí)現(xiàn)同時(shí)分庫(kù)分表也很容易實(shí)現(xiàn)。
此插件具體實(shí)現(xiàn)方案已開源:
目錄如下:
mysql分庫(kù)分表,首先得找到瓶頸在哪里(IO or CPU),是分庫(kù)還是分表,分多少?不能為了分庫(kù)分表而拆分。
原則上是盡量先垂直拆分 后 水平拆分。
以上基于mybatis插件分庫(kù)分表是一種實(shí)現(xiàn)思路,還有很多不完善的地方,
例如:
MySQL單表(innoDB)可以存儲(chǔ)10億級(jí)數(shù)據(jù),只是這時(shí)候性能比較差,業(yè)界公認(rèn)MySQL單表容量在1KW以下是最佳狀態(tài),因?yàn)檫@時(shí)它的BTREE索引樹高在3~5之間。
參考阿里開發(fā)手冊(cè)建議:
1.單表行數(shù)超過(guò) 500 萬(wàn)行或者單表容量超過(guò) 2GB,才推薦進(jìn)行分庫(kù)分表;如果預(yù)計(jì)三年后的數(shù)據(jù)量根本達(dá)不到這個(gè)級(jí)別,請(qǐng)不要在創(chuàng)建表時(shí)就分庫(kù)分表。
2.實(shí)際情況受mysql機(jī)器配置等多方面影響,可能數(shù)據(jù)量很大但性能依舊不錯(cuò),但考慮后續(xù)發(fā)展一定要進(jìn)行分庫(kù)分表考慮。
根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景選擇合適的分片數(shù)據(jù),參考如下:
根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景選擇適當(dāng)?shù)姆制侄危_(dá)到如下要求:
分表數(shù)量和分表字段確定后,要設(shè)計(jì)一個(gè)合理的分表規(guī)則,良好的分表規(guī)則要達(dá)到如下條件:
如何保證分片數(shù)據(jù)均勻,參考:
如何保證方便后續(xù)分片擴(kuò)容,參考:
如何高效的使用分庫(kù)分表,核心是做到盡量的路由到最少的表,最好是只路由到一個(gè)表里面
核心規(guī)則如下:
階段一
階段二
階段三
本文鏈接:
一、分庫(kù)分表的必要性
分庫(kù)分表技術(shù)的使用,主要是數(shù)據(jù)庫(kù)產(chǎn)生了瓶頸,如單庫(kù)的并發(fā)訪問(wèn)或單表的查詢都超出了閾值。對(duì)系統(tǒng)使用造成一定的影響,不得已而產(chǎn)生的技術(shù)。
通過(guò)分庫(kù)分表技術(shù)來(lái)解決此類問(wèn)題,但正因?yàn)槭褂么思夹g(shù),會(huì)產(chǎn)生ACID一系列的問(wèn)題,各類中間件解決此類問(wèn)題各有各的優(yōu)勢(shì)。
提示:如場(chǎng)景無(wú)必要,千萬(wàn)不要使用分庫(kù)分表。
二、分庫(kù)分表的思路
1、垂直區(qū)分
垂直分庫(kù):從業(yè)務(wù)角度,一個(gè)庫(kù)分成多個(gè)庫(kù),如把訂單和用戶信息分成兩個(gè)庫(kù)來(lái)存儲(chǔ)。這樣的好處就是可以微服務(wù)了。每塊的業(yè)務(wù)單獨(dú)部署,互不影響,通過(guò)接口去調(diào)用。
垂直分表:把大表分成多個(gè)小表,如熱點(diǎn)數(shù)據(jù)和非熱點(diǎn)數(shù)據(jù)分開,提高查詢速度。
2、水平區(qū)分
水平分表:同一業(yè)務(wù)如數(shù)據(jù)量大了以后,根據(jù)一定的規(guī)則分為不同的表進(jìn)行存儲(chǔ)。
水平分庫(kù):如訂單分成多個(gè)庫(kù)存儲(chǔ),分解服務(wù)器壓力。
以上一般來(lái)說(shuō),垂直分庫(kù)和水平分表用的會(huì)多些。
三、分庫(kù)分表的原理分析
分庫(kù)分表常用的方案:Hash取模方案和range范圍方案;
路由算法為最主要的算法,指得是把路由的Key按照指定的算法進(jìn)行存放;
1、Hash取模方案
根據(jù)取余分配到不同的表里。要根據(jù)實(shí)際情況確認(rèn)模的大小。此方案由于平均分配,不存在熱點(diǎn)問(wèn)題,但數(shù)據(jù)遷移很復(fù)雜。
2、Range范圍方案
range根據(jù)范圍進(jìn)行劃分,如日期,大小。此方案不存在數(shù)據(jù)遷移,但存在熱點(diǎn)問(wèn)題。
四、分庫(kù)分表的技術(shù)選型
1、技術(shù)選型
解決方案主要分為4種:MySQL的分區(qū)技術(shù)、NoSql、NewSQL、MySQL的分庫(kù)分表。
(1)mysql分區(qū)技術(shù):把一張表存放在不同存儲(chǔ)文件。由于無(wú)法負(fù)載,使用較少。
(2)NoSQL(如MongoDB):如是訂單等比較重要數(shù)據(jù),強(qiáng)關(guān)聯(lián)關(guān)系,需約束一致性,不太適應(yīng)。
(3)NewSql(具有NoSQL對(duì)海量數(shù)據(jù)的存儲(chǔ)管理能力,還保持了傳統(tǒng)數(shù)據(jù)庫(kù)支持ACID和SQL等特性):如TiDB可滿足需求。
(4)MySQL的分庫(kù)分表:如使用mysql,此種方案為主流方式。
2、中間件
解決此類問(wèn)題的中間件主要為:Proxy模式、Client模式。
(1)Proxy模式
(2)Client模式
把分庫(kù)分表相關(guān)邏輯存放在客戶端,一版客戶端的應(yīng)用會(huì)引用一個(gè)jar,然后再jar中處理SQL組合、數(shù)據(jù)庫(kù)路由、執(zhí)行結(jié)果合并等相關(guān)功能。
(3)中間件的比較
由于Client模式少了一層,運(yùn)維方便,相對(duì)來(lái)說(shuō)容易些。
五、分庫(kù)分表的實(shí)踐
根據(jù)容量(當(dāng)前容量和增長(zhǎng)量)評(píng)估分庫(kù)或分表個(gè)數(shù) - 選key(均勻)- 分表規(guī)則(hash或range等)- 執(zhí)行(一般雙寫)- 擴(kuò)容問(wèn)題(盡量減少數(shù)據(jù)的移動(dòng))。
在這里我們選用中間件share-jdbc。
1、引入maven依賴
2、spring boot規(guī)則配置
行表達(dá)式標(biāo)識(shí)符可以使用${...}或$-{...},但前者與Spring本身的屬性文件占位符沖突,因此在Spring環(huán)境中使用行表達(dá)式標(biāo)識(shí)符建議使用$-{...}。
3、創(chuàng)建DataSource
通過(guò)ShardingDataSourceFactory工廠和規(guī)則配置對(duì)象獲取ShardingDataSource,ShardingDataSource實(shí)現(xiàn)自JDBC的標(biāo)準(zhǔn)接口DataSource。然后即可通過(guò)DataSource選擇使用原生JDBC開發(fā),或者使用JPA, MyBatis等ORM工具。
1,接收到sql;2,把sql放到排隊(duì)隊(duì)列中 ;3,執(zhí)行sql;4,返回執(zhí)行結(jié)果。在這個(gè)執(zhí)行過(guò)程中最花時(shí)間在什么地方呢?第一,是排隊(duì)等待的時(shí)間,第二,sql的執(zhí)行時(shí)間。其實(shí)這二個(gè)是一回事,等待的同時(shí),肯定有sql在執(zhí)行。所以我們要縮短sql的執(zhí)行時(shí)間。
mysql中有一種機(jī)制是表鎖定和行鎖定,為什么要出現(xiàn)這種機(jī)制,是為了保證數(shù)據(jù)的完整 性,我舉個(gè)例子來(lái)說(shuō)吧,如果有二個(gè)sql都要修改同一張表的同一條數(shù)據(jù),這個(gè)時(shí)候怎么辦呢,是不是二個(gè)sql都可以同時(shí)修改這條數(shù)據(jù)呢?很顯然mysql 對(duì)這種情況的處理是,一種是表鎖定(myisam存儲(chǔ)引擎),一個(gè)是行鎖定(innodb存儲(chǔ)引擎)。表鎖定表示你們都不能對(duì)這張表進(jìn)行操作,必須等我對(duì) 表操作完才行。行鎖定也一樣,別的sql必須等我對(duì)這條數(shù)據(jù)操作完了,才能對(duì)這條數(shù)據(jù)進(jìn)行操作。如果數(shù)據(jù)太多,一次執(zhí)行的時(shí)間太長(zhǎng),等待的時(shí)間就越長(zhǎng),這 也是我們?yōu)槭裁匆直淼脑颉?/p>
分享文章:mysql怎么分庫(kù)分表,mysql怎么分庫(kù)分表如何查詢
本文URL:http://chinadenli.net/article8/dsidsop.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供動(dòng)態(tài)網(wǎng)站、軟件開發(fā)、用戶體驗(yàn)、全網(wǎng)營(yíng)銷推廣、網(wǎng)站導(dǎo)航、外貿(mào)網(wǎng)站建設(shè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)