淺談mysql數(shù)據(jù)庫分庫分表那些事-億級數(shù)據(jù)存儲方案

mysql分庫分表一般有如下場景

成都創(chuàng)新互聯(lián)公司10多年成都企業(yè)網站定制服務;為您提供網站建設,網站制作,網頁設計及高端網站定制服務,成都企業(yè)網站定制及推廣,對成都三維植被網等多個行業(yè)擁有豐富的網站營銷經驗的網站建設公司。

其中1，2相對較容易實現(xiàn),本文重點講講水平拆表和水平拆庫,以及基于mybatis插件方式實現(xiàn)水平拆分方案落地。

在 《聊一聊擴展字段設計》 一文中有講解到基于KV水平存儲擴展字段方案,這就是非常典型的可以水平分表的場景。主表和kv表是一對N關系,隨著主表數(shù)據(jù)量增長,KV表最大N倍線性增長。

這里我們以分KV表水平拆分為場景

對于kv擴展字段查詢,只會根據(jù)id + key 或者 id 為條件的方式查詢,所以這里我們可以按照id 分片即可

分512張表(實際場景具體分多少表還得根據(jù)字段增加的頻次而定)

分表后表名為kv_000 ~ kv_511

id % 512 = 1 .... 分到 kv_001,

id % 512 = 2 .... 分到 kv_002

依次類推!

水平分表相對比較容易,后面會講到基于mybatis插件實現(xiàn)方案

場景:以下我們基于博客文章表分庫場景來分析

目標:

表結構如下(節(jié)選部分字段):

按照user_id sharding

假如分1024個庫,按照user_id % 1024 hash

user_id % 1024 = 1 分到db_001庫

user_id % 1024 = 2 分到db_002庫

依次類推

目前是2個節(jié)點,假如后期達到瓶頸,我們可以增加至4個節(jié)點

最多可以增加只1024個節(jié)點,性能線性增長

對于水平分表/分庫后,非shardingKey查詢首先得考慮到

基于mybatis分庫分表,一般常用的一種是基于spring AOP方式, 另外一種基于mybatis插件。其實兩種方式思路差不多。

為了比較直觀解決這個問題,我分別在Executor 和StatementHandler階段2個攔截器

實現(xiàn)動態(tài)數(shù)據(jù)源獲取接口

測試結果如下

由此可知,我們需要在Executor階段 切換數(shù)據(jù)源

對于分庫:

原始sql:

目標sql:

其中定義了三個注解

@useMaster 是否強制讀主

@shardingBy 分片標識

@DB 定義邏輯表名 庫名以及分片策略

1)編寫entity

Insert

select

以上順利實現(xiàn)mysql分庫,同樣的道理實現(xiàn)同時分庫分表也很容易實現(xiàn)。

此插件具體實現(xiàn)方案已開源:

目錄如下:

mysql分庫分表,首先得找到瓶頸在哪里(IO or CPU),是分庫還是分表,分多少？不能為了分庫分表而拆分。

原則上是盡量先垂直拆分 后 水平拆分。

以上基于mybatis插件分庫分表是一種實現(xiàn)思路,還有很多不完善的地方,

例如:

如何實現(xiàn)mysql的分庫分表

1,接收到sql;2,把sql放到排隊隊列中 ;3,執(zhí)行sql;4,返回執(zhí)行結果。在這個執(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>

分庫分表技術及技術方案

一、分庫分表的必要性

分庫分表技術的使用，主要是數(shù)據(jù)庫產生了瓶頸，如單庫的并發(fā)訪問或單表的查詢都超出了閾值。對系統(tǒng)使用造成一定的影響，不得已而產生的技術。

通過分庫分表技術來解決此類問題，但正因為使用此技術，會產生ACID一系列的問題，各類中間件解決此類問題各有各的優(yōu)勢。

提示：如場景無必要，千萬不要使用分庫分表。

二、分庫分表的思路

1、垂直區(qū)分

垂直分庫：從業(yè)務角度，一個庫分成多個庫，如把訂單和用戶信息分成兩個庫來存儲。這樣的好處就是可以微服務了。每塊的業(yè)務單獨部署，互不影響，通過接口去調用。

垂直分表：把大表分成多個小表，如熱點數(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í)行結果合并等相關功能。

（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分庫分表怎么分,mysql分庫分表注意哪些
鏈接URL：http://m.rwnh.cn/article10/dscoddo.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網站導航、微信公眾號、網站收錄、網站策劃、云服務器、外貿網站建設

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)