恕我直言，我懷疑你并不會(huì)“分庫(kù)分表”-魔扣目錄

隨著互聯(lián)網(wǎng)的迅速發(fā)展，會(huì)導(dǎo)致產(chǎn)生海量的數(shù)據(jù)，在數(shù)據(jù)量還比較小的時(shí)候，傳統(tǒng)的處理方式是將數(shù)據(jù)存儲(chǔ)在關(guān)系或者非關(guān)系型數(shù)據(jù)庫(kù)中，但是隨著數(shù)據(jù)量逐漸增加，單個(gè)數(shù)據(jù)庫(kù)的表已經(jīng)很難容納所有數(shù)據(jù)，所以業(yè)界出現(xiàn)了分庫(kù)分表的概念。利用分為知之的思想，完美的將數(shù)據(jù)進(jìn)行了拆分，但是也帶來(lái)了許多比較棘手的問(wèn)題，比如引入了分布式事務(wù)、擴(kuò)容等。

數(shù)據(jù)庫(kù)使用演變史

我們?cè)趹?yīng)用中使用數(shù)據(jù)庫(kù)主要經(jīng)歷以下三個(gè)階段

單庫(kù)單表，應(yīng)用初始階段，此階段由于數(shù)據(jù)量小于數(shù)據(jù)庫(kù)承受閾值，對(duì)應(yīng)用性能上基本沒(méi)有影響。
單庫(kù)分表，由于數(shù)據(jù)庫(kù)中的某張表數(shù)據(jù)庫(kù)量過(guò)大，對(duì)應(yīng)用的性能有了一定的影響，比如查詢等，對(duì)某個(gè)表會(huì)分為table_1,table_2,table_N,將一張表拆分N張小表。注意此階段磁盤容量充足。但是更多的是使用的數(shù)據(jù)庫(kù)的分區(qū)，分區(qū)原理和分表原理很相似，比如MySQL hash的分區(qū)

CREATE TABLE `test_user_hash` (
  `user_id` bigint(19) NOT NULL,
  `user_name` varchar(50) NOT NULL,
  `ext_int` int(2) NOT NULL,
  `ts` bigint(19) NOT NULL,
  PRIMARY KEY (`user_id`,`ext_int`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
//Mysql 分區(qū)
ALTER TABLE `test_user_hash` PARTITION BY HASH(ext_int) PARTITIONS 3 ;
復(fù)制代碼

mysql數(shù)據(jù)庫(kù)中存儲(chǔ)形式，由于上述是按3hash求余，所以會(huì)分三個(gè)存儲(chǔ)文件

分庫(kù)分表，上述兩種都無(wú)法解決時(shí)，出現(xiàn)分庫(kù)分表方案，即將單數(shù)據(jù)庫(kù)數(shù)據(jù)分散在多個(gè)數(shù)據(jù)庫(kù)中。

什么情況下需要分庫(kù)分表

? 原則上能不分庫(kù)盡量不分庫(kù)，無(wú)法避免時(shí)或者已經(jīng)有趨勢(shì)顯示需要分庫(kù)分表，則使用分庫(kù)分表。

數(shù)據(jù)庫(kù)的吞吐量達(dá)到瓶頸，需要擴(kuò)多個(gè)數(shù)據(jù)庫(kù)實(shí)例來(lái)提高；
數(shù)據(jù)表的數(shù)據(jù)達(dá)到一定的量級(jí)，對(duì)應(yīng)用查詢等性能有了明顯的影響，可以通過(guò)分庫(kù)分表來(lái)提升性能，有資料顯示Mysql數(shù)據(jù)庫(kù)單表數(shù)據(jù)量超過(guò)5000w后對(duì)查詢性能有影響
為了避免后期復(fù)雜的擴(kuò)容，提前根據(jù)數(shù)據(jù)增長(zhǎng)的趨勢(shì)預(yù)估N年后的數(shù)據(jù)量 count，count / 單庫(kù)容量 =所需數(shù)據(jù)庫(kù)實(shí)例，屬于提前規(guī)劃，防范于未然。

常見(jiàn)拆分方案

常見(jiàn)拆分方案有兩種：垂直拆分和水平拆分，分庫(kù)分表則是一種對(duì)數(shù)據(jù)庫(kù)拆分的常見(jiàn)解決方案。

垂直拆分

垂直拆分是根據(jù)業(yè)務(wù)特點(diǎn)，將某些有關(guān)系的表集中存儲(chǔ)在的某個(gè)DB中，并且這些表的數(shù)據(jù)量一般不會(huì)過(guò)大。比如電商系統(tǒng)中有用戶模塊、訂單模塊

水平拆分

每個(gè)db中存在相同的表結(jié)構(gòu)，根據(jù)一定的規(guī)則將數(shù)據(jù)分散在多個(gè)DB中

分庫(kù)分表實(shí)現(xiàn)方案

主要有以下三種實(shí)現(xiàn)方案

客戶端分片
代理實(shí)現(xiàn)分片
分布式數(shù)據(jù)庫(kù)

客戶端分片

客戶端分片一般有兩種實(shí)現(xiàn)方式，一種是應(yīng)用層直接實(shí)現(xiàn)，應(yīng)用層內(nèi)包含分片邏輯以及分片算法等，與業(yè)務(wù)代碼緊耦合

應(yīng)用層實(shí)現(xiàn)了所有邏輯，業(yè)務(wù)人員需要參與。

另外一種是實(shí)現(xiàn)標(biāo)準(zhǔn)的JDBC協(xié)議，對(duì)應(yīng)用提供包裝過(guò)的JDBC，對(duì)應(yīng)用使用無(wú)感，實(shí)現(xiàn)邏輯作為jar，嵌入在應(yīng)用中，應(yīng)用可以靈活的切換

這種方式是實(shí)現(xiàn)標(biāo)準(zhǔn)的JDBC接口，對(duì)應(yīng)用使用原生JDBC無(wú)影響，二者遵循統(tǒng)一規(guī)范，相比于第一種方式好處是與業(yè)務(wù)代碼解耦。提高靈活性。

代理分片

代理方式實(shí)現(xiàn)的方式是在應(yīng)用和數(shù)據(jù)庫(kù)中間增加代理層，獨(dú)立部署，代理充當(dāng)數(shù)據(jù)的角色，對(duì)應(yīng)用來(lái)說(shuō)使用代理就等價(jià)于數(shù)據(jù)庫(kù)，原則上使用代理與直接使用數(shù)據(jù)庫(kù)是無(wú)區(qū)別，但是代理畢竟不是真實(shí)的數(shù)據(jù)庫(kù)，代理層只是解決如何充分的利用數(shù)據(jù)庫(kù)資源，代理層實(shí)現(xiàn)了所有分庫(kù)分表邏輯，包括分片規(guī)則等，業(yè)務(wù)人員無(wú)需關(guān)注，可以將更多的時(shí)間投入到業(yè)務(wù)實(shí)現(xiàn)邏輯中。

一般會(huì)在代理層外添加一層負(fù)載。

這種方式可以讓業(yè)務(wù)人員更專注于業(yè)務(wù)，但是復(fù)雜度相比第一種要高很多，增加了通訊鏈路，涉及到協(xié)議轉(zhuǎn)換，所以會(huì)對(duì)性能相比于第一種方案有明顯的損耗，同時(shí)對(duì)人員的要求也比較高，需要技術(shù)大牛來(lái)支持，否則一旦出現(xiàn)問(wèn)題很難處理。比較耳熟的有Mycat，由于本人基于Mycat做過(guò)深度二次開(kāi)發(fā)，對(duì)源碼有一定的了解，缺陷真的很。。。。，希望使用者仔細(xì)斟酌，題外話o(￣︶￣)o

分布式數(shù)據(jù)庫(kù)

耳熟的有TiDB，對(duì)外提供可伸縮的架構(gòu)體系，提供一定的分布式事務(wù)，可伸縮和分布式事務(wù)在內(nèi)部實(shí)現(xiàn)中包裝，對(duì)用者無(wú)需直接控制這些特性，比如TiDB提供了JDBC接口，應(yīng)用層使用TiDB和直連MySQL數(shù)據(jù)庫(kù)使用方式?jīng)]什么區(qū)別