mysql實(shí)現(xiàn)數(shù)據(jù)切分的方法-創(chuàng)新互聯(lián)

這篇文章主要介紹了mysql實(shí)現(xiàn)數(shù)據(jù)切分的方法，具有一定借鑒價(jià)值，需要的朋友可以參考下。希望大家閱讀完這篇文章后大有收獲。下面讓小編帶著大家一起了解一下。

十余年的上黨網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開(kāi)發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。網(wǎng)絡(luò)營(yíng)銷(xiāo)推廣的優(yōu)勢(shì)是能夠根據(jù)用戶(hù)設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整上黨建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)公司從事“上黨網(wǎng)站設(shè)計(jì)”,“上黨網(wǎng)站推廣”以來(lái)，每個(gè)客戶(hù)項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

mysql實(shí)現(xiàn)數(shù)據(jù)切分的方法：1、使用數(shù)據(jù)的垂直切分；2、使用數(shù)據(jù)的水平切分；3、利用MySQL Proxy實(shí)現(xiàn)數(shù)據(jù)切分及整合；4、利用Amoeba實(shí)現(xiàn)數(shù)據(jù)切分；5、利用HiveDB實(shí)現(xiàn)數(shù)據(jù)切分及整合。

mysql實(shí)現(xiàn)數(shù)據(jù)切分的方法：

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

簡(jiǎn)單來(lái)說(shuō)，就是指通過(guò)某種特定的條件，將存放在同一個(gè)數(shù)據(jù)庫(kù)中的數(shù)據(jù)分散存放到多個(gè)數(shù)據(jù)庫(kù)（主機(jī)）上面，以達(dá)到分散單臺(tái)設(shè)備負(fù)載的效果。數(shù)據(jù)的切分同時(shí)還可以提高系統(tǒng)的總體可用性，因?yàn)閱闻_(tái)設(shè)備Crash之后，只有總體數(shù)據(jù)的某部分不可用，而不是所有的數(shù)據(jù)。

數(shù)據(jù)的切分（Sharding）根據(jù)其切分規(guī)則的類(lèi)型，可以分為兩種切分模式。一種是按照不同的表（或者Schema）來(lái)切分到不同的數(shù)據(jù)庫(kù)（主機(jī)）之上，這種切分可以稱(chēng)之為數(shù)據(jù)的垂直（縱向）切分；另外一種則是根據(jù)表中數(shù)據(jù)的邏輯關(guān)系，將同一個(gè)表中的數(shù)據(jù)按照某種條件拆分到多臺(tái)數(shù)據(jù)庫(kù)（主機(jī)）上，這種切分稱(chēng)之為數(shù)據(jù)的水平（橫向）切分。

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

水平切分與垂直切分相比，稍微復(fù)雜一些。因?yàn)橐獙⑼粋€(gè)表中的不同數(shù)據(jù)拆分到不同的數(shù)據(jù)庫(kù)中，對(duì)于應(yīng)用程序來(lái)說(shuō)，拆分規(guī)則本身就較根據(jù)表名來(lái)拆分更為復(fù)雜，后期的數(shù)據(jù)維護(hù)也會(huì)更復(fù)雜。

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

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

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

我們先來(lái)看一下，數(shù)據(jù)的垂直切分到底是如何切分的。數(shù)據(jù)的垂直切分，也可以稱(chēng)為縱向切分。將數(shù)據(jù)庫(kù)想象成由很多個(gè)一大塊一大塊的“數(shù)據(jù)塊”（表）組成，垂直地將這些“數(shù)據(jù)塊”切開(kāi)，然后把它們分散到多臺(tái)數(shù)據(jù)庫(kù)主機(jī)上面。這樣的切分方法就是垂直（縱向）的數(shù)據(jù)切分。

一個(gè)架構(gòu)設(shè)計(jì)較好的應(yīng)用系統(tǒng)，其總體功能肯定是由很多個(gè)功能模塊所組成的，而每一個(gè)功能模塊所需要的數(shù)據(jù)對(duì)應(yīng)到數(shù)據(jù)庫(kù)中就是一個(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ù)的垂直切分也就越容易。

功能模塊越清晰，耦合度越低，數(shù)據(jù)垂直切分的規(guī)則定義也就越容易。完全可以根據(jù)功能模塊來(lái)進(jìn)行數(shù)據(jù)的切分，不同功能模塊的數(shù)據(jù)存放于不同的數(shù)據(jù)庫(kù)主機(jī)中，可以很容易就避免跨數(shù)據(jù)庫(kù)的Join存在，同時(shí)系統(tǒng)架構(gòu)也非常清晰。

當(dāng)然，很難有系統(tǒng)能夠做到所有功能模塊使用的表完全獨(dú)立，根本不須要訪(fǎng)問(wèn)對(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ù)庫(kù)中，還是讓?xiě)?yīng)用程序做更多的事情——完全通過(guò)模塊接口取得不同數(shù)據(jù)庫(kù)中的數(shù)據(jù)，然后在程序中完成Join操作。

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

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

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

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

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

• 用戶(hù)模塊表：user,user_profile,user_group,user_photo_album

• 群組討論表：groups,group_message,group_message_content,top_message

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

• 事件信息表：event

初略一看，沒(méi)有哪個(gè)模塊可以脫離其他模塊獨(dú)立存在，模塊與模塊之間都存在著關(guān)系，莫非無(wú)法切分？

當(dāng)然不是，再稍微深入分析一下，可以發(fā)現(xiàn)，雖然各個(gè)模塊所使用的表之間都有關(guān)聯(lián)，但是關(guān)聯(lián)關(guān)系還算清晰，也比較簡(jiǎn)單。

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

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

事件模塊與各個(gè)模塊可能都有關(guān)聯(lián)，但是都只關(guān)注其各個(gè)模塊中對(duì)象的ID信息，同樣比較容易分拆。

所以，第一步可以將數(shù)據(jù)庫(kù)按照功能模塊相關(guān)的表進(jìn)行一次垂直拆分，每個(gè)模塊所涉及的表單獨(dú)分到一個(gè)數(shù)據(jù)庫(kù)中，模塊與模塊之間的表關(guān)聯(lián)在應(yīng)用系統(tǒng)端都通過(guò)接口來(lái)處理。如數(shù)據(jù)垂直切分示意圖（圖1）所示：

通過(guò)這樣的垂直切分之后，之前只能通過(guò)一個(gè)數(shù)據(jù)庫(kù)來(lái)提供的服務(wù)，就被分拆成4個(gè)數(shù)據(jù)庫(kù)來(lái)提供服務(wù)，服務(wù)能力自然是增加幾倍了。

垂直切分的優(yōu)點(diǎn)：

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

• 應(yīng)用程序模塊清晰明確，整合容易；

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

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

• 部分表關(guān)聯(lián)無(wú)法在數(shù)據(jù)庫(kù)級(jí)別完成，要在程序中完成；

• 對(duì)于訪(fǎng)問(wèn)極其頻繁且數(shù)據(jù)量超大的表仍然存在性能瓶頸，不一定能滿(mǎn)足要求；

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

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

• 過(guò)度切分可能會(huì)帶來(lái)系統(tǒng)過(guò)于復(fù)雜而難以維護(hù)。

針對(duì)于垂直切分可能遇到數(shù)據(jù)切分及事務(wù)問(wèn)題，在數(shù)據(jù)庫(kù)層面實(shí)在是很難找到一個(gè)較好的處理方案。實(shí)際應(yīng)用案例中，數(shù)據(jù)庫(kù)的垂直切分大多是與應(yīng)用系統(tǒng)的模塊相對(duì)應(yīng)的，同一個(gè)模塊的數(shù)據(jù)源存放于同一個(gè)數(shù)據(jù)庫(kù)中，可以解決模塊內(nèi)部的數(shù)據(jù)關(guān)聯(lián)問(wèn)題。而模塊與模塊之間，則通過(guò)應(yīng)用程序以服務(wù)接口的方式來(lái)相互提供所需要的數(shù)據(jù)。雖然這樣做在數(shù)據(jù)庫(kù)的總體操作次數(shù)方面確實(shí)會(huì)有所增加，但是在系統(tǒng)整體擴(kuò)展性及架構(gòu)模塊化方面，都是有益的?？赡苣承┎僮鞯膯未雾憫?yīng)的時(shí)間會(huì)稍有增加，但是系統(tǒng)的整體性能很可能反而會(huì)有一定的提升。而擴(kuò)展瓶頸問(wèn)題，就只能依靠下一節(jié)將要介紹的數(shù)據(jù)水平切分架構(gòu)來(lái)解決了。

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

上面一節(jié)分析介紹了數(shù)據(jù)的垂直切分，本節(jié)分析數(shù)據(jù)的水平切分。數(shù)據(jù)的垂直切分基本上可以簡(jiǎn)單地理解為按照表或模塊來(lái)切分?jǐn)?shù)據(jù)，而水平切分則不同。一般來(lái)說(shuō)，簡(jiǎn)單的水平切分主要是將某個(gè)訪(fǎng)問(wèn)極其平凡的表再按照某個(gè)字段的某種規(guī)則分散到多個(gè)表中，每個(gè)表包含一部分?jǐn)?shù)據(jù)。

簡(jiǎn)單來(lái)說(shuō)，可以將數(shù)據(jù)的水平切分理解為按照數(shù)據(jù)行的切分，就是將表中的某些行切分到一個(gè)數(shù)據(jù)庫(kù)，而另外的某些行又切分到其他的數(shù)據(jù)庫(kù)中。當(dāng)然，為了能夠比較容易地判定各行數(shù)據(jù)被切分到哪個(gè)數(shù)據(jù)庫(kù)中了，切分總是須要按照某種特定的規(guī)則來(lái)進(jìn)行的：如根據(jù)某個(gè)數(shù)字類(lèi)型字段基于特定數(shù)目取模，某個(gè)時(shí)間類(lèi)型字段的范圍，或者某個(gè)字符類(lèi)型字段的hash值。如果整個(gè)系統(tǒng)中大部分核心表都可以通過(guò)某個(gè)字段來(lái)進(jìn)行關(guān)聯(lián)，那這個(gè)字段自然是一個(gè)進(jìn)行水平分區(qū)的上上之選了，當(dāng)然，非常特殊無(wú)法使用的情況除外。

一般來(lái)說(shuō)，像現(xiàn)在非常火爆的Web 2.0類(lèi)型網(wǎng)站，基本上大部分?jǐn)?shù)據(jù)都能夠通過(guò)會(huì)員用戶(hù)信息關(guān)聯(lián)上，可能很多核心表都非常適合通過(guò)會(huì)員ID來(lái)進(jìn)行數(shù)據(jù)的水平切分。而像論壇社區(qū)討論系統(tǒng)，就更容易切分了，可以按照論壇編號(hào)來(lái)進(jìn)行水平切分。切分之后基本上不會(huì)出現(xiàn)各個(gè)庫(kù)之間的交互。

如果示例系統(tǒng)的所有數(shù)據(jù)都是和用戶(hù)關(guān)聯(lián)的，那么就可以根據(jù)用戶(hù)來(lái)進(jìn)行水平拆分，將不同用戶(hù)的數(shù)據(jù)切分到不同的數(shù)據(jù)庫(kù)中。當(dāng)然，唯一區(qū)別是用戶(hù)模塊中的groups表和用戶(hù)沒(méi)有直接關(guān)系，所以groups不能根據(jù)用戶(hù)來(lái)進(jìn)行水平拆分。對(duì)于這種特殊情況下的表，完全可以獨(dú)立出來(lái)，放在一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)中。其實(shí)這個(gè)做法可以說(shuō)是利用了前面一節(jié)所介紹的“數(shù)據(jù)的垂直切分”方法，將在下一節(jié)中更為詳細(xì)地介紹這種垂直切分與水平切分同時(shí)使用的聯(lián)合切分方法。

所以，對(duì)于示例數(shù)據(jù)庫(kù)來(lái)說(shuō)，大部分的表都可以根據(jù)用戶(hù)ID來(lái)進(jìn)行水平切分。不同用戶(hù)相關(guān)的數(shù)據(jù)進(jìn)行切分之后存放在不同的數(shù)據(jù)庫(kù)中。如將所有用戶(hù)ID通過(guò)被2取模然后分別存放于兩個(gè)不同的數(shù)據(jù)庫(kù)中。每個(gè)和用戶(hù)ID關(guān)聯(lián)上的表都可以這樣切分。這樣，基本上每個(gè)用戶(hù)相關(guān)的數(shù)據(jù)，都在同一個(gè)數(shù)據(jù)庫(kù)中，即使須要關(guān)聯(lián)，也非常容易實(shí)現(xiàn)。

可以通過(guò)水平切分示意圖（圖2）更為直觀地展示水平切分相關(guān)信息：

水平切分的優(yōu)點(diǎn)：

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

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

• 應(yīng)用程序端整體架構(gòu)改動(dòng)相對(duì)較少；

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

• 只要切分規(guī)則能夠定義好，基本上較難遇到擴(kuò)展性限制。

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

• 切分規(guī)則相對(duì)復(fù)雜，很難抽象出一個(gè)能夠滿(mǎn)足整個(gè)數(shù)據(jù)庫(kù)的切分規(guī)則；

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

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

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

前面兩節(jié)內(nèi)容中，分別了解了“垂直”和“水平”這兩種切分方式的實(shí)現(xiàn)和切分之后的架構(gòu)信息，以及兩種架構(gòu)各自的優(yōu)缺點(diǎn)。但是在實(shí)際的應(yīng)用場(chǎng)景中，除了那些負(fù)載并不是太大、業(yè)務(wù)邏輯也相對(duì)簡(jiǎn)單的系統(tǒng)可以通過(guò)上面兩種切分方法之一來(lái)解決擴(kuò)展性問(wèn)題之外，恐怕其他大部分業(yè)務(wù)邏輯復(fù)雜、系統(tǒng)負(fù)載大的系統(tǒng)，都無(wú)法通過(guò)上面任何一種數(shù)據(jù)的切分方法來(lái)實(shí)現(xiàn)較好的擴(kuò)展性，這就需要將上述兩種切分方法結(jié)合使用，不同的場(chǎng)景使用不同的切分方法。

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

一般來(lái)說(shuō)，數(shù)據(jù)庫(kù)中的所有表很難通過(guò)某一個(gè)（或少數(shù)幾個(gè)）字段全部關(guān)聯(lián)起來(lái)，所以?xún)H僅通過(guò)數(shù)據(jù)的水平切分無(wú)法解決所有問(wèn)題。而垂直切分也只能解決部分問(wèn)題，對(duì)于那些負(fù)載非常高的系統(tǒng)，即使只是單個(gè)表都無(wú)法通過(guò)單臺(tái)數(shù)據(jù)庫(kù)主機(jī)來(lái)承擔(dān)其負(fù)載。必須結(jié)合“垂直”和“水平”兩種切分方式，充分利用兩者的優(yōu)點(diǎn)，避開(kāi)其缺點(diǎn)。

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

此時(shí)該如何抉擇？是再次進(jìn)一步細(xì)分模塊，還是尋求其他的解決辦法？如果我們?cè)傧褡铋_(kāi)始那樣繼續(xù)細(xì)分模塊，進(jìn)行數(shù)據(jù)的垂直切分，那可能在不久的將來(lái)，又會(huì)遇到現(xiàn)在所面臨的同樣問(wèn)題。而且隨著模塊的不斷細(xì)化，應(yīng)用系統(tǒng)的架構(gòu)也會(huì)越來(lái)越復(fù)雜，整個(gè)系統(tǒng)很可能會(huì)出現(xiàn)失控的局面。

這時(shí)候就必須要利用數(shù)據(jù)水平切分的優(yōu)勢(shì)來(lái)解決遇到的問(wèn)題。而且，完全不必在使用數(shù)據(jù)水平切分時(shí)，推倒之前進(jìn)行數(shù)據(jù)垂直切分的成果，而是在其基礎(chǔ)上利用水平切分的優(yōu)勢(shì)來(lái)避開(kāi)垂直切分的弊端，解決系統(tǒng)復(fù)雜性不斷擴(kuò)大的問(wèn)題。而水平拆分的弊端（規(guī)則難以統(tǒng)一）也已經(jīng)被之前的垂直切分解決掉了，讓水平切分可以進(jìn)行得得心應(yīng)手。

對(duì)于示例數(shù)據(jù)庫(kù)，假設(shè)在最開(kāi)始進(jìn)行了數(shù)據(jù)的垂直切分，然而隨著業(yè)務(wù)的不斷增長(zhǎng)，數(shù)據(jù)庫(kù)系統(tǒng)遇到了瓶頸，我們選擇重構(gòu)數(shù)據(jù)庫(kù)集群的架構(gòu)。如何重構(gòu)？考慮到之前已經(jīng)做好了數(shù)據(jù)的垂直切分，而且模塊結(jié)構(gòu)清晰明確，而業(yè)務(wù)增長(zhǎng)的勢(shì)頭越來(lái)越猛，即使現(xiàn)在再次拆分模塊，也堅(jiān)持不了太久。所以選擇了在垂直切分的基礎(chǔ)上再進(jìn)行水平切分。

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

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

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

聯(lián)合切分的優(yōu)點(diǎn)：

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

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

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

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

• 應(yīng)用程序架構(gòu)也更復(fù)雜。

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

通過(guò)前面的章節(jié)，已經(jīng)清楚了通過(guò)數(shù)據(jù)庫(kù)的數(shù)據(jù)切分可以極大地提高系統(tǒng)的擴(kuò)展性。但是，數(shù)據(jù)庫(kù)中的數(shù)據(jù)經(jīng)過(guò)垂直和（或）水平切分被存放在不同的數(shù)據(jù)庫(kù)主機(jī)之后，應(yīng)用系統(tǒng)面臨的大問(wèn)題就是如何讓這些數(shù)據(jù)源得到較好的整合，可能這也是很多讀者非常關(guān)心的一個(gè)問(wèn)題。本節(jié)主要的內(nèi)容就是分析各種可以幫助我們實(shí)現(xiàn)數(shù)據(jù)切分及數(shù)據(jù)整合的整體解決方案。

數(shù)據(jù)的整合很難依靠數(shù)據(jù)庫(kù)本身來(lái)達(dá)到，雖然MySQL存在Federated存儲(chǔ)引擎，可以解決部分類(lèi)似的問(wèn)題，但是在實(shí)際應(yīng)用場(chǎng)景中卻很難較好地運(yùn)用。那該如何來(lái)整合這些分散在各個(gè)MySQL主機(jī)上的數(shù)據(jù)源呢？

總的來(lái)說(shuō)，存在兩種解決思路：

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

通過(guò)中間代理層來(lái)統(tǒng)一管理所有的數(shù)據(jù)源，后端數(shù)據(jù)庫(kù)集群對(duì)前端應(yīng)用程序透明。

可能90％以上的人在面對(duì)這兩種解決思路時(shí)都會(huì)傾向于選擇第二種，尤其是系統(tǒng)不斷龐大復(fù)雜的時(shí)候。確實(shí)，這是一個(gè)非常正確的選擇，雖然短期內(nèi)須要付出的成本可能會(huì)相對(duì)大一些，但對(duì)整個(gè)系統(tǒng)的擴(kuò)展性來(lái)說(shuō)，是非常有幫助的。

所以，對(duì)于第一種解決思路就不過(guò)多分析了，下面重點(diǎn)分析第二種思路中的一些解決方案。

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

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

自行開(kāi)發(fā)中間代理層可以大程度地應(yīng)對(duì)自身應(yīng)用的特點(diǎn)，大化定制個(gè)性化需求，在面對(duì)變化的時(shí)候也可以靈活應(yīng)對(duì)。這應(yīng)該是自行開(kāi)發(fā)代理層大的優(yōu)勢(shì)了。

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

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

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

MySQL Proxy是MySQL官方提供的一個(gè)數(shù)據(jù)庫(kù)代理層產(chǎn)品，和MySQL Server一樣，它也是一個(gè)基于GPL開(kāi)源協(xié)議的開(kāi)源產(chǎn)品?？捎脕?lái)監(jiān)視、分析或傳輸它們之間的通訊信息。它的靈活性允許大限度地使用它，目前具備的功能主要有連接路由、Query分析、Query過(guò)濾和修改、負(fù)載均衡，以及基本的HA機(jī)制等。

實(shí)際上，MySQL Proxy本身并不具有上述所有的功能，而是提供了實(shí)現(xiàn)上述功能的基礎(chǔ)。要實(shí)現(xiàn)這些功能，還須要我們自行編寫(xiě)LUA腳本。

MySQL Proxy實(shí)際上是在客戶(hù)端請(qǐng)求與MySQL Server之間建立了一個(gè)連接池。所有客戶(hù)端請(qǐng)求都發(fā)向MySQL Proxy，然后經(jīng)由MySQL Proxy進(jìn)行相應(yīng)的分析，判斷出是讀操作還是寫(xiě)操作，分發(fā)至對(duì)應(yīng)的MySQL Server上。對(duì)于多節(jié)點(diǎn)Slave集群，也可以起到負(fù)載均衡的效果。如MySQL Proxy基本架構(gòu)圖（圖4）：

通過(guò)上面的架構(gòu)簡(jiǎn)圖，可以清晰地看到MySQL Proxy在實(shí)際應(yīng)用中所處的位置，以及能做的基本事情。MySQL Proxy詳細(xì)的實(shí)施細(xì)則在MySQL官方文檔中有非常詳細(xì)的介紹和示例，感興趣的讀者朋友可以直接從MySQL官方網(wǎng)站免費(fèi)下載或者在線(xiàn)閱讀，這里就不贅述。

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

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

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

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

• 提供數(shù)據(jù)切分規(guī)則并降低數(shù)據(jù)切分規(guī)則給數(shù)據(jù)庫(kù)帶來(lái)的影響；

• 降低數(shù)據(jù)庫(kù)與客戶(hù)端的連接數(shù)；

• 讀寫(xiě)分離路由。

可以看出，Amoeba所做的事情，正好就是通過(guò)數(shù)據(jù)切分來(lái)提升數(shù)據(jù)庫(kù)的擴(kuò)展性所需要的。

Amoeba并不是一個(gè)代理層的Proxy程序，而是一個(gè)開(kāi)發(fā)數(shù)據(jù)庫(kù)代理層Proxy程序的框架，目前基于Amoeba所開(kāi)發(fā)的Proxy程序有Amoeba For MySQL和Amoeba For Aladin兩個(gè)。

Amoeba For MySQL是專(zhuān)門(mén)針對(duì)MySQL數(shù)據(jù)庫(kù)的解決方案，前端應(yīng)用程序請(qǐng)求的協(xié)議及后端連接的數(shù)據(jù)源數(shù)據(jù)庫(kù)都必須是MySQL。對(duì)于客戶(hù)端的任何應(yīng)用程序來(lái)說(shuō)，Amoeba For MySQL和一個(gè)MySQL數(shù)據(jù)庫(kù)沒(méi)有什么區(qū)別，任何使用MySQL協(xié)議的客戶(hù)端請(qǐng)求，都可以被Amoeba For MySQL解析并進(jìn)行相應(yīng)的處理。Amoeba For可以告訴我們Amoeba For MySQL的架構(gòu)信息（出自Amoeba開(kāi)發(fā)者博客）：

Amoeba For Aladin則是一個(gè)適用更為廣泛、功能更為強(qiáng)大的Proxy程序。它可以同時(shí)連接不同數(shù)據(jù)庫(kù)的數(shù)據(jù)源為前端應(yīng)用程序提供服務(wù)，但是僅僅接受符合MySQL協(xié)議的客戶(hù)端應(yīng)用程序請(qǐng)求。也就是說(shuō)，只要前端應(yīng)用程序通過(guò)MySQL協(xié)議連接上來(lái)，Amoeba For Aladin會(huì)自動(dòng)分析Query語(yǔ)句，根據(jù)Query語(yǔ)句中所請(qǐng)求的數(shù)據(jù)來(lái)自動(dòng)識(shí)別出該Query的數(shù)據(jù)源是在什么類(lèi)型數(shù)據(jù)庫(kù)的哪一個(gè)物理主機(jī)上。Amoeba For Aladdin架構(gòu)圖（圖6）展示了Amoeba For Aladin的架構(gòu)細(xì)節(jié)（出自Amoeba開(kāi)發(fā)者博客）。

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

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

但對(duì)于使用MySQL數(shù)據(jù)庫(kù)來(lái)說(shuō)，不論是Amoeba For MySQL還是Amoeba For Aladin都可以很好地使用。當(dāng)然，考慮到任何一個(gè)系統(tǒng)越是復(fù)雜，其性能肯定就會(huì)有一定的損失，維護(hù)成本自然也會(huì)更高一些。所以，在僅僅須要使用MySQL數(shù)據(jù)庫(kù)的時(shí)候，還是建議使用Amoeba For MySQL。

Amoeba For MySQL的使用非常簡(jiǎn)單，所有的配置文件都是標(biāo)準(zhǔn)的XML文件，總共有4個(gè)，分別如下：

• amoeba.xml——主配置文件，配置所有數(shù)據(jù)源及Amoeba自身的參數(shù)；

• rule.xml——配置所有Query路由規(guī)則的信息；

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

• rullFunctionMap.xml——配置路由規(guī)則中需要使用到的特定函數(shù)的實(shí)現(xiàn)類(lèi)。

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

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

和前面的MySQL Proxy及Amoeba一樣，HiveDB同樣是一個(gè)基于Java針對(duì)MySQL數(shù)據(jù)庫(kù)的提供數(shù)據(jù)切分及整合的開(kāi)源框架，只是目前的HiveDB僅僅支持?jǐn)?shù)據(jù)的水平切分。主要解決大數(shù)據(jù)量下數(shù)據(jù)庫(kù)的擴(kuò)展性及數(shù)據(jù)的高性能訪(fǎng)問(wèn)問(wèn)題，同時(shí)支持?jǐn)?shù)據(jù)的冗余及基本的HA機(jī)制。

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

在HiveDB中，通過(guò)用戶(hù)自定義的各種Partition keys（即制定數(shù)據(jù)切分規(guī)則），將數(shù)據(jù)分散到多個(gè)MySQL Server中。訪(fǎng)問(wèn)時(shí)運(yùn)行Query請(qǐng)求，則會(huì)自動(dòng)分析過(guò)濾條件，并行從多個(gè)MySQL Server中讀取數(shù)據(jù)，并合并結(jié)果集返回給客戶(hù)端應(yīng)用程序。

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

HiveDB官方網(wǎng)站上的HiveDB架構(gòu)示意圖（圖7），描述了HiveDB如何來(lái)組織數(shù)據(jù)的基本信息，雖然不能詳細(xì)地表現(xiàn)出架構(gòu)方面的信息，但是也基本可以展示其在數(shù)據(jù)切分上獨(dú)特的一面了。

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

除了上面介紹的幾個(gè)數(shù)據(jù)切分及整合的整體解決方案之外，還存在很多其他的解決方案、如在MySQL Proxy的基礎(chǔ)上做進(jìn)一步擴(kuò)展的HSCALE，通過(guò)Rails構(gòu)建的Spock Proxy，以及基于Pathon的Pyshards，等等。

不管大家選擇使用哪一種解決方案，總體設(shè)計(jì)思路基本上都不應(yīng)該有任何變化，即通過(guò)數(shù)據(jù)的垂直和水平切分，增強(qiáng)數(shù)據(jù)庫(kù)的整體服務(wù)能力，讓?xiě)?yīng)用系統(tǒng)的整體擴(kuò)展能力盡量得到提升，擴(kuò)展方式盡可能便捷。

只要通過(guò)中間層Proxy應(yīng)用程序較好地解決了數(shù)據(jù)切分和數(shù)據(jù)源整合問(wèn)題，那么數(shù)據(jù)庫(kù)的線(xiàn)性擴(kuò)展能力將像應(yīng)用程序一樣方便：只要通過(guò)添加廉價(jià)的PC Server服務(wù)器，即可線(xiàn)性增加數(shù)據(jù)庫(kù)集群的整體服務(wù)能力，讓數(shù)據(jù)庫(kù)不再輕易成為應(yīng)用系統(tǒng)的性能瓶頸。

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

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

在實(shí)施數(shù)據(jù)切分方案之前，仍要分析一些可能存在的問(wèn)題。一般來(lái)說(shuō)，可能遇到的問(wèn)題主要有以下幾點(diǎn)：

• 引入分布式事務(wù)的問(wèn)題；

• 跨節(jié)點(diǎn)Join的問(wèn)題；

• 跨節(jié)點(diǎn)合并排序分頁(yè)問(wèn)題。

• 引入分布式事務(wù)的問(wèn)題

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

在這樣的場(chǎng)景下，如果應(yīng)用程序仍然按照老的方案，那么勢(shì)必須要引入分布式事務(wù)來(lái)解決。而在MySQL各個(gè)版本中，只有從MySQL 5.0開(kāi)始以后的各個(gè)版本才對(duì)分布式事務(wù)提供支持，而且目前僅有Innodb提供分布式事務(wù)支持。不過(guò)，即使我們剛好使用了支持分布式事務(wù)的MySQL版本，同時(shí)也使用Innodb存儲(chǔ)引擎，分布式事務(wù)本身對(duì)于系統(tǒng)資源的消耗就很大，性能也并不太高，引入分布式事務(wù)在異常處理方面會(huì)帶來(lái)很多比較難控制的問(wèn)題。

怎么辦？其實(shí)可以通過(guò)一個(gè)變通的方法來(lái)解決這種問(wèn)題，首先須要考慮的是：數(shù)據(jù)庫(kù)是否是唯一一個(gè)能夠解決事務(wù)的地方？其實(shí)并不是這樣的，完全可以結(jié)合數(shù)據(jù)庫(kù)及應(yīng)用程序來(lái)共同解決。各個(gè)數(shù)據(jù)庫(kù)解決自身的事務(wù)，然后通過(guò)應(yīng)用程序來(lái)控制多個(gè)數(shù)據(jù)庫(kù)上的事務(wù)。

也就是說(shuō)，只要我們?cè)敢猓耆梢詫⒁粋€(gè)跨多個(gè)數(shù)據(jù)庫(kù)的分布式事務(wù)分拆成多個(gè)僅處于單個(gè)數(shù)據(jù)庫(kù)上的小事務(wù)，并通過(guò)應(yīng)用程序來(lái)總控各個(gè)小事務(wù)。當(dāng)然，這樣做要求應(yīng)用程序必須要有足夠的健壯性，當(dāng)然也會(huì)給應(yīng)用程序帶來(lái)一些技術(shù)難度。

跨節(jié)點(diǎn)Join的問(wèn)題

上面介紹了可能引入分布式事務(wù)的問(wèn)題，現(xiàn)在再看看需要跨節(jié)點(diǎn)Join的問(wèn)題。數(shù)據(jù)切分之后，也許有些老的Join語(yǔ)句無(wú)法繼續(xù)使用，因?yàn)镴oin使用的數(shù)據(jù)源可能被切分到多個(gè)MySQL Server中了。

怎么辦？這個(gè)問(wèn)題從MySQL數(shù)據(jù)庫(kù)角度來(lái)看，如果非得在數(shù)據(jù)庫(kù)端直接解決的話(huà)，恐怕只能通過(guò)MySQL一種特殊的存儲(chǔ)引擎Federated處理了。Federated存儲(chǔ)引擎是MySQL解決類(lèi)似于Oracle的DB Link之類(lèi)問(wèn)題的方案。和Oracle DB Link的主要區(qū)別在于，F(xiàn)ederated會(huì)保存一份遠(yuǎn)端表結(jié)構(gòu)的定義信息在本地。乍一看，F(xiàn)ederated確實(shí)是解決跨節(jié)點(diǎn)Join非常好的方案。但是我們還應(yīng)該清楚一點(diǎn)，那就是如果遠(yuǎn)端的表結(jié)構(gòu)發(fā)生了變更，本地的表定義信息是不會(huì)跟著發(fā)生變化的。如果在更新遠(yuǎn)端表結(jié)構(gòu)的時(shí)候并沒(méi)有更新本地的Federated表定義信息，Query運(yùn)行很可能出錯(cuò)，無(wú)法得到正確的結(jié)果。

對(duì)待這類(lèi)問(wèn)題，還是推薦通過(guò)應(yīng)用程序來(lái)處理，先在驅(qū)動(dòng)表所在的MySQL Server中取出驅(qū)動(dòng)結(jié)果集，然后根據(jù)驅(qū)動(dòng)結(jié)果集再到被驅(qū)動(dòng)表所在的MySQL Server中取出相應(yīng)的數(shù)據(jù)?？赡芎芏嘧x者朋友會(huì)認(rèn)為這樣做將對(duì)性能產(chǎn)生一定的影響，是的，確實(shí)會(huì)有一定的負(fù)面影響，但除此之外，基本上沒(méi)有太多其他更好的解決辦法了。而且，由于數(shù)據(jù)庫(kù)通過(guò)較好的擴(kuò)展之后，每臺(tái)MySQL Server的負(fù)載就可以得到較好的控制，單純針對(duì)單條Query來(lái)說(shuō)，其響應(yīng)時(shí)間可能比不切分之前要提高一些，所以性能方面帶來(lái)的負(fù)面影響也并不是太大。更何況，類(lèi)似于這種跨節(jié)點(diǎn)Join的需求也并不是太多，相對(duì)于總體性能而言，可能也只是很小一部分而已。所以為了整體性能，偶爾犧牲一點(diǎn)點(diǎn)，其實(shí)是值得的，畢竟系統(tǒng)優(yōu)化本身就是很多取舍和平衡的過(guò)程。

跨節(jié)點(diǎn)合并排序分頁(yè)問(wèn)題

一旦進(jìn)行了數(shù)據(jù)的水平切分之后，可能就并不只有跨節(jié)點(diǎn)Join無(wú)法正常運(yùn)行，有些排序分頁(yè)的Query語(yǔ)句的數(shù)據(jù)源可能也會(huì)被切分到多個(gè)節(jié)點(diǎn)，其直接后果就是這些排序分頁(yè)Query無(wú)法繼續(xù)正常運(yùn)行。其實(shí)這和跨節(jié)點(diǎn)Join是一個(gè)道理，數(shù)據(jù)源存在于多個(gè)節(jié)點(diǎn)上，要通過(guò)一個(gè)Query來(lái)解決，就是一個(gè)跨節(jié)點(diǎn)Join操作。同樣Federated也可以部分解決，但存在的風(fēng)險(xiǎn)也一樣。但是有一點(diǎn)不同：Join很多時(shí)候都有一個(gè)驅(qū)動(dòng)與被驅(qū)動(dòng)的關(guān)系，所以它涉及的多個(gè)表之間的數(shù)據(jù)讀取一般會(huì)存在一個(gè)順序關(guān)系。但是排序分頁(yè)就不同了，排序分頁(yè)的數(shù)據(jù)源基本上可以說(shuō)是一個(gè)表（或者一個(gè)結(jié)果集），并不存在順序關(guān)系，所以從多個(gè)數(shù)據(jù)源取數(shù)據(jù)的過(guò)程是完全可以并行的。這樣，排序分頁(yè)數(shù)據(jù)的取數(shù)效率可以比跨庫(kù)Join更高，所以帶來(lái)的性能損失相對(duì)要小，在有些情況下可能比在原來(lái)未進(jìn)行數(shù)據(jù)切分的數(shù)據(jù)庫(kù)中效率更高了。當(dāng)然，不論是跨節(jié)點(diǎn)Join還是跨節(jié)點(diǎn)排序分頁(yè)，都會(huì)使應(yīng)用服務(wù)器消耗更多的資源，尤其是內(nèi)存資源，因?yàn)樵谧x取訪(fǎng)問(wèn)及合并結(jié)果集的這個(gè)過(guò)程須要比不處理合并處理更多的數(shù)據(jù)。

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享mysql實(shí)現(xiàn)數(shù)據(jù)切分的方法內(nèi)容對(duì)大家有幫助，同時(shí)也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道，遇到問(wèn)題就找創(chuàng)新互聯(lián)，詳細(xì)的解決方法等著你來(lái)學(xué)習(xí)!

當(dāng)前名稱(chēng)：mysql實(shí)現(xiàn)數(shù)據(jù)切分的方法-創(chuàng)新互聯(lián)
網(wǎng)站路徑：http://muchs.cn/article8/dspoop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供服務(wù)器托管、自適應(yīng)網(wǎng)站、企業(yè)建站、動(dòng)態(tài)網(wǎng)站、品牌網(wǎng)站建設(shè)、定制開(kāi)發(fā)

廣告

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