分庫 又 分表? 只做過分表的,分庫 的沒搞過。大體思路:
樂山ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景,ssl證書未來市場廣闊!成為成都創(chuàng)新互聯(lián)的ssl證書銷售渠道,可以享受市場價格4-6折優(yōu)惠!如果有意向歡迎電話聯(lián)系或者加微信:13518219792(備注:SSL證書合作)期待與您的合作!
1、你的數(shù)據(jù)必須有個主鍵 auto_increasement 屬性,記錄編號能自動增長。
2、設置一個表,里面存記錄范圍(或者查詢條件)對應的表。比如 1-100萬記錄對應 table1,100萬-200萬 對應table2
3、在php里根據(jù)查詢條件,找到本次查詢可能涉及到的表,就可以對具體的表進行操作了
1,接收到sql;2,把sql放到排隊隊列中 ;3,執(zhí)行sql;4,返回執(zhí)行結(jié)果。在這個執(zhí)行過程中最花時間在什么地方呢?第一,是排隊等待的時間,第二,sql的執(zhí)行時間。其實這二個是一回事,等待的同時,肯定有sql在執(zhí)行。所以我們要縮短sql的執(zhí)行時間。
mysql中有一種機制是表鎖定和行鎖定,為什么要出現(xiàn)這種機制,是為了保證數(shù)據(jù)的完整 性,我舉個例子來說吧,如果有二個sql都要修改同一張表的同一條數(shù)據(jù),這個時候怎么辦呢,是不是二個sql都可以同時修改這條數(shù)據(jù)呢?很顯然mysql 對這種情況的處理是,一種是表鎖定(myisam存儲引擎),一個是行鎖定(innodb存儲引擎)。表鎖定表示你們都不能對這張表進行操作,必須等我對 表操作完才行。行鎖定也一樣,別的sql必須等我對這條數(shù)據(jù)操作完了,才能對這條數(shù)據(jù)進行操作。如果數(shù)據(jù)太多,一次執(zhí)行的時間太長,等待的時間就越長,這 也是我們?yōu)槭裁匆直淼脑颉?/p>
mysql要分庫分表怎樣處理
從字面上簡單理解,就是把原本存儲于一個庫的數(shù)據(jù)分塊存儲到多個庫上,把原本存儲于一個表的數(shù)據(jù)分塊存儲到多個表上。
一、分庫分表的必要性
分庫分表技術的使用,主要是數(shù)據(jù)庫產(chǎn)生了瓶頸,如單庫的并發(fā)訪問或單表的查詢都超出了閾值。對系統(tǒng)使用造成一定的影響,不得已而產(chǎn)生的技術。
通過分庫分表技術來解決此類問題,但正因為使用此技術,會產(chǎn)生ACID一系列的問題,各類中間件解決此類問題各有各的優(yōu)勢。
提示:如場景無必要,千萬不要使用分庫分表。
二、分庫分表的思路
1、垂直區(qū)分
垂直分庫:從業(yè)務角度,一個庫分成多個庫,如把訂單和用戶信息分成兩個庫來存儲。這樣的好處就是可以微服務了。每塊的業(yè)務單獨部署,互不影響,通過接口去調(diào)用。
垂直分表:把大表分成多個小表,如熱點數(shù)據(jù)和非熱點數(shù)據(jù)分開,提高查詢速度。
2、水平區(qū)分
水平分表:同一業(yè)務如數(shù)據(jù)量大了以后,根據(jù)一定的規(guī)則分為不同的表進行存儲。
水平分庫:如訂單分成多個庫存儲,分解服務器壓力。
以上一般來說,垂直分庫和水平分表用的會多些。
三、分庫分表的原理分析
分庫分表常用的方案:Hash取模方案和range范圍方案;
路由算法為最主要的算法,指得是把路由的Key按照指定的算法進行存放;
1、Hash取模方案
根據(jù)取余分配到不同的表里。要根據(jù)實際情況確認模的大小。此方案由于平均分配,不存在熱點問題,但數(shù)據(jù)遷移很復雜。
2、Range范圍方案
range根據(jù)范圍進行劃分,如日期,大小。此方案不存在數(shù)據(jù)遷移,但存在熱點問題。
四、分庫分表的技術選型
1、技術選型
解決方案主要分為4種:MySQL的分區(qū)技術、NoSql、NewSQL、MySQL的分庫分表。
(1)mysql分區(qū)技術:把一張表存放在不同存儲文件。由于無法負載,使用較少。
(2)NoSQL(如MongoDB):如是訂單等比較重要數(shù)據(jù),強關聯(lián)關系,需約束一致性,不太適應。
(3)NewSql(具有NoSQL對海量數(shù)據(jù)的存儲管理能力,還保持了傳統(tǒng)數(shù)據(jù)庫支持ACID和SQL等特性):如TiDB可滿足需求。
(4)MySQL的分庫分表:如使用mysql,此種方案為主流方式。
2、中間件
解決此類問題的中間件主要為:Proxy模式、Client模式。
(1)Proxy模式
(2)Client模式
把分庫分表相關邏輯存放在客戶端,一版客戶端的應用會引用一個jar,然后再jar中處理SQL組合、數(shù)據(jù)庫路由、執(zhí)行結(jié)果合并等相關功能。
(3)中間件的比較
由于Client模式少了一層,運維方便,相對來說容易些。
五、分庫分表的實踐
根據(jù)容量(當前容量和增長量)評估分庫或分表個數(shù) - 選key(均勻)- 分表規(guī)則(hash或range等)- 執(zhí)行(一般雙寫)- 擴容問題(盡量減少數(shù)據(jù)的移動)。
在這里我們選用中間件share-jdbc。
1、引入maven依賴
2、spring boot規(guī)則配置
行表達式標識符可以使用${...}或$-{...},但前者與Spring本身的屬性文件占位符沖突,因此在Spring環(huán)境中使用行表達式標識符建議使用$-{...}。
3、創(chuàng)建DataSource
通過ShardingDataSourceFactory工廠和規(guī)則配置對象獲取ShardingDataSource,ShardingDataSource實現(xiàn)自JDBC的標準接口DataSource。然后即可通過DataSource選擇使用原生JDBC開發(fā),或者使用JPA, MyBatis等ORM工具。
MySQL單表(innoDB)可以存儲10億級數(shù)據(jù),只是這時候性能比較差,業(yè)界公認MySQL單表容量在1KW以下是最佳狀態(tài),因為這時它的BTREE索引樹高在3~5之間。
參考阿里開發(fā)手冊建議:
1.單表行數(shù)超過 500 萬行或者單表容量超過 2GB,才推薦進行分庫分表;如果預計三年后的數(shù)據(jù)量根本達不到這個級別,請不要在創(chuàng)建表時就分庫分表。
2.實際情況受mysql機器配置等多方面影響,可能數(shù)據(jù)量很大但性能依舊不錯,但考慮后續(xù)發(fā)展一定要進行分庫分表考慮。
根據(jù)實際的業(yè)務場景選擇合適的分片數(shù)據(jù),參考如下:
根據(jù)實際的業(yè)務場景選擇適當?shù)姆制侄?,要達到如下要求:
分表數(shù)量和分表字段確定后,要設計一個合理的分表規(guī)則,良好的分表規(guī)則要達到如下條件:
如何保證分片數(shù)據(jù)均勻,參考:
如何保證方便后續(xù)分片擴容,參考:
如何高效的使用分庫分表,核心是做到盡量的路由到最少的表,最好是只路由到一個表里面
核心規(guī)則如下:
階段一
階段二
階段三
本文鏈接:
分享名稱:mysql怎么做分庫分表 mysql分庫分表實現(xiàn)
本文來源:http://aaarwkj.com/article18/docjpdp.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供App設計、網(wǎng)站策劃、靜態(tài)網(wǎng)站、網(wǎng)頁設計公司、品牌網(wǎng)站建設、商城網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)