您好,登錄后才能下訂單哦!
這篇文章主要講解了“數(shù)據(jù)庫的分庫分表需要注意什么”,文中的講解內(nèi)容簡(jiǎn)單清晰,易于學(xué)習(xí)與理解,下面請(qǐng)大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“數(shù)據(jù)庫的分庫分表需要注意什么”吧!
切入層次
以下,范圍界定在JAVA和MySQL中。我們首先來看一下分庫分表切入的層次。
① 編碼層
在同一個(gè)項(xiàng)目中創(chuàng)建多個(gè)數(shù)據(jù)源,采用if else的方式,直接根據(jù)條件在代碼中路由。Spring中有動(dòng)態(tài)切換數(shù)據(jù)源的抽象類,具體參見
AbstractRoutingDataSource。
如果項(xiàng)目不是很龐大,使用這種方式能夠快速的進(jìn)行分庫。但缺點(diǎn)也是顯而易見的,需要編寫大量的代碼,照顧到每個(gè)分支。當(dāng)涉及跨庫查詢、聚合,需要循環(huán)計(jì)算結(jié)果并合并的場(chǎng)景,工作量巨大。
如果項(xiàng)目裂變,此類代碼大多不能共用,大多通過拷貝共享。長(zhǎng)此以往,碼將不碼。
② 框架層
這種情況適合公司ORM框架統(tǒng)一的情況,但在很多情況下不太現(xiàn)實(shí)。主要是修改或增強(qiáng)現(xiàn)有ORM框架的功能,在SQL中增加一些自定義原語或者h(yuǎn)int來實(shí)現(xiàn)。
通過實(shí)現(xiàn)一些攔截器(比如Mybatis的Interceptor接口),增加一些自定義解析來控制數(shù)據(jù)的流向,效果雖然較好,但會(huì)改變一些現(xiàn)有的編程經(jīng)驗(yàn)。
很多情況要修改框架源碼,不推薦。
③ 驅(qū)動(dòng)層
基于在編碼層和框架層切入的各種缺點(diǎn),真正的數(shù)據(jù)庫中間件起碼要從驅(qū)動(dòng)層開始。什么意思呢?其實(shí)就是重新編寫了一個(gè)JDBC的驅(qū)動(dòng),在內(nèi)存中維護(hù)一個(gè)路由列表,然后將請(qǐng)求轉(zhuǎn)發(fā)到真正的數(shù)據(jù)庫連接中。
像TDDL、ShardingJDBC等,都是在此層切入。
包括Mysql Connector/J的Failover協(xié)議
(具體指“l(fā)oad balancing”、“replication”、“farbic”等),
也是直接在驅(qū)動(dòng)上進(jìn)行修改。
請(qǐng)求流向一般是這樣的:
④ 代理層
代理層的數(shù)據(jù)庫中間件,將自己偽裝成一個(gè)數(shù)據(jù)庫,接受業(yè)務(wù)端的鏈接。然后負(fù)載業(yè)務(wù)端的請(qǐng)求,解析或者轉(zhuǎn)發(fā)到真正的數(shù)據(jù)庫中。
像MySQL Router、MyCat等,都是在此層切入。
請(qǐng)求流向一般是這樣的:
⑤ 實(shí)現(xiàn)層
SQL特殊版本支持,如Mysql cluster本身就支持各種特性,mariadb galera cluster支持對(duì)等雙主,Greenplum支持分片等。
需要換存儲(chǔ),一般是解決方案,就不在討論之列了。
技術(shù)最終都會(huì)趨于一致,選擇任何一種、都是可行的。但最終選型,受開發(fā)人員熟悉度、社區(qū)活躍度、公司切合度、官方維護(hù)度、擴(kuò)展性,以及公司現(xiàn)有的數(shù)據(jù)庫產(chǎn)品等多方位因素影響。選擇或開發(fā)一款合適的,小伙伴們會(huì)幸福很多。
驅(qū)動(dòng)層和代理層對(duì)比
通過以上層次描述,很明顯,我們選擇或開發(fā)中間件,就集中在驅(qū)動(dòng)層和代理層。在這兩層,能夠?qū)?shù)據(jù)庫連接和路由進(jìn)行更強(qiáng)的控制和更細(xì)致的管理。但它們的區(qū)別也是明顯的。
驅(qū)動(dòng)層特點(diǎn)
僅支持JAVA,支持豐富的DB
驅(qū)動(dòng)層中間件僅支持Java一種開發(fā)語言,但支持所有后端關(guān)系型數(shù)據(jù)庫。如果你的開發(fā)語言固定,后端數(shù)據(jù)源類型豐富,推薦使用此方案。
占用較多的數(shù)據(jù)庫連接
驅(qū)動(dòng)層中間件要維護(hù)很多數(shù)據(jù)庫連接。比如一個(gè)分了10個(gè) 庫 的表,每個(gè)java中的Connection要維護(hù)10個(gè)數(shù)據(jù)庫連接。如果項(xiàng)目過多,則會(huì)出現(xiàn)連接爆炸(我們算一下,如果每個(gè)項(xiàng)目6個(gè)實(shí)例,連接池中minIdle等于5,3個(gè)項(xiàng)目的連接總數(shù)是 10*6*5*3 = 900個(gè))。像Postgres這種每個(gè)連接對(duì)應(yīng)一個(gè)進(jìn)程的數(shù)據(jù)庫,壓力會(huì)很大。
數(shù)據(jù)聚合在業(yè)務(wù)實(shí)例執(zhí)行
數(shù)據(jù)聚合,比如count sum等,是通過多次查詢,然后在業(yè)務(wù)實(shí)例的內(nèi)存中進(jìn)行聚合。
路由表存在于業(yè)務(wù)方實(shí)例內(nèi)存中,通過輪詢或者被動(dòng)通知的途徑更新路由表即可。
集中式管理
所有集群的配置管理都集中在一個(gè)地方,運(yùn)維負(fù)擔(dān)小,DBA即可完成相關(guān)操作。
典型實(shí)現(xiàn)
代理層特點(diǎn)
異構(gòu)支持,DB支持有限
代理層中間件正好相反。僅支持一種后端關(guān)系型數(shù)據(jù)庫,但支持多種開發(fā)語言。如果你的系統(tǒng)是異構(gòu)的,并且都有同樣的SLA要求,則推薦使用此方案。
運(yùn)維負(fù)擔(dān)大
代理層需要維護(hù)數(shù)據(jù)庫連接數(shù)量有限(MySQL Router那種粘性連接除外)。但作為一個(gè)獨(dú)立的服務(wù),既要考慮單獨(dú)部署,又要考慮高可用,會(huì)增加很多額外節(jié)點(diǎn),更別提用了影子節(jié)點(diǎn)的公司了。
另外,代理層是請(qǐng)求唯一的入口,穩(wěn)定性要求極高,一旦有高耗內(nèi)存的聚合查詢把節(jié)點(diǎn)搞崩潰了,都是災(zāi)難性的事故。
典型實(shí)現(xiàn)
共同點(diǎn)
篇幅有限,不做過多討論。訪問各中間件宣傳頁面,能夠看到長(zhǎng)長(zhǎng)的Feature列表,也就是白名單;也能看到長(zhǎng)長(zhǎng)的限制列表,也就是黑名單。限定了你怎么玩,在增強(qiáng)了分布式能力后,分庫分表本身就是一個(gè)閹割的數(shù)據(jù)庫。
使用限制
確保數(shù)據(jù)均衡 拆分?jǐn)?shù)據(jù)庫的數(shù)據(jù)盡量均勻,比如按省份分user庫不均勻,按userid取模會(huì)比較均勻
不用深分頁 不帶切分鍵的深分頁,會(huì)取出所有庫所取頁數(shù)之前的所有數(shù)據(jù)在內(nèi)存排序計(jì)算。容易造成內(nèi)存溢出。
減少子查詢 子查詢會(huì)造成SQL解析紊亂,解析錯(cuò)誤的情況,盡量減少SQL的子查詢。
事務(wù)最小原則 盡量縮小單機(jī)事務(wù)涉及的庫范圍,即盡可能減少夸庫操作,將同類操作的庫/表分在一起
數(shù)據(jù)均衡原則 拆分?jǐn)?shù)據(jù)庫的數(shù)據(jù)盡量均勻,比如按省份分user庫不均勻,按userid取模會(huì)比較均勻
特殊函數(shù) distinct、having、union、in、or等,一般不被支持?;蛘弑恢С郑褂弥髸?huì)增加風(fēng)險(xiǎn),需要改造。
產(chǎn)品
建議聚焦在MyCat和ShardingJDBC上。另外,還有大量其他的中間件,不熟悉建議不要妄動(dòng)。
數(shù)據(jù)庫中間件不好維護(hù),你會(huì)發(fā)現(xiàn)大量半死不活的項(xiàng)目。
以下列表,排名不分先后,有幾個(gè)是只有HA功能,沒有拆分功能的:
Atlas、Kingshard、DBProxy、mysql router、MaxScale、58 Oceanus、ArkProxy、Ctrip DAL、Tsharding、Youtube vitess、網(wǎng)易DDB、Heisenberg、proxysql、Mango、DDAL、Datahekr、MTAtlas、MTDDL、Zebra、Cobar、Cobar
汗、幾乎每個(gè)大廠都有自己的數(shù)據(jù)庫中間件(還發(fā)現(xiàn)了幾個(gè)喜歡拿開源組件加公司前綴作為產(chǎn)品的),只不過不給咱用罷了。
流程解決方案
無論是采用哪個(gè)層面切入進(jìn)行分庫分表,都面臨以下工作過程。
信息收集
統(tǒng)計(jì)影響的業(yè)務(wù)和項(xiàng)目
項(xiàng)目范圍越大,分庫難度越高。有時(shí)候,一句復(fù)雜的SQL能夠涉及四五個(gè)業(yè)務(wù)方,這種SQL都是需要重點(diǎn)關(guān)注的。
確定分庫分表的規(guī)模,是只分其中的幾張表,還是全部涉及。分的越多,工作量越大,幾乎是線性的。
還有一些項(xiàng)目是牽一發(fā)動(dòng)全身的。舉個(gè)例子,下面這個(gè)過程,影響的鏈路就不僅是分庫這么簡(jiǎn)單了。
確定參與人員
除了分庫分表組件的技術(shù)支持人員,最應(yīng)該參與的是對(duì)系統(tǒng)、對(duì)現(xiàn)有代碼最熟悉的幾個(gè)人。只有他們能夠確定哪些SQL該廢棄掉、SQL的影響面等。
確定分庫分表策略
確定分庫分表的維度和切分鍵。切分鍵(就是路由數(shù)據(jù)的column)一旦確定,是不允許修改的,所以在前期架構(gòu)設(shè)計(jì)上,應(yīng)該首先將其確立下來,才能進(jìn)行后續(xù)的工作;數(shù)據(jù)維度多意味著有不同的切分鍵,達(dá)到不同條件查詢的效果。這涉及到數(shù)據(jù)的冗余(多寫、數(shù)據(jù)同步),會(huì)更加復(fù)雜。
前期準(zhǔn)備
數(shù)據(jù)規(guī)整
庫表結(jié)構(gòu)不滿足需求,需要提前規(guī)整。比如,切分鍵的字段名稱不同或者類型各異。在實(shí)施分庫分表策略時(shí),這些個(gè)性會(huì)造成策略過大不好維護(hù)。
掃描所有SQL
將項(xiàng)目中所有的SQL掃描出來,逐個(gè)判斷是否能夠按照切分鍵正常運(yùn)行。
在判斷過程中肯定會(huì)有大量不合規(guī)的SQL,則都需要給出改造方案,這是主要的工作量之一。
驗(yàn)證工具支持
直接在原有項(xiàng)目上進(jìn)行改動(dòng)和驗(yàn)證是可行的,但會(huì)遇到諸多問題,主要是效率太低。我傾向于首先設(shè)計(jì)一些驗(yàn)證工具,輸入要驗(yàn)證的SQL或者列表,然后打印路由信息和結(jié)果進(jìn)行判斷。
技術(shù)準(zhǔn)備
建議以下提到的各個(gè)點(diǎn),都找一個(gè)例子體驗(yàn)一下,然后根據(jù)自己的團(tuán)隊(duì)預(yù)估難度。
以下:
中間件所有不支持的SQL類型
整理容易造成崩潰的注意事項(xiàng)
不支持的SQL給出處理方式
考慮一個(gè)通用的主鍵生成器
考慮沒有切分鍵的SQL如何處理
考慮定時(shí)任務(wù)等掃全庫的如何進(jìn)行遍歷
考慮跨庫跨表查詢?nèi)绾胃脑?/p>
準(zhǔn)備一些工具集
實(shí)施階段
數(shù)據(jù)遷移
分庫分表會(huì)重新影響數(shù)據(jù)的分布,無論是全量還是增量,都會(huì)涉及到數(shù)據(jù)遷移,所以Databus是必要的。
一種理想的狀態(tài)是所有的增刪改都是消息,可以通過訂閱MQ進(jìn)行雙寫。
但一般情況下,仍然需要去模擬這個(gè)狀態(tài),比如使用Canal組件。
怎么保證數(shù)據(jù)安全的切換,我們分其他章節(jié)進(jìn)行討論。
充足的測(cè)試
分庫分表必須經(jīng)過充足的測(cè)試,每一句SQL都要經(jīng)過嚴(yán)格的驗(yàn)證。如果有單元測(cè)試或者自動(dòng)化測(cè)試工具,完全的覆蓋是必要的。一旦有數(shù)據(jù)進(jìn)行了錯(cuò)誤的路由,尤其是增刪改,將會(huì)創(chuàng)造大量的麻煩。
在測(cè)試階段,將驗(yàn)證過程輸出到單獨(dú)的日志文件,充足測(cè)試后review日志文件是否有錯(cuò)誤的數(shù)據(jù)流向。
SQL復(fù)驗(yàn)
強(qiáng)烈建議統(tǒng)一進(jìn)行一次SQL復(fù)驗(yàn)。主要是根據(jù)功能描述,確定SQL的正確性,也就是通常說的review。
演練
在非線上環(huán)境多次對(duì)方案進(jìn)行演練,確保萬無一失。
制定新的SQL規(guī)范
分庫分表以后,項(xiàng)目中的SQL就加了枷鎖,不能夠隨意書寫了。很多平常支持的操作,在拆分環(huán)境下就可能運(yùn)行不了了。所以在上線前,涉及的SQL都應(yīng)該有一個(gè)確認(rèn)過程,即使已經(jīng)經(jīng)過了充足的測(cè)試。
感謝各位的閱讀,以上就是“數(shù)據(jù)庫的分庫分表需要注意什么”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對(duì)數(shù)據(jù)庫的分庫分表需要注意什么這一問題有了更深刻的體會(huì),具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云,小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章,歡迎關(guān)注!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。