當(dāng)企業(yè)數(shù)據(jù)達(dá)到一個規(guī)模后，不得不面臨數(shù)據(jù)拆分的問題。使用分布式數(shù)據(jù)庫是一個相對“簡單”的選擇。通過分布式架構(gòu)可以支撐海量規(guī)模，也避免的拆分所帶來的各種“麻煩”。當(dāng)然，分布式數(shù)據(jù)庫也不是“銀彈”，會有其適用的場景。如在分布式數(shù)據(jù)庫下無法解決的話，仍然是需要面臨拆分問題。但如何拆分?jǐn)?shù)據(jù)是一個令人頭疼的問題，除了要結(jié)合業(yè)務(wù)拆分外，具體拆分的粒度也是需要關(guān)注的?？梢栽趯?shí)例級、庫級別、表級別、分區(qū)級進(jìn)行拆分，不同層次的拆分各有其利弊。下文針對不同的拆分方式，進(jìn)行簡單的對比分析。
1、拆分層次：實(shí)例級
在實(shí)例級拆分，即通過將原有數(shù)據(jù)拆分到多個數(shù)據(jù)庫實(shí)例來承載更大規(guī)模。
架構(gòu)
從架構(gòu)角度來看，在實(shí)例級拆分無疑是比較徹底的，通過增加更多地實(shí)例，可以有效增加計算、存儲資源。很多分布式數(shù)據(jù)庫的架構(gòu)，也是采用上層分布式計算層與下層單機(jī)存儲引擎相結(jié)合，原理上就是在架構(gòu)層拆分更多實(shí)例來支撐。每個實(shí)例都承載了一部分?jǐn)?shù)據(jù)，這種情況會在一定程度上增加數(shù)據(jù)耦合，需要全部實(shí)例可用，才能提供完整的數(shù)據(jù)服務(wù)。
研發(fā)
從研發(fā)角度來看，實(shí)例級拆分無疑是很大的變化，從單一數(shù)據(jù)源變?yōu)槎鄠€數(shù)據(jù)源。針對業(yè)務(wù)開發(fā)來說，不得不去解決多數(shù)據(jù)源管理及少量跨實(shí)例的問題。一般可通過自研或引入三方的數(shù)據(jù)庫訪問層來解決問題，減少對開發(fā)的影響。針對數(shù)據(jù)分析類需求，更加建議將數(shù)據(jù)匯聚到AP層進(jìn)行處理。無論是哪方面的調(diào)整，工作量及工作難度都較之前架構(gòu)增大及復(fù)雜很多。
運(yùn)維
從運(yùn)維角度來看，實(shí)例級拆分意味著很多運(yùn)維工作的變化。從資源管理、實(shí)例管理、備份恢復(fù)、系統(tǒng)優(yōu)化等，都要從單實(shí)例變更為多實(shí)例。其劃分為多個實(shí)例后，還需解決部分?jǐn)?shù)據(jù)耦合關(guān)系所帶來的問題。例如，如何實(shí)現(xiàn)跨實(shí)例的一致性備份、如何解決監(jiān)控指標(biāo)的全局匯總等。針對數(shù)據(jù)對象本身的管理，則更為復(fù)雜。前者多通過運(yùn)維平臺來解決多實(shí)例管理帶來的工作量增多等問題；后者則通過數(shù)據(jù)庫中間層可有效解決，針對多實(shí)例從邏輯上視同單一實(shí)例。
安全
從安全角度來看，實(shí)例級拆分無疑是不利的。需要解決多實(shí)例下或者說分散條件下的安全統(tǒng)一管理、訪問能力。通過統(tǒng)一的安全平臺或安全框架是可以在一定程度上解決的。
2、拆分層次：庫級
在庫級拆分，即通過將原有數(shù)據(jù)拆分到多個數(shù)據(jù)庫中。不同數(shù)據(jù)庫叫法不太統(tǒng)一，以MySQL為例就是"show databases"看到的結(jié)果。通常也被稱為不同的Schema。
架構(gòu)
從架構(gòu)角度來看，這種拆分方式只是在邏輯層面的一種拆分，并沒有真實(shí)增加物理資源，因而對計算、存儲的擴(kuò)展上，達(dá)不到什么效果。從數(shù)據(jù)耦合上，還有所增加。這種拆分方式雖然沒有增加資源，但是可為未來的擴(kuò)展打下一定基礎(chǔ)。例如，后續(xù)拆分給到不同實(shí)例，可以簡單將某個Schema拆分出去即可，相對簡化了很多。
研發(fā)
從研發(fā)角度來看，較實(shí)例級拆分要輕些，需要增加對多Schema的支持。必要的多數(shù)據(jù)源管理或部分跨Schema的問題時需要解決的。分析類的需求，可通過跨Schema的關(guān)聯(lián)完成。在工作量上有一定增加，但難度相對不大。通過也可以自研或引入三方的數(shù)據(jù)庫訪問層來解決。
運(yùn)維
從運(yùn)維角度來看，應(yīng)為沒有引入其他實(shí)例，從日常運(yùn)維、備份恢復(fù)等沒什么變化。對于對象管理，是需要考慮多Schema的支持，至于性能上通過拆分Schema是否有提升不確定。使用更小的訪問規(guī)模，也許性能有提升；但由于此而引入更多的關(guān)聯(lián)查詢，可能造成性能下降。
安全
從安全角度來看，這種方式還是會造成一定管理的復(fù)雜度。管理成本的提高跟前面實(shí)例相差不大。
3、拆分層次：表級
表級拆分，是指將原來的單個表，拆成多個分表（表名都發(fā)生變化）。物理上從單個對象拆分為多個對象，邏輯上有時可通過諸如視圖等重新裝飾出一個對象。
架構(gòu)
從架構(gòu)角度來看，這種拆分方式是一種邏輯上的拆分，沒有引入更多資源。從數(shù)據(jù)耦合度看，反而變差了。
研發(fā)
從研發(fā)角度來看，與前面庫級拆分類似，都還存在一定的工作量，但相對難度不大。也多可以通過自研或引入三方數(shù)據(jù)庫訪問層來解決。
運(yùn)維
從運(yùn)維角度來看，與前面庫級拆分也類似，差別不大。
安全
從安全角度來看，與前面庫級拆分也類似，差別不大。
4、拆分層次：分區(qū)級
分區(qū)是數(shù)據(jù)庫層面支持的一種技術(shù)，通過將數(shù)據(jù)劃分在表中的多個分區(qū)，達(dá)到數(shù)據(jù)大而化小的效果。這是一種數(shù)據(jù)庫原生內(nèi)置的優(yōu)化能力，較之前的實(shí)例級、庫級、對象級，更為輕量，且無更多感知。
架構(gòu)
從架構(gòu)角度來看，這種方式?jīng)]有擴(kuò)展現(xiàn)有資源，與拆分前的架構(gòu)幾乎沒有區(qū)別。
研發(fā)
從研發(fā)角度來看，幾乎沒有變化。將數(shù)據(jù)存在分區(qū)中，從業(yè)務(wù)層可做到無感。原有的開發(fā)邏輯，一般都可以正常使用，只是在個別地方可能需要有所調(diào)整。
運(yùn)維
從運(yùn)維角度來看，資源、實(shí)例層面管理沒有變化。差別較大的就是對象管理，分區(qū)級拆分提供更為靈活的管理方式，支持如分區(qū)合并、分裂、交換、清理等能力，可方便對象管理動作。從性能上看，使用分區(qū)后，數(shù)據(jù)庫優(yōu)化器將針對分區(qū)做更多優(yōu)化動作，相對會有不錯的性能提升。當(dāng)然，這里需要注意下，不同數(shù)據(jù)庫在分區(qū)上面的能力差異較大，有些數(shù)據(jù)庫是做的相對不完善，分區(qū)可能存在較多限制。
安全
從安全角度來看，分區(qū)級拆分與拆分前沒有太大變化。
作者介紹
韓鋒，51CTO社區(qū)編輯，CCIA（中國計算機(jī)協(xié)會）常務(wù)理事，前Oracle ACE，騰訊TVP，阿里云MVP，dbaplus等多家社群創(chuàng)始人或?qū)＜覉F(tuán)成員。有著豐富的一線數(shù)據(jù)庫架構(gòu)、軟件研發(fā)、產(chǎn)品設(shè)計、團(tuán)隊(duì)管理經(jīng)驗(yàn)。曾擔(dān)任多家公司首席DBA、數(shù)據(jù)庫架構(gòu)師等職。在云、電商、金融、互聯(lián)網(wǎng)等行業(yè)均有涉獵，精通多種關(guān)系型數(shù)據(jù)庫，對NoSQL及大數(shù)據(jù)相關(guān)技術(shù)也有涉足，實(shí)踐經(jīng)驗(yàn)豐富。曾著有數(shù)據(jù)庫相關(guān)著作《SQL優(yōu)化最佳實(shí)踐》、《數(shù)據(jù)庫高效優(yōu)化》。
