mysql數(shù)據(jù)庫切分是什么-創(chuàng)新互聯(lián)

這篇文章主要介紹mysql數(shù)據(jù)庫切分是什么，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

創(chuàng)新互聯(lián)公司主要從事成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)西塞山,十年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220

mysql數(shù)據(jù)庫切分

前言

通過MySQLReplication功能所實(shí)現(xiàn)的擴(kuò)展總是會(huì)受到數(shù)據(jù)庫大小的限制。一旦數(shù)據(jù)庫過于龐大，尤其是當(dāng)寫入過于頻繁，非常難由一臺(tái)主機(jī)支撐的時(shí)候，我們還是會(huì)面臨到擴(kuò)展瓶頸。這時(shí)候，我們就必須許找其它技術(shù)手段來解決這個(gè)瓶頸，那就是我們這一章所要介紹惡的數(shù)據(jù)切分技術(shù)。

何謂數(shù)據(jù)切分

可能非常多讀者朋友在網(wǎng)上或者雜志上面都已經(jīng)多次見到關(guān)于數(shù)據(jù)切分的相關(guān)文章了，僅僅只是在有些文章中稱之為數(shù)據(jù)的Sharding。事實(shí)上無論是稱之為數(shù)據(jù)的Sharding還是數(shù)據(jù)的切分，其概念都是一樣的。

簡(jiǎn)單來說，就是指通過某種特定的條件，將我們存放在同一個(gè)數(shù)據(jù)庫中的數(shù)據(jù)分散存放到多個(gè)數(shù)據(jù)庫（主機(jī)）上面，以達(dá)到分散單臺(tái)設(shè)備負(fù)載的效果。數(shù)據(jù)的切分同一時(shí)候還能夠提高系統(tǒng)的總體可用性，由于單臺(tái)設(shè)備Crash之后。僅僅有總體數(shù)據(jù)的某部分不可用，而不是全部的數(shù)據(jù)。

數(shù)據(jù)的切分（Sharding）依據(jù)其切分規(guī)則的類型。能夠分為兩種切分模式。

一種是依照不同的表（或者Schema）來切分到不同的數(shù)據(jù)庫（主機(jī)）之上，這樣的切能夠稱之為數(shù)據(jù)的垂直（縱向）切分。另外一種則是依據(jù)表中的數(shù)據(jù)的邏輯關(guān)系，將同一個(gè)表中的數(shù)據(jù)依照某種條件拆分到多臺(tái)數(shù)據(jù)庫（主機(jī)）上面。這樣的切分稱之為數(shù)據(jù)的水平（橫向）切分。

垂直切分的大特點(diǎn)就是規(guī)則簡(jiǎn)單，實(shí)施也更為方便，尤其適合各業(yè)務(wù)之間的耦合度非常低。相互影響非常小，業(yè)務(wù)邏輯非常清晰的系統(tǒng)。在這樣的系統(tǒng)中，能夠非常easy做到將不同業(yè)務(wù)模塊所使用的表分拆到不同的數(shù)據(jù)庫中。依據(jù)不同的表來進(jìn)行拆分。對(duì)應(yīng)用程序的影響也更小，拆分規(guī)則也會(huì)比較簡(jiǎn)單清晰。

水平切分于垂直切分相比。相對(duì)來說略微復(fù)雜一些。由于要將同一個(gè)表中的不同數(shù)據(jù)拆分到不同的數(shù)據(jù)庫中，對(duì)于應(yīng)用程序來說，拆分規(guī)則本身就較依據(jù)表名來拆分更為復(fù)雜，后期的數(shù)據(jù)維護(hù)也會(huì)更為復(fù)雜一些。

當(dāng)我們某個(gè)（或者某些）表的數(shù)據(jù)量和訪問量特別的大，通過垂直切分將其放在獨(dú)立的設(shè)備上后仍然無法滿足性能要求，這時(shí)候我們就必須將垂直切分和水平切分相結(jié)合。先垂直切分，然后再水平切分。才干解決這樣的超大型表的性能問題。

以下我們就針對(duì)垂直、水平以及組合切分這三種數(shù)據(jù)切分方式的架構(gòu)實(shí)現(xiàn)及切分后數(shù)據(jù)的整合進(jìn)行對(duì)應(yīng)的分析。

數(shù)據(jù)的垂直切分

我們先來看一下，數(shù)據(jù)的垂直切分究竟是怎樣一個(gè)切分法的。數(shù)據(jù)的垂直切分。也能夠稱之為縱向切分。將數(shù)據(jù)庫想象成為由非常多個(gè)一大塊一大塊的“數(shù)據(jù)塊”（表）組成。我們垂直的將這些“數(shù)據(jù)塊”切開，然后將他們分散到多臺(tái)數(shù)據(jù)庫主機(jī)上面。這樣的切分方法就是一個(gè)垂直（縱向）的數(shù)據(jù)切分。

一個(gè)架構(gòu)設(shè)計(jì)較好的應(yīng)用系統(tǒng)。其總體功能肯定是由非常多個(gè)功能模塊所組成的。而每一個(gè)功能模塊所須要的數(shù)據(jù)對(duì)應(yīng)到數(shù)據(jù)庫中就是一個(gè)或者多個(gè)表。

而在架構(gòu)設(shè)計(jì)中，各個(gè)功能模塊相互之間的交互點(diǎn)越統(tǒng)一越少，系統(tǒng)的耦合度就越低，系統(tǒng)各個(gè)模塊的維護(hù)性以及擴(kuò)展性也就越好。這樣的系統(tǒng)。實(shí)現(xiàn)數(shù)據(jù)的垂直切分也就越easy。

當(dāng)我們的功能模塊越清晰，耦合度越低，數(shù)據(jù)垂直切分的規(guī)則定義也就越easy。全然能夠依據(jù)功能模塊來進(jìn)行數(shù)據(jù)的切分，不同功能模塊的數(shù)據(jù)存放于不同的數(shù)據(jù)庫主機(jī)中，能夠非常easy就避免掉跨數(shù)據(jù)庫的Join存在。同一時(shí)候系統(tǒng)架構(gòu)也非常的清晰。

當(dāng)然。非常難有系統(tǒng)能夠做到全部功能模塊所使用的表全然獨(dú)立，全然不須要訪問對(duì)方的表或者須要兩個(gè)模塊的表進(jìn)行Join操作。這樣的情況下，我們就必須依據(jù)實(shí)際的應(yīng)用場(chǎng)景進(jìn)行評(píng)估權(quán)衡。決定是遷就應(yīng)用程序?qū)㈨氁狫oin的表的相關(guān)某快都存放在同一個(gè)數(shù)據(jù)庫中，還是讓應(yīng)用程序做很多其它的事情，也就是程序全然通過模塊接口取得不同數(shù)據(jù)庫中的數(shù)據(jù)，然后在程序中完畢Join操作。

一般來說。假設(shè)是一個(gè)負(fù)載相對(duì)不是非常大的系統(tǒng)，并且表關(guān)聯(lián)又非常的頻繁。那可能數(shù)據(jù)庫讓步。將幾個(gè)相關(guān)模塊合并在一起降低應(yīng)用程序的工作的方案能夠降低較多的工作量。是一個(gè)可行的方案。

當(dāng)然。通過數(shù)據(jù)庫的讓步，讓多個(gè)模塊集中共用數(shù)據(jù)源，實(shí)際上也是簡(jiǎn)單介紹的默許了各模塊架構(gòu)耦合度增大的發(fā)展，可能會(huì)讓以后的架構(gòu)越來越惡化。尤其是當(dāng)發(fā)展到一定階段之后，發(fā)現(xiàn)數(shù)據(jù)庫實(shí)在無法承擔(dān)這些表所帶來的壓力。不得不面臨再次切分的時(shí)候。所帶來的架構(gòu)改造成本可能會(huì)遠(yuǎn)遠(yuǎn)大于最初的時(shí)候。

所以。在數(shù)據(jù)庫進(jìn)行垂直切分的時(shí)候，怎樣切分，切分到什么樣的程度，是一個(gè)比較考驗(yàn)人的難題。僅僅能在實(shí)際的應(yīng)用場(chǎng)景中通過平衡各方面的成本和收益。才干分析出一個(gè)真正適合自己的拆分方案。

比方在本書所使用演示樣例系統(tǒng)的example數(shù)據(jù)庫，我們簡(jiǎn)單的分析一下。然后再設(shè)計(jì)一個(gè)簡(jiǎn)單的切分規(guī)則，進(jìn)行一次垂直垂直拆分。

系統(tǒng)功能能夠基本分為四個(gè)功能模塊：用戶，群組消息，相冊(cè)以及事件。分別對(duì)應(yīng)為例如以下這些表：

1. 用戶模塊表：user,user_profile,user_group,user_photo_album

2. 群組討論表：groups,group_message,group_message_content,top_message

3. 相冊(cè)相關(guān)表：photo,photo_album,photo_album_relation,photo_comment

4. 事件信息表：event

初略一看，沒有哪一個(gè)模塊能夠脫離其它模塊獨(dú)立存在，模塊與模塊之間都存在著關(guān)系。莫非無法切分？

當(dāng)然不是，我們?cè)俾晕⑸钊敕治鲆幌?，能夠發(fā)現(xiàn)，盡管各個(gè)模塊所使用的表之間都有關(guān)聯(lián)，可是關(guān)聯(lián)關(guān)系還算比較清晰，也比較簡(jiǎn)單。

◆ 群組討論模塊和用戶模塊之間主要存在通過用戶或者是群組關(guān)系來進(jìn)行關(guān)聯(lián)。一般關(guān)聯(lián)的時(shí)候都會(huì)是通過用戶的id或者nick_name以及group的id來進(jìn)行關(guān)聯(lián)。通過模塊之間的接口實(shí)現(xiàn)不會(huì)帶來太多麻煩。

◆ 相冊(cè)模塊僅僅與用戶模塊存在通過用戶的關(guān)聯(lián)。這兩個(gè)模塊之間的關(guān)聯(lián)基本就有通過用戶id關(guān)聯(lián)的內(nèi)容。簡(jiǎn)單清晰，接口明白；

◆ 事件模塊與各個(gè)模塊可能都有關(guān)聯(lián)，可是都僅僅關(guān)注其各個(gè)模塊中對(duì)象的ID信息，相同能夠做到非常easy分拆。

所以。我們第一步能夠?qū)?shù)據(jù)庫依照功能模塊相關(guān)的表進(jìn)行一次垂直拆分。每一個(gè)模塊所涉及的表單獨(dú)到一個(gè)數(shù)據(jù)庫中，模塊與模塊之間的表關(guān)聯(lián)都在應(yīng)用系統(tǒng)端通過藉口來處理。例如以下圖所看到的：

通過這樣的垂直切分之后。之前僅僅能通過一個(gè)數(shù)據(jù)庫來提供的服務(wù)。就被分拆成四個(gè)數(shù)據(jù)庫來提供服務(wù)，服務(wù)能力自然是添加幾倍了。

垂直切分的長(zhǎng)處

◆ 數(shù)據(jù)庫的拆分簡(jiǎn)單明了，拆分規(guī)則明白；

◆ 應(yīng)用程序模塊清晰明白，整合easy。

◆ 數(shù)據(jù)維護(hù)方便易行，easy定位。

垂直切分的缺點(diǎn)

◆ 部分表關(guān)聯(lián)無法在數(shù)據(jù)庫級(jí)別完畢。須要在程序中完畢。

◆ 對(duì)于訪問極其頻繁且數(shù)據(jù)量超大的表仍然存在性能平靜，不一定能滿足要求。

◆ 事務(wù)處理相對(duì)更為復(fù)雜；

◆ 切分達(dá)到一定程度之后，擴(kuò)展性會(huì)遇到限制；

◆ 過讀切分可能會(huì)帶來系統(tǒng)過渡復(fù)雜而難以維護(hù)。

針對(duì)于垂直切分可能遇到數(shù)據(jù)切分及事務(wù)問題，在數(shù)據(jù)庫層面實(shí)在是非常難找到一個(gè)較好的處理方案。實(shí)際應(yīng)用案例中，數(shù)據(jù)庫的垂直切分大多是與應(yīng)用系統(tǒng)的模塊相對(duì)應(yīng)，同一個(gè)模塊的數(shù)據(jù)源存放于同一個(gè)數(shù)據(jù)庫中，能夠解決模塊內(nèi)部的數(shù)據(jù)關(guān)聯(lián)問題。而模塊與模塊之間，則通過應(yīng)用程序以服務(wù)接口方式來相互提供所須要的數(shù)據(jù)。

盡管這樣做在數(shù)據(jù)庫的總體操作次數(shù)方面確實(shí)會(huì)有所添加，可是在系統(tǒng)總體擴(kuò)展性以及架構(gòu)模塊化方面，都是故意的?？赡茉谀承┎僮鞯膯未雾憫?yīng)時(shí)間會(huì)稍有添加?？墒窍到y(tǒng)的總體性能非?？赡芊炊鴷?huì)有一定的提升。而擴(kuò)展瓶頸問題。就僅僅能依靠下一節(jié)將要介紹的數(shù)據(jù)水平切分架構(gòu)來攻克了。

數(shù)據(jù)的水平切分

上面一節(jié)分析介紹了數(shù)據(jù)的垂直切分，這一節(jié)再分析一下數(shù)據(jù)的水平切分。數(shù)據(jù)的垂直切分基本上能夠簡(jiǎn)單的理解為依照表依照模塊來切分?jǐn)?shù)據(jù)，而水平切分就不再是依照表或者是功能模塊來切分了。一般來說，簡(jiǎn)單的水平切分主要是將某個(gè)訪問極其平庸的表再依照某個(gè)字段的某種規(guī)則來分散到多個(gè)表之中。每一個(gè)表中包括一部分?jǐn)?shù)據(jù)。

簡(jiǎn)單來說。我們能夠?qū)?shù)據(jù)的水平切分理解為是依照數(shù)據(jù)行的切分。就是將表中的某些行切分到一個(gè)數(shù)據(jù)庫，而另外的某些行又切分到其它的數(shù)據(jù)庫中。當(dāng)然，為了能夠比較easy的判定各行數(shù)據(jù)被切分到哪個(gè)數(shù)據(jù)庫中了，切分總是都須要依照某種特定的規(guī)則來進(jìn)行的。

如依據(jù)某個(gè)數(shù)字類型字段基于特定數(shù)目取模，某個(gè)時(shí)間類型字段的范圍。或者是某個(gè)字符類型字段的hash值。假設(shè)整個(gè)系統(tǒng)中大部分核心表都能夠通過某個(gè)字段來進(jìn)行關(guān)聯(lián)。那這個(gè)字段自然是一個(gè)進(jìn)行水平分區(qū)的上上之選了，當(dāng)然，非常特殊無法使用就僅僅能另選其它了。

一般來說，像如今互聯(lián)網(wǎng)非?；鸨腤eb2.0類型的站點(diǎn)。基本上大部分?jǐn)?shù)據(jù)都能夠通過會(huì)員用戶信息關(guān)聯(lián)上，可能非常多核心表都非常適合通過會(huì)員ID來進(jìn)行數(shù)據(jù)的水平切分。

而像論壇社區(qū)討論系統(tǒng)。就更easy切分了，非常easy依照論壇編號(hào)來進(jìn)行數(shù)據(jù)的水平切分。

切分之后基本上不會(huì)出現(xiàn)各個(gè)庫之間的交互。

如我們的演示樣例系統(tǒng)。全部數(shù)據(jù)都是和用戶關(guān)聯(lián)的。那么我們就能夠依據(jù)用戶來進(jìn)行水平拆分，將不同用戶的數(shù)據(jù)切分到不同的數(shù)據(jù)庫中。當(dāng)然，唯一有點(diǎn)差別的是用戶模塊中的groups表和用戶沒有直接關(guān)系。所以groups不能依據(jù)用戶來進(jìn)行水平拆分。對(duì)于這樣的特殊情況下的表，我們?nèi)荒軌颡?dú)立出來。單獨(dú)放在一個(gè)獨(dú)立的數(shù)據(jù)庫中。

事實(shí)上這個(gè)做法能夠說是利用了前面一節(jié)所介紹的“數(shù)據(jù)的垂直切分”方法。我將在下一節(jié)中更為具體的介紹這樣的垂直切分與水平切分同一時(shí)候使用的聯(lián)合切分方法。

所以，對(duì)于我們的演示樣例數(shù)據(jù)庫來說，大部分的表都能夠依據(jù)用戶ID來進(jìn)行水平的切分。不同用戶相關(guān)的數(shù)據(jù)進(jìn)行切分之后存放在不同的數(shù)據(jù)庫中。如將全部用戶ID通過2取模然后分別存放于兩個(gè)不同的數(shù)據(jù)庫中。

每一個(gè)和用戶ID關(guān)聯(lián)上的表都能夠這樣切分。這樣，基本上每一個(gè)用戶相關(guān)的數(shù)據(jù)。都在同一個(gè)數(shù)據(jù)庫中，即使是須要關(guān)聯(lián)，也能夠非常簡(jiǎn)單的關(guān)聯(lián)上。

我們能夠通過下圖來更為直觀的展示水平切分相關(guān)信息：水平切分的長(zhǎng)處

◆ 表關(guān)聯(lián)基本能夠在數(shù)據(jù)庫端全部完畢；

◆ 不會(huì)存在某些超大型數(shù)據(jù)量和高負(fù)載的表遇到瓶頸的問題；

◆ 應(yīng)用程序端總體架構(gòu)修改相對(duì)較少；

◆ 事務(wù)處理相對(duì)簡(jiǎn)單；

◆ 僅僅要切分規(guī)則能夠定義好?；旧陷^難遇到擴(kuò)展性限制；

水平切分的缺點(diǎn)

◆ 切分規(guī)則相對(duì)更為復(fù)雜，非常難抽象出一個(gè)能夠滿足整個(gè)數(shù)據(jù)庫的切分規(guī)則；

◆ 后期數(shù)據(jù)的維護(hù)難度有所添加，人為手工定位數(shù)據(jù)更困難；

◆ 應(yīng)用系統(tǒng)各模塊耦合度較高，可能會(huì)對(duì)后面數(shù)據(jù)的遷移拆分造成一定的困難。

垂直與水平切分的聯(lián)合使用

上面兩節(jié)內(nèi)容中。我們分別，了解了“垂直”和“水平”這兩種切分方式的實(shí)現(xiàn)以及切分之后的架構(gòu)信息。同一時(shí)候也分析了兩種架構(gòu)各自的優(yōu)缺點(diǎn)?？墒窃趯?shí)際的應(yīng)用場(chǎng)景中，除了那些負(fù)載并非太大。業(yè)務(wù)邏輯也相對(duì)較簡(jiǎn)單的系統(tǒng)能夠通過上面兩種切分方法之中的一個(gè)來解決擴(kuò)展性問題之外?？峙缕渌蟛糠謽I(yè)務(wù)邏輯略微復(fù)雜一點(diǎn)，系統(tǒng)負(fù)載大一些的系統(tǒng)，都無法通過上面不論什么一種數(shù)據(jù)的切分方法來實(shí)現(xiàn)較好的擴(kuò)展性。而須要將上述兩種切分方法結(jié)合使用，不同的場(chǎng)景使用不同的切分方法。

在這一節(jié)中。我將結(jié)合垂直切分和水平切分各自的優(yōu)缺點(diǎn)，進(jìn)一步完好我們的總體架構(gòu)，讓系統(tǒng)的擴(kuò)展性進(jìn)一步提高。

一般來說。我們數(shù)據(jù)庫中的全部表非常難通過某一個(gè)（或少數(shù)幾個(gè)）字段全部關(guān)聯(lián)起來，所以非常難簡(jiǎn)單的僅僅通過數(shù)據(jù)的水平切分來解決全部問題。而垂直切分也僅僅能解決部分問題，對(duì)于那些負(fù)載非常高的系統(tǒng)，即使僅僅僅僅是單個(gè)表都無法通過單臺(tái)數(shù)據(jù)庫主機(jī)來承擔(dān)其負(fù)載。

我們必須結(jié)合“垂直”和“水平”兩種切分方式同一時(shí)候使用，充分利用兩者的長(zhǎng)處，避開其缺點(diǎn)。

每一個(gè)應(yīng)用系統(tǒng)的負(fù)載都是一步一步增長(zhǎng)上來的，在開始遇到性能瓶頸的時(shí)候，大多數(shù)架構(gòu)師和DBA都會(huì)選擇先進(jìn)行數(shù)據(jù)的垂直拆分，由于這樣的成本最先。最符合這個(gè)時(shí)期所追求的大投入產(chǎn)出比。然而。隨著業(yè)務(wù)的不斷擴(kuò)張。系統(tǒng)負(fù)載的持續(xù)增長(zhǎng)，在系統(tǒng)穩(wěn)定一段時(shí)期之后，經(jīng)過了垂直拆分之后的數(shù)據(jù)庫集群可能又再一次不堪重負(fù)，遇到了性能瓶頸。

這時(shí)候我們?cè)撛鯓泳駬?？是再次進(jìn)一步細(xì)分模塊呢，還是尋求其它的辦法來解決？假設(shè)我們?cè)僖淮蜗褡铋_始那樣繼續(xù)細(xì)分模塊，進(jìn)行數(shù)據(jù)的垂直切分，那我們可能在不久的將來，又會(huì)遇到如今所面對(duì)的相同的問題。并且隨著模塊的不斷的細(xì)化，應(yīng)用系統(tǒng)的架構(gòu)也會(huì)越來越復(fù)雜，整個(gè)系統(tǒng)非?？赡軙?huì)出現(xiàn)失控的局面。

這時(shí)候我們就必須要通過數(shù)據(jù)的水平切分的優(yōu)勢(shì)，來解決這里所遇到的問題。并且，我們?nèi)徊槐匾谑褂脭?shù)據(jù)水平切分的時(shí)候，推倒之前進(jìn)行數(shù)據(jù)垂直切分的成果，而是在其基礎(chǔ)上利用水平切分的優(yōu)勢(shì)來避開垂直切分的弊端。解決系統(tǒng)復(fù)雜性不斷擴(kuò)大的問題。

而水平拆分的弊端（規(guī)則難以統(tǒng)一）也已經(jīng)被之前的垂直切分解決掉了。讓水平拆分能夠進(jìn)行的得心應(yīng)手。

對(duì)于我們的演示樣例數(shù)據(jù)庫。假設(shè)在最開始。我們進(jìn)行了數(shù)據(jù)的垂直切分，然而隨著業(yè)務(wù)的不斷增長(zhǎng)，數(shù)據(jù)庫系統(tǒng)遇到了瓶頸，我們選擇重構(gòu)數(shù)據(jù)庫集群的架構(gòu)。怎樣重構(gòu)？考慮到之前已經(jīng)做好了數(shù)據(jù)的垂直切分，并且模塊結(jié)構(gòu)清晰明白。

而業(yè)務(wù)增長(zhǎng)的勢(shì)頭越來越猛。即使如今進(jìn)一步再次拆分模塊，也堅(jiān)持不了太久。

我們選擇了在垂直切分的基礎(chǔ)上再進(jìn)行水平拆分。

在經(jīng)歷過垂直拆分后的各個(gè)數(shù)據(jù)庫集群中的每一個(gè)都僅僅有一個(gè)功能模塊。而每一個(gè)功能模塊中的全部表基本上都會(huì)與某個(gè)字段進(jìn)行關(guān)聯(lián)。如用戶模塊全部都能夠通過用戶ID進(jìn)行切分，群組討論模塊則都通過群組ID來切分。相冊(cè)模塊則依據(jù)相冊(cè)ID來進(jìn)切分。最后的事件通知信息表考慮到數(shù)據(jù)的時(shí)限性（僅僅僅僅會(huì)訪問近期某個(gè)事件段的信息），則考慮按時(shí)間來切分。

下圖展示了切分后的整個(gè)架構(gòu)：

實(shí)際上，在非常多大型的應(yīng)用系統(tǒng)中，垂直切分和水平切這兩種數(shù)據(jù)的切分方法基本上都是并存的。并且經(jīng)常在不斷的交替進(jìn)行，以不斷的添加系統(tǒng)的擴(kuò)展能力。我們?cè)趹?yīng)對(duì)不同的應(yīng)用場(chǎng)景的時(shí)候，也須要充分考慮到這兩種切分方法各自的局限，以及各自的優(yōu)勢(shì)。在不同的時(shí)期（負(fù)載壓力）使用不同的結(jié)合方式。

聯(lián)合切分的長(zhǎng)處

◆ 能夠充分利用垂直切分和水平切分各自的優(yōu)勢(shì)而避免各自的缺陷；

◆ 讓系統(tǒng)擴(kuò)展性得到大化提升。

聯(lián)合切分的缺點(diǎn)

◆ 數(shù)據(jù)庫系統(tǒng)架構(gòu)比較復(fù)雜。維護(hù)難度更大。

◆ 應(yīng)用程序架構(gòu)也相對(duì)更復(fù)雜；

數(shù)據(jù)切分及整合方案

通過前面的章節(jié)。我們已經(jīng)非常清晰了通過數(shù)據(jù)庫的數(shù)據(jù)切分能夠極大的提高系統(tǒng)的擴(kuò)展性?？墒牵瑪?shù)據(jù)庫中的數(shù)據(jù)在經(jīng)過垂直和（或）水平切分被存放在不同的數(shù)據(jù)庫主機(jī)之后，應(yīng)用系統(tǒng)面臨的大問題就是怎樣來讓這些數(shù)據(jù)源得到較好的整合?？赡苓@也是非常多讀者朋友非常關(guān)心的一個(gè)問題。這一節(jié)我們主要針對(duì)的內(nèi)容就是分析能夠使用的各種能夠幫助我們實(shí)現(xiàn)數(shù)據(jù)切分以及數(shù)據(jù)整合的總體解決方式。

數(shù)據(jù)的整合非常難依靠數(shù)據(jù)庫本身來達(dá)到這個(gè)效果，盡管MySQL存在Federated存儲(chǔ)引擎，能夠解決部分相似的問題?？墒窃趯?shí)際應(yīng)用場(chǎng)景中卻非常難較好的運(yùn)用。那我們?cè)撛鯓觼碚线@些分散在各個(gè)MySQL主機(jī)上面的數(shù)據(jù)源呢？

總的來說，存在兩種解決思路：

1. 在每一個(gè)應(yīng)用程序模塊中配置管理自己須要的一個(gè)（或者多個(gè)）數(shù)據(jù)源。直接訪問各個(gè)數(shù)據(jù)庫，在模塊內(nèi)完畢數(shù)據(jù)的整合；

2. 通過中間代理層來統(tǒng)一管理全部的數(shù)據(jù)源。后端數(shù)據(jù)庫集群對(duì)前端應(yīng)用程序透明；

可能90%以上的人在面對(duì)上面這兩種解決思路的時(shí)候都會(huì)傾向于選擇另外一種，尤其是系統(tǒng)不斷變得龐大復(fù)雜的時(shí)候。

確實(shí)。這是一個(gè)非常正確的選擇，盡管短期內(nèi)須要付出的成本可能會(huì)相對(duì)更大一些，可是對(duì)整個(gè)系統(tǒng)的擴(kuò)展性來說，是非常有幫助的。

所以，對(duì)于第一種解決思路我這里就不準(zhǔn)備過多的分析，以下我重點(diǎn)分析一下在另外一種解決思路中的一些解決方式。

★ 自行開發(fā)中間代理層

在決定選擇通過數(shù)據(jù)庫的中間代理層來解決數(shù)據(jù)源整合的架構(gòu)方向之后，有不少公司（或者企業(yè)）選擇了通過自行開發(fā)符合自身應(yīng)用特定場(chǎng)景的代理層應(yīng)用程序。

通過自行開發(fā)中間代理層能夠大程度的應(yīng)對(duì)自身應(yīng)用的特定。大化的定制非常多個(gè)性化需求，在面對(duì)變化的時(shí)候也能夠靈活的應(yīng)對(duì)。這應(yīng)該說是自行開發(fā)代理層大的優(yōu)勢(shì)了。

當(dāng)然，選擇自行開發(fā)，享受讓個(gè)性化定制大化的樂趣的同一時(shí)候，自然也須要投入很多其它的成本來進(jìn)行前期研發(fā)以及后期的持續(xù)升級(jí)改進(jìn)工作。并且本身的技術(shù)門檻可能也比簡(jiǎn)單的Web應(yīng)用要更高一些。所以，在決定選擇自行開發(fā)之前，還是須要進(jìn)行比較全面的評(píng)估為好。

由于自行開發(fā)很多其它時(shí)候考慮的是怎樣更好的適應(yīng)自身應(yīng)用系統(tǒng)，應(yīng)對(duì)自身的業(yè)務(wù)場(chǎng)景，所以這里也不好分析太多。后面我們主要分析一下當(dāng)前比較流行的幾種數(shù)據(jù)源整合解決方式。

★利用MySQLProxy實(shí)現(xiàn)數(shù)據(jù)切分及整合

MySQLProxy是MySQL官方提供的一個(gè)數(shù)據(jù)庫代理層產(chǎn)品，和MySQLServer一樣，相同是一個(gè)基于GPL開源協(xié)議的開源產(chǎn)品。可用來監(jiān)視、分析或者傳輸他們之間的通訊信息。他的靈活性同意你大限度的使用它，眼下具備的功能主要有連接路由，Query分析，Query過濾和修改，負(fù)載均衡。以及主要的HA機(jī)制等。

實(shí)際上，MySQLProxy本身并不具有上述全部的這些功能。而是提供了實(shí)現(xiàn)上述功能的基礎(chǔ)。

要實(shí)現(xiàn)這些功能，還須要通過我們自行編寫LUA腳本來實(shí)現(xiàn)。

MySQLProxy實(shí)際上是在client請(qǐng)求與MySQLServer之間建立了一個(gè)連接池。全部client請(qǐng)求都是發(fā)向MySQLProxy，然后經(jīng)由MySQLProxy進(jìn)行對(duì)應(yīng)的分析。推斷出是讀操作還是寫操作，分發(fā)至對(duì)應(yīng)的MySQLServer上。對(duì)于多節(jié)點(diǎn)Slave集群，也能夠起做到負(fù)載均衡的效果。以下是MySQLProxy的基本架構(gòu)圖：

通過上面的架構(gòu)簡(jiǎn)圖。我們能夠非常清晰的看出MySQLProxy在實(shí)際應(yīng)用中所處的位置，以及能做的基本事情。

關(guān)于MySQLProxy更為具體的實(shí)施細(xì)則在MySQL官方文檔中有非常具體的介紹和演示樣例。感興趣的讀者朋友能夠直接從MySQL官方站點(diǎn)免費(fèi)下載或者在線閱讀，我這里就不累述浪費(fèi)紙張了。

★利用Amoeba實(shí)現(xiàn)數(shù)據(jù)切分及整合

Amoeba是一個(gè)基于Java開發(fā)的，專注于解決分布式數(shù)據(jù)庫數(shù)據(jù)源整合Proxy程序的開源框架，基于GPL3開源協(xié)議。眼下，Amoeba已經(jīng)具有Query路由，Query過濾，讀寫分離，負(fù)載均衡以及HA機(jī)制等相關(guān)內(nèi)容。

Amoeba 主要解決的以下幾個(gè)問題：

1. 數(shù)據(jù)切分后復(fù)雜數(shù)據(jù)源整合；

2. 提供數(shù)據(jù)切分規(guī)則并降低數(shù)據(jù)切分規(guī)則給數(shù)據(jù)庫帶來的影響。

3. 降低數(shù)據(jù)庫與client的連接數(shù)。

4. 讀寫分離路由；

我們能夠看出，Amoeba所做的事情，正好就是我們通過數(shù)據(jù)切分來提升數(shù)據(jù)庫的擴(kuò)展性所須要的。

Amoeba并非一個(gè)代理層的Proxy程序，而是一個(gè)開發(fā)數(shù)據(jù)庫代理層Proxy程序的開發(fā)框架，眼下基于Amoeba所開發(fā)的Proxy程序有AmoebaForMySQL和AmoebaForAladin兩個(gè)。

AmoebaForMySQL主要是專門針對(duì)MySQL數(shù)據(jù)庫的解決方式，前端應(yīng)用程序請(qǐng)求的協(xié)議以及后端連接的數(shù)據(jù)源數(shù)據(jù)庫都必須是MySQL。對(duì)于client的不論什么應(yīng)用程序來說，AmoebaForMySQL和一個(gè)MySQL數(shù)據(jù)庫沒有什么差別。不論什么使用MySQL協(xié)議的client請(qǐng)求，都能夠被AmoebaForMySQL解析并進(jìn)行對(duì)應(yīng)的處理。下如能夠告訴我們AmoebaForMySQL的架構(gòu)信息（出自Amoeba開發(fā)人員博客）：

AmoebaForAladin則是一個(gè)適用更為廣泛。功能更為強(qiáng)大的Proxy程序。

他能夠同一時(shí)候連接不同數(shù)據(jù)庫的數(shù)據(jù)源為前端應(yīng)用程序提供服務(wù)，可是僅僅接受符合MySQL協(xié)議的client應(yīng)用程序請(qǐng)求。也就是說，僅僅要前端應(yīng)用程序通過MySQL協(xié)議連接上來之后，AmoebaForAladin會(huì)自己主動(dòng)分析Query語句，依據(jù)Query語句中所請(qǐng)求的數(shù)據(jù)來自己主動(dòng)識(shí)別出該所Query的數(shù)據(jù)源是在什么類型數(shù)據(jù)庫的哪一個(gè)物理主機(jī)上面。下圖展示了AmoebaForAladin的架構(gòu)細(xì)節(jié)（出自Amoeba開發(fā)人員博客）：

咋一看，兩者好像全然一樣嘛。細(xì)看之后，才會(huì)發(fā)現(xiàn)兩者主要的差別僅在于通過MySQLProtocalAdapter處理之后。依據(jù)分析結(jié)果推斷出數(shù)據(jù)源數(shù)據(jù)庫。然后選擇特定的JDBC驅(qū)動(dòng)和對(duì)應(yīng)協(xié)議連接后端數(shù)據(jù)庫。

事實(shí)上通過上面兩個(gè)架構(gòu)圖大家可能也已經(jīng)發(fā)現(xiàn)了Amoeba的特點(diǎn)了，他僅僅僅僅是一個(gè)開發(fā)框架。我們除了選擇他已經(jīng)提供的ForMySQL和ForAladin這兩款產(chǎn)品之外。還能夠基于自身的需求進(jìn)行對(duì)應(yīng)的二次開發(fā)。得到更適應(yīng)我們自己應(yīng)用特點(diǎn)的Proxy程序。

當(dāng)對(duì)于使用MySQL數(shù)據(jù)庫來說。不論是AmoebaForMySQL還是AmoebaForAladin都能夠非常好的使用。當(dāng)然，考慮到不論什么一個(gè)系統(tǒng)越是復(fù)雜，其性能肯定就會(huì)有一定的損失，維護(hù)成本自然也會(huì)相對(duì)更高一些。所以，對(duì)于僅僅須要使用MySQL數(shù)據(jù)庫的時(shí)候，我還是建議使用AmoebaForMySQL。

AmoebaForMySQL的使用非常簡(jiǎn)單，全部的配置文件都是標(biāo)準(zhǔn)的XML文件，總共同擁有四個(gè)配置文件。分別為：

◆ amoeba.xml：主配置文件，配置全部數(shù)據(jù)源以及Amoeba自身的參數(shù)設(shè)置。

◆ rule.xml：配置全部Query路由規(guī)則的信息。

◆ functionMap.xml：配置用于解析Query中的函數(shù)所對(duì)應(yīng)的Java實(shí)現(xiàn)類；

◆ rullFunctionMap.xml：配置路由規(guī)則中須要使用到的特定函數(shù)的實(shí)現(xiàn)類；

假設(shè)您的規(guī)則不是太復(fù)雜，基本上僅須要使用到上面四個(gè)配置文件里的前面兩個(gè)就可完畢全部工作。Proxy程序經(jīng)常使用的功能如讀寫分離。負(fù)載均衡等配置都在amoeba.xml中進(jìn)行。此外。Amoeba已經(jīng)支持了實(shí)現(xiàn)數(shù)據(jù)的垂直切分和水平切分的自己主動(dòng)路由。路由規(guī)則能夠在rule.xml進(jìn)行設(shè)置。

眼下Amoeba少有欠缺的主要就是其在線管理功能以及對(duì)事務(wù)的支持了，以前在與相關(guān)開發(fā)人員的溝通過程中提出過相關(guān)的建議，希望能夠提供一個(gè)能夠進(jìn)行在線維護(hù)管理的命令行管理工具，方便在線維護(hù)使用，得到的反饋是管理專門的管理模塊已經(jīng)納入開發(fā)日程了。另外在事務(wù)支持方面臨時(shí)還是Amoeba無法做到的，即使client應(yīng)用在提交給Amoeba的請(qǐng)求是包括事務(wù)信息的，Amoeba也會(huì)忽略事務(wù)相關(guān)信息。當(dāng)然，在經(jīng)過不斷完好之后，我相信事務(wù)支持肯定是Amoeba重點(diǎn)考慮添加的feature。

關(guān)于Amoeba更為具體的用法讀者朋友能夠通過Amoeba開發(fā)人員博客（http://amoeba.sf.net）上面提供的使用手冊(cè)獲取，這里就不再細(xì)述了。

★利用HiveDB實(shí)現(xiàn)數(shù)據(jù)切分及整合

和前面的MySQLProxy以及Amoeba一樣，HiveDB相同是一個(gè)基于Java針對(duì)MySQL數(shù)據(jù)庫的提供數(shù)據(jù)切分及整合的開源框架，僅僅是眼下的HiveDB僅僅支持?jǐn)?shù)據(jù)的水平切分。

主要解決大數(shù)據(jù)量下數(shù)據(jù)庫的擴(kuò)展性及數(shù)據(jù)的高性能訪問問題，同一時(shí)候支持?jǐn)?shù)據(jù)的冗余及主要的HA機(jī)制。

HiveDB的實(shí)現(xiàn)機(jī)制與MySQLProxy和Amoeba有一定的差異，他并非借助MySQL的Replication功能來實(shí)現(xiàn)數(shù)據(jù)的冗余，而是自行實(shí)現(xiàn)了數(shù)據(jù)冗余機(jī)制，而其底層主要是基于HibernateShards來實(shí)現(xiàn)的數(shù)據(jù)切分工作。

在HiveDB中，通過用戶自己定義的各種Partitionkeys（事實(shí)上就是制定數(shù)據(jù)切分規(guī)則），將數(shù)據(jù)分散到多個(gè)MySQLServer中。在訪問的時(shí)候。在執(zhí)行Query請(qǐng)求的時(shí)候。會(huì)自己主動(dòng)分析過濾條件，并行從多個(gè)MySQLServer中讀取數(shù)據(jù)，并合并結(jié)果集返回給client應(yīng)用程序。

單純從功能方面來講，HiveDB可能并不如MySQLProxy和Amoeba那樣強(qiáng)大，可是其數(shù)據(jù)切分的思路與前面二者并無本質(zhì)差異。此外，HiveDB并不僅僅僅僅是一個(gè)開源愛好者所共享的內(nèi)容，而是存在商業(yè)公司支持的開源項(xiàng)目。

以下是HiveDB官方站點(diǎn)上面一章圖片，描寫敘述了HiveDB怎樣來組織數(shù)據(jù)的基本信息，盡管不能具體的表現(xiàn)出太多架構(gòu)方面的信息，可是也基本能夠展示出其在數(shù)據(jù)切分方面獨(dú)特的一面了。

★ mycat 數(shù)據(jù)整合：具體http://www.songwie.com/articlelist/11

★ 其它實(shí)現(xiàn)數(shù)據(jù)切分及整合的解決方式

除了上面介紹的幾個(gè)數(shù)據(jù)切分及整合的總體解決方式之外，還存在非常多其它相同提供了數(shù)據(jù)切分與整合的解決方式。如基于MySQLProxy的基礎(chǔ)上做了進(jìn)一步擴(kuò)展的HSCALE，通過Rails構(gòu)建的SpockProxy。以及基于Pathon的Pyshards等等。

無論大家選擇使用哪一種解決方式，總體設(shè)計(jì)思路基本上都不應(yīng)該會(huì)有不論什么變化。那就是通過數(shù)據(jù)的垂直和水平切分，增強(qiáng)數(shù)據(jù)庫的總體服務(wù)能力，讓應(yīng)用系統(tǒng)的總體擴(kuò)展能力盡可能的提升。擴(kuò)展方式盡可能的便捷。

僅僅要我們通過中間層Proxy應(yīng)用程序較好的攻克了數(shù)據(jù)切分和數(shù)據(jù)源整合問題。那么數(shù)據(jù)庫的線性擴(kuò)展能力將非常easy做到像我們的應(yīng)用程序一樣方便。僅僅須要通過加入便宜的PCServerserver，就可以線性添加數(shù)據(jù)庫集群的總體服務(wù)能力，讓數(shù)據(jù)庫不再輕易成為應(yīng)用系統(tǒng)的性能瓶頸。

數(shù)據(jù)切分與整合可能存在的問題

這里。大家應(yīng)該對(duì)數(shù)據(jù)切分與整合的實(shí)施有了一定的認(rèn)識(shí)了。也許非常多讀者朋友都已經(jīng)依據(jù)各種解決方式各自特性的優(yōu)劣基本選定了適合于自己應(yīng)用場(chǎng)景的方案，后面的工作主要就是實(shí)施準(zhǔn)備了。

在實(shí)施數(shù)據(jù)切分方案之前，有些可能存在的問題我們還是須要做一些分析的。

一般來說，我們可能遇到的問題主要會(huì)有以下幾點(diǎn)：

◆ 引入分布式事務(wù)的問題。

◆ 跨節(jié)點(diǎn)Join的問題；

◆ 跨節(jié)點(diǎn)合并排序分頁問題。

1. 引入分布式事務(wù)的問題

一旦數(shù)據(jù)進(jìn)行切分被分別存放在多個(gè)MySQLServer中之后，無論我們的切分規(guī)則設(shè)計(jì)的多么的完美（實(shí)際上并不存在完美的切分規(guī)則），都可能造成之前的某些事務(wù)所涉及到的數(shù)據(jù)已經(jīng)不在同一個(gè)MySQLServer中了。

在這樣的場(chǎng)景下，假設(shè)我們的應(yīng)用程序仍然依照老的解決方式。那么勢(shì)必須要引入分布式事務(wù)來解決。而在MySQL各個(gè)版本號(hào)中，僅僅有從MySQL5.0開始以后的各個(gè)版本號(hào)才開始對(duì)分布式事務(wù)提供支持，并且眼下僅有Innodb提供分布式事務(wù)支持。不僅如此。即使我們剛好使用了支持分布式事務(wù)的MySQL版本號(hào)。同一時(shí)候也是使用的Innodb存儲(chǔ)引擎，分布式事務(wù)本身對(duì)于系統(tǒng)資源的消耗就是非常大的，性能本身也并非太高。并且引入分布式事務(wù)本身在異常處理方面就會(huì)帶來較多比較難控制的因素。

怎么辦？事實(shí)上我們能夠能夠通過一個(gè)變通的方法來解決這樣的問題。首先須要考慮的一件事情就是：是否數(shù)據(jù)庫是唯一一個(gè)能夠解決事務(wù)的地方呢？事實(shí)上并非這樣的，我們?nèi)荒軌蚪Y(jié)合數(shù)據(jù)庫以及應(yīng)用程序兩者來共同解決。各個(gè)數(shù)據(jù)庫解決自己身上的事務(wù)。然后通過應(yīng)用程序來控制多個(gè)數(shù)據(jù)庫上面的事務(wù)。

也就是說。僅僅要我們?cè)敢?。全然能夠?qū)⒁粋€(gè)跨多個(gè)數(shù)據(jù)庫的分布式事務(wù)分拆成多個(gè)僅處于單個(gè)數(shù)據(jù)庫上面的小事務(wù)。并通過應(yīng)用程序來總控各個(gè)小事務(wù)。

當(dāng)然，這樣作的要求就是我們的俄應(yīng)用程序必須要有足夠的健壯性。當(dāng)然也會(huì)給應(yīng)用程序帶來一些技術(shù)難度。

2.跨節(jié)點(diǎn)Join的問題

上面介紹了可能引入分布式事務(wù)的問題，如今我們?cè)倏纯错氁绻?jié)點(diǎn)Join的問題。

數(shù)據(jù)切分之后。可能會(huì)造成有些老的Join語句無法繼續(xù)使用。由于Join使用的數(shù)據(jù)源可能被切分到多個(gè)MySQLServer中了。

怎么辦？這個(gè)問題從MySQL數(shù)據(jù)庫角度來看，假設(shè)非得在數(shù)據(jù)庫端來直接解決的話，恐怕僅僅能通過MySQL一種特殊的存儲(chǔ)引擎Federated來攻克了。Federated存儲(chǔ)引擎是MySQL解決相似于Oracle的DBLink之類問題的解決方式。

和OracleDBLink的主要差別在于Federated會(huì)保存一份遠(yuǎn)端表結(jié)構(gòu)的定義信息在本地。咋一看，F(xiàn)ederated確實(shí)是解決跨節(jié)點(diǎn)Join非常好的解決方式?？墒俏覀冞€應(yīng)該清晰一點(diǎn)，那就似乎假設(shè)遠(yuǎn)端的表結(jié)構(gòu)發(fā)生了變更，本地的表定義信息是不會(huì)跟著發(fā)生對(duì)應(yīng)變化的。假設(shè)在更新遠(yuǎn)端表結(jié)構(gòu)的時(shí)候并沒有更新本地的Federated表定義信息。就非?？赡茉斐蒕uery執(zhí)行出錯(cuò)，無法得到正確的結(jié)果。

對(duì)待這類問題，我還是推薦通過應(yīng)用程序來進(jìn)行處理，先在驅(qū)動(dòng)表所在的MySQLServer中取出對(duì)應(yīng)的驅(qū)動(dòng)結(jié)果集。然后依據(jù)驅(qū)動(dòng)結(jié)果集再到被驅(qū)動(dòng)表所在的MySQLServer中取出對(duì)應(yīng)的數(shù)據(jù)?？赡芊浅６嘧x者朋友會(huì)覺得這樣做對(duì)性能會(huì)產(chǎn)生一定的影響，是的，確實(shí)是會(huì)對(duì)性能有一定的負(fù)面影響，可是除了此法，基本上沒有太多其它更好的解決的方法了。

并且，由于數(shù)據(jù)庫通過較好的擴(kuò)展之后，每臺(tái)MySQLServer的負(fù)載就能夠得到較好的控制。單純針對(duì)單條Query來說，其響應(yīng)時(shí)間可能比不切分之前要提高一些，所以性能方面所帶來的負(fù)面影響也并非太大。更何況。相似于這樣的須要跨節(jié)點(diǎn)Join的需求也并非太多。相對(duì)于總體性能而言，可能也僅僅是非常小一部分而已。所以為了總體性能的考慮，偶爾犧牲那么一點(diǎn)點(diǎn)。事實(shí)上是值得的。畢竟系統(tǒng)優(yōu)化本身就是存在非常多取舍和平衡的過程。

3. 跨節(jié)點(diǎn)合并排序分頁問題

一旦進(jìn)行了數(shù)據(jù)的水平切分之后，可能就并不僅僅僅僅有跨節(jié)點(diǎn)Join無法正常執(zhí)行，有些排序分頁的Query語句的數(shù)據(jù)源可能也會(huì)被切分到多個(gè)節(jié)點(diǎn)。這樣造成的直接后果就是這些排序分頁Query無法繼續(xù)正常執(zhí)行。事實(shí)上這和跨節(jié)點(diǎn)Join是一個(gè)道理。數(shù)據(jù)源存在于多個(gè)節(jié)點(diǎn)上，要通過一個(gè)Query來解決，就和跨節(jié)點(diǎn)Join是一樣的操作。相同F(xiàn)ederated也能夠部分解決。當(dāng)然存在的風(fēng)險(xiǎn)也一樣。

還是相同的問題，怎么辦？我相同仍然繼續(xù)建議通過應(yīng)用程序來解決。

怎樣解決？解決的思路大體上和跨節(jié)點(diǎn)Join的解決相似，可是有一點(diǎn)和跨節(jié)點(diǎn)Join不太一樣。Join非常多時(shí)候都有一個(gè)驅(qū)動(dòng)與被驅(qū)動(dòng)的關(guān)系。所以Join本身涉及到的多個(gè)表之間的數(shù)據(jù)讀取一般都會(huì)存在一個(gè)順序關(guān)系?？墒桥判蚍猪摼筒惶粯恿?，排序分頁的數(shù)據(jù)源基本上能夠說是一個(gè)表（或者一個(gè)結(jié)果集）。本身并不存在一個(gè)順序關(guān)系，所以在從多個(gè)數(shù)據(jù)源取數(shù)據(jù)的過程是全然能夠并行的。

這樣。排序分頁數(shù)據(jù)的取數(shù)效率我們能夠做的比跨庫Join更高。所以帶來的性能損失相對(duì)的要更小，在有些情況下可能比在原來未進(jìn)行數(shù)據(jù)切分的數(shù)據(jù)庫中效率更高了。

當(dāng)然，不論是跨節(jié)點(diǎn)Join還是跨節(jié)點(diǎn)排序分頁。都會(huì)使我們的應(yīng)用server消耗很多其它的資源，尤其是內(nèi)存資源，由于我們?cè)谧x取訪問以及合并結(jié)果集的這個(gè)過程須要比原來處理很多其它的數(shù)據(jù)。

分析到這里，可能非常多讀者朋友會(huì)發(fā)現(xiàn)，上面全部的這些問題，我給出的建議基本上都是通過應(yīng)用程序來解決。大家可能心里開始犯嘀咕了。是不是由于我是DBA，所以就非常多事情都扔給應(yīng)用架構(gòu)師和開發(fā)人員了？

事實(shí)上全然不是這樣，首先應(yīng)用程序由于其特殊性。能夠非常easy做到非常好的擴(kuò)展性，可是數(shù)據(jù)庫就不一樣。必須借助非常多其它的方式才干做到擴(kuò)展。并且在這個(gè)擴(kuò)展過程中，非常難避免帶來有些原來在集中式數(shù)據(jù)庫中能夠解決但被切分開成一個(gè)數(shù)據(jù)庫集群之后就成為一個(gè)難題的情況。

要想讓系統(tǒng)總體得到大限度的擴(kuò)展，我們僅僅能讓應(yīng)用程序做很多其它的事情。來解決數(shù)據(jù)庫集群無法較好解決的問題。

通過數(shù)據(jù)切分技術(shù)將一個(gè)大的MySQLServer切分成多個(gè)小的MySQLServer，既攻克了寫入性能瓶頸問題，同一時(shí)候也再一次提升了整個(gè)數(shù)據(jù)庫集群的擴(kuò)展性。不論是通過垂直切分，還是水平切分。都能夠讓系統(tǒng)遇到瓶頸的可能性更小。尤其是當(dāng)我們使用垂直和水平相結(jié)合的切分方法之后，理論上將不會(huì)再遇到擴(kuò)展瓶頸了。

以上是mysql數(shù)據(jù)庫切分是什么的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

網(wǎng)頁標(biāo)題：mysql數(shù)據(jù)庫切分是什么-創(chuàng)新互聯(lián)
文章鏈接：http://muchs.cn/article10/posgo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、定制網(wǎng)站、定制開發(fā)、響應(yīng)式網(wǎng)站、網(wǎng)頁設(shè)計(jì)公司

廣告

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