前言

通過MySQLReplication功能所實現的擴充套件總是會受到資料庫大小的限制，一旦資料庫過於龐大，尤其是當寫入過於頻繁，很難由一臺主機支撐的時候，我們還是會面臨到擴充套件瓶頸。這時候，我們就必須許找其他技術手段來解決這個瓶頸，那就是我們這一章所要介紹惡的資料切分技術。

何謂資料切分

可能很多讀者朋友在網上或者雜誌上面都已經多次見到關於資料切分的相關文章了，只不過在有些文章中稱之為資料的Sharding。其實不管是稱之為資料的Sharding還是資料的切分，其概念都是一樣的。簡單來說，就是指通過某種特定的條件，將我們存放在同一個資料庫中的資料分散存放到多個數據庫（主機）上面，以達到分散單臺裝置負載的效果。資料的切分同時還可以提高系統的總體可用性，因為單臺裝置Crash之後，只有總體資料的某部分不可用，而不是所有的資料。

資料的切分（Sharding）根據其切分規則的型別，可以分為兩種切分模式。一種是按照不同的表（或者Schema）來切分到不同的資料庫（主機）之上，這種切可以稱之為資料的垂直（縱向）切分；另外一種則是根據表中的資料的邏輯關係，將同一個表中的資料按照某種條件拆分到多臺資料庫（主機）上面，這種切分稱之為資料的水平（橫向）切分。

垂直切分的最大特點就是規則簡單，實施也更為方便，尤其適合各業務之間的耦合度非常低，相互影響很小，業務邏輯非常清晰的系統。在這種系統中，可以很容易做到將不同業務模組所使用的表分拆到不同的資料庫中。根據不同的表來進行拆分，對應用程式的影響也更小，拆分規則也會比較簡單清晰。

水平切分於垂直切分相比，相對來說稍微複雜一些。因為要將同一個表中的不同資料拆分到不同的資料庫中，對於應用程式來說，拆分規則本身就較根據表名來拆分更為複雜，後期的資料維護也會更為複雜一些。

當我們某個（或者某些）表的資料量和訪問量特別的大，通過垂直切分將其放在獨立的裝置上後仍然無法滿足效能要求，這時候我們就必須將垂直切分和水平切分相結合，先垂直切分，然後再水平切分，才能解決這種超大型表的效能問題。

下面我們就針對垂直、水平以及組合切分這三種資料切分方式的架構實現及切分後資料的整合進行相應的分析。

資料的垂直切分

我們先來看一下，資料的垂直切分到底是如何一個切分法的。資料的垂直切分，也可以稱之為縱向切分。將資料庫想象成為由很多個一大塊一大塊的“資料塊”（表）組成，我們垂直的將這些“資料塊”切開，然後將他們分散到多臺資料庫主機上面。這樣的切分方法就是一個垂直（縱向）的資料切分。

一個架構設計較好的應用系統，其總體功能肯定是由很多個功能模組所組成的，而每一個功能模組所需要的資料對應到資料庫中就是一個或者多個表。而在架構設計中，各個功能模組相互之間的互動點越統一越少，系統的耦合度就越低，系統各個模組的維護性以及擴充套件性也就越好。這樣的系統，實現資料的垂直切分也就越容易。

當我們的功能模組越清晰，耦合度越低，資料垂直切分的規則定義也就越容易。完全可以根據功能模組來進行資料的切分，不同功能模組的資料存放於不同的資料庫主機中，可以很容易就避免掉跨資料庫的Join存在，同時系統架構也非常的清晰。

當然，很難有系統能夠做到所有功能模組所使用的表完全獨立，完全不需要訪問對方的表或者需要兩個模組的表進行Join操作。這種情況下，我們就必須根據實際的應用場景進行評估權衡。決定是遷就應用程式將需要Join的表的相關某快都存放在同一個資料庫中，還是讓應用程式做更多的事情，也就是程式完全通過模組介面取得不同資料庫中的資料，然後在程式中完成Join操作。

一般來說，如果是一個負載相對不是很大的系統，而且表關聯又非常的頻繁，那可能資料庫讓步，將幾個相關模組合併在一起減少應用程式的工作的方案可以減少較多的工作量，是一個可行的方案。

當然，通過資料庫的讓步，讓多個模組集中共用資料來源，實際上也是簡介的默許了各模組架構耦合度增大的發展，可能會讓以後的架構越來越惡化。尤其是當發展到一定階段之後，發現數據庫實在無法承擔這些表所帶來的壓力，不得不面臨再次切分的時候，所帶來的架構改造成本可能會遠遠大於最初的時候。

所以，在資料庫進行垂直切分的時候，如何切分，切分到什麼樣的程度，是一個比較考驗人的難題。只能在實際的應用場景中通過平衡各方面的成本和收益，才能分析出一個真正適合自己的拆分方案。

比如在本書所使用示例系統的example資料庫，我們簡單的分析一下，然後再設計一個簡單的切分規則，進行一次垂直垂直拆分。

系統功能可以基本分為四個功能模組：使用者，群組訊息，相簿以及事件，分別對應為如下這些表：

1. 使用者模組表：user,user_profile,user_group,user_photo_album

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

3. 相簿相關表：photo,photo_album,photo_album_relation,photo_comment

4. 事件資訊表：event

初略一看，沒有哪一個模組可以脫離其他模組獨立存在，模組與模組之間都存在著關係，莫非無法切分？

當然不是，我們再稍微深入分析一下，可以發現，雖然各個模組所使用的表之間都有關聯，但是關聯關係還算比較清晰，也比較簡單。

◆群組討論模組和使用者模組之間主要存在通過使用者或者是群組關係來進行關聯。一般關聯的時候都會是通過使用者的id或者nick_name以及group的id來進行關聯，通過模組之間的介面實現不會帶來太多麻煩；

◆相簿模組僅僅與使用者模組存在通過使用者的關聯。這兩個模組之間的關聯基本就有通過使用者id關聯的內容，簡單清晰，介面明確；

◆ 事件模組與各個模組可能都有關聯，但是都只關注其各個模組中物件的ID資訊，同樣可以做到很容易分拆。

所以，我們第一步可以將資料庫按照功能模組相關的表進行一次垂直拆分，每個模組所涉及的表單獨到一個數據庫中，模組與模組之間的表關聯都在應用系統端通過藉口來處理。如下圖所示：

通過這樣的垂直切分之後，之前只能通過一個數據庫來提供的服務，就被分拆成四個資料庫來提供服務，服務能力自然是增加幾倍了。

垂直切分的優點

◆ 資料庫的拆分簡單明瞭，拆分規則明確；

◆ 應用程式模組清晰明確，整合容易；

◆ 資料維護方便易行，容易定位；

垂直切分的缺點

◆ 部分表關聯無法在資料庫級別完成，需要在程式中完成；

◆ 對於訪問極其頻繁且資料量超大的表仍然存在效能平靜，不一定能滿足要求；

◆ 事務處理相對更為複雜；

◆ 切分達到一定程度之後，擴充套件性會遇到限制；

◆ 過讀切分可能會帶來系統過渡複雜而難以維護。

針對於垂直切分可能遇到資料切分及事務問題，在資料庫層面實在是很難找到一個較好的處理方案。實際應用案例中，資料庫的垂直切分大多是與應用系統的模組相對應，同一個模組的資料來源存放於同一個資料庫中，可以解決模組內部的資料關聯問題。而模組與模組之間，則通過應用程式以服務介面方式來相互提供所需要的資料。雖然這樣做在資料庫的總體操作次數方面確實會有所增加，但是在系統整體擴充套件性以及架構模組化方面，都是有益的。可能在某些操作的單次響應時間會稍有增加，但是系統的整體效能很可能反而會有一定的提升。而擴充套件瓶頸問題，就只能依靠下一節將要介紹的資料水平切分架構來解決了。

資料的水平切分

上面一節分析介紹了資料的垂直切分，這一節再分析一下資料的水平切分。資料的垂直切分基本上可以簡單的理解為按照表按照模組來切分資料，而水平切分就不再是按照表或者是功能模組來切分了。一般來說，簡單的水平切分主要是將某個訪問極其平凡的表再按照某個欄位的某種規則來分散到多個表之中，每個表中包含一部分資料。

簡單來說，我們可以將資料的水平切分理解為是按照資料行的切分，就是將表中的某些行切分到一個數據庫，而另外的某些行又切分到其他的資料庫中。當然，為了能夠比較容易的判定各行資料被切分到哪個資料庫中了，切分總是都需要按照某種特定的規則來進行的。如根據某個數字型別欄位基於特定數目取模，某個時間型別欄位的範圍，或者是某個字元型別欄位的hash值。如果整個系統中大部分核心表都可以通過某個欄位來進行關聯，那這個欄位自然是一個進行水平分割槽的上上之選了，當然，非常特殊無法使用就只能另選其他了。

一般來說，像現在網際網路非常火爆的Web2.0型別的網站，基本上大部分資料都能夠通過會員使用者資訊關聯上，可能很多核心表都非常適合通過會員ID來進行資料的水平切分。而像論壇社群討論系統，就更容易切分了，非常容易按照論壇編號來進行資料的水平切分。切分之後基本上不會出現各個庫之間的互動。

如我們的示例系統，所有資料都是和使用者關聯的，那麼我們就可以根據使用者來進行水平拆分，將不同使用者的資料切分到不同的資料庫中。當然，唯一有點區別的是使用者模組中的groups表和使用者沒有直接關係，所以groups不能根據使用者來進行水平拆分。對於這種特殊情況下的表，我們完全可以獨立出來，單獨放在一個獨立的資料庫中。其實這個做法可以說是利用了前面一節所介紹的“資料的垂直切分”方法，我將在下一節中更為詳細的介紹這種垂直切分與水平切分同時使用的聯合切分方法。

所以，對於我們的示例資料庫來說，大部分的表都可以根據使用者ID來進行水平的切分。不同使用者相關的資料進行切分之後存放在不同的資料庫中。如將所有使用者ID通過2取模然後分別存放於兩個不同的資料庫中。每個和使用者ID關聯上的表都可以這樣切分。這樣，基本上每個使用者相關的資料，都在同一個資料庫中，即使是需要關聯，也可以非常簡單的關聯上。

我們可以通過下圖來更為直觀的展示水平切分相關資訊：水平切分的優點

◆ 表關聯基本能夠在資料庫端全部完成；

◆ 不會存在某些超大型資料量和高負載的表遇到瓶頸的問題；

◆ 應用程式端整體架構改動相對較少；

◆ 事務處理相對簡單；

◆ 只要切分規則能夠定義好，基本上較難遇到擴充套件性限制；

水平切分的缺點

◆ 切分規則相對更為複雜，很難抽象出一個能夠滿足整個資料庫的切分規則；

◆ 後期資料的維護難度有所增加，人為手工定位資料更困難；

◆ 應用系統各模組耦合度較高，可能會對後面資料的遷移拆分造成一定的困難。

垂直與水平切分的聯合使用

上面兩節內容中，我們分別，瞭解了“垂直”和“水平”這兩種切分方式的實現以及切分之後的架構資訊，同時也分析了兩種架構各自的優缺點。但是在實際的應用場景中，除了那些負載並不是太大，業務邏輯也相對較簡單的系統可以通過上面兩種切分方法之一來解決擴充套件性問題之外，恐怕其他大部分業務邏輯稍微複雜一點，系統負載大一些的系統，都無法通過上面任何一種資料的切分方法來實現較好的擴充套件性，而需要將上述兩種切分方法結合使用，不同的場景使用不同的切分方法。

在這一節中，我將結合垂直切分和水平切分各自的優缺點，進一步完善我們的整體架構，讓系統的擴充套件性進一步提高。

一般來說，我們資料庫中的所有表很難通過某一個（或少數幾個）欄位全部關聯起來，所以很難簡單的僅僅通過資料的水平切分來解決所有問題。而垂直切分也只能解決部分問題，對於那些負載非常高的系統，即使僅僅只是單個表都無法通過單臺數據庫主機來承擔其負載。我們必須結合“垂直”和“水平”兩種切分方式同時使用，充分利用兩者的優點，避開其缺點。

每一個應用系統的負載都是一步一步增長上來的，在開始遇到效能瓶頸的時候，大多數架構師和DBA都會選擇先進行資料的垂直拆分，因為這樣的成本最先，最符合這個時期所追求的最大投入產出比。然而，隨著業務的不斷擴張，系統負載的持續增長，在系統穩定一段時期之後，經過了垂直拆分之後的資料庫叢集可能又再一次不堪重負，遇到了效能瓶頸。

這時候我們該如何抉擇？是再次進一步細分模組呢，還是尋求其他的辦法來解決？如果我們再一次像最開始那樣繼續細分模組，進行資料的垂直切分，那我們可能在不久的將來，又會遇到現在所面對的同樣的問題。而且隨著模組的不斷的細化，應用系統的架構也會越來越複雜，整個系統很可能會出現失控的局面。

這時候我們就必須要通過資料的水平切分的優勢，來解決這裡所遇到的問題。而且，我們完全不必要在使用資料水平切分的時候，推倒之前進行資料垂直切分的成果，而是在其基礎上利用水平切分的優勢來避開垂直切分的弊端，解決系統複雜性不斷擴大的問題。而水平拆分的弊端（規則難以統一）也已經被之前的垂直切分解決掉了，讓水平拆分可以進行的得心應手。

對於我們的示例資料庫，假設在最開始，我們進行了資料的垂直切分，然而隨著業務的不斷增長，資料庫系統遇到了瓶頸，我們選擇重構資料庫叢集的架構。如何重構？考慮到之前已經做好了資料的垂直切分，而且模組結構清晰明確。而業務增長的勢頭越來越猛，即使現在進一步再次拆分模組，也堅持不了太久。我們選擇了在垂直切分的基礎上再進行水平拆分。

在經歷過垂直拆分後的各個資料庫叢集中的每一個都只有一個功能模組，而每個功能模組中的所有表基本上都會與某個欄位進行關聯。如使用者模組全部都可以通過使用者ID進行切分，群組討論模組則都通過群組ID來切分，相簿模組則根據相簿ID來進切分，最後的事件通知資訊表考慮到資料的時限性（僅僅只會訪問最近某個事件段的資訊），則考慮按時間來切分。

下圖展示了切分後的整個架構：

實際上，在很多大型的應用系統中，垂直切分和水平切這兩種資料的切分方法基本上都是並存的，而且經常在不斷的交替進行，以不斷的增加系統的擴充套件能力。我們在應對不同的應用場景的時候，也需要充分考慮到這兩種切分方法各自的侷限，以及各自的優勢，在不同的時期（負載壓力）使用不同的結合方式。

聯合切分的優點

◆ 可以充分利用垂直切分和水平切分各自的優勢而避免各自的缺陷；

◆ 讓系統擴充套件性得到最大化提升；

聯合切分的缺點

◆ 資料庫系統架構比較複雜，維護難度更大；

◆ 應用程式架構也相對更復雜；

資料切分及整合方案

通過前面的章節，我們已經很清楚了通過資料庫的資料切分可以極大的提高系統的擴充套件性。但是，資料庫中的資料在經過垂直和（或）水平切分被存放在不同的資料庫主機之後，應用系統面臨的最大問題就是如何來讓這些資料來源得到較好的整合，可能這也是很多讀者朋友非常關心的一個問題。這一節我們主要針對的內容就是分析可以使用的各種可以幫助我們實現資料切分以及資料整合的整體解決方案。

資料的整合很難依靠資料庫本身來達到這個效果，雖然MySQL存在Federated儲存引擎，可以解決部分類似的問題，但是在實際應用場景中卻很難較好的運用。那我們該如何來整合這些分散在各個MySQL主機上面的資料來源呢？

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

1. 在每個應用程式模組中配置管理自己需要的一個（或者多個）資料來源，直接訪問各個資料庫，在模組內完成資料的整合；

2. 通過中間代理層來統一管理所有的資料來源，後端資料庫叢集對前端應用程式透明；

可能90%以上的人在面對上面這兩種解決思路的時候都會傾向於選擇第二種，尤其是系統不斷變得龐大複雜的時候。確實，這是一個非常正確的選擇，雖然短期內需要付出的成本可能會相對更大一些，但是對整個系統的擴充套件性來說，是非常有幫助的。

所以，對於第一種解決思路我這裡就不準備過多的分析，下面我重點分析一下在第二種解決思路中的一些解決方案。

★ 自行開發中間代理層

在決定選擇通過資料庫的中間代理層來解決資料來源整合的架構方向之後，有不少公司（或者企業）選擇了通過自行開發符合自身應用特定場景的代理層應用程式。

通過自行開發中間代理層可以最大程度的應對自身應用的特定，最大化的定製很多個性化需求，在面對變化的時候也可以靈活的應對。這應該說是自行開發代理層最大的優勢了。

當然，選擇自行開發，享受讓個性化定製最大化的樂趣的同時，自然也需要投入更多的成本來進行前期研發以及後期的持續升級改進工作，而且本身的技術門檻可能也比簡單的Web應用要更高一些。所以，在決定選擇自行開發之前，還是需要進行比較全面的評估為好。

由於自行開發更多時候考慮的是如何更好的適應自身應用系統，應對自身的業務場景，所以這裡也不好分析太多。後面我們主要分析一下當前比較流行的幾種資料來源整合解決方案。

★利用MySQLProxy實現資料切分及整合

MySQLProxy是MySQL官方提供的一個數據庫代理層產品，和MySQLServer一樣，同樣是一個基於GPL開源協議的開源產品。可用來監視、分析或者傳輸他們之間的通訊資訊。他的靈活性允許你最大限度的使用它，目前具備的功能主要有連線路由，Query分析，Query過濾和修改，負載均衡，以及基本的HA機制等。

實際上，MySQLProxy本身並不具有上述所有的這些功能，而是提供了實現上述功能的基礎。要實現這些功能，還需要通過我們自行編寫LUA指令碼來實現。

MySQLProxy實際上是在客戶端請求與MySQLServer之間建立了一個連線池。所有客戶端請求都是發向MySQLProxy，然後經由MySQLProxy進行相應的分析，判斷出是讀操作還是寫操作，分發至對應的MySQLServer上。對於多節點Slave叢集，也可以起做到負載均衡的效果。以下是MySQLProxy的基本架構圖：

通過上面的架構簡圖，我們可以很清晰的看出MySQLProxy在實際應用中所處的位置，以及能做的基本事情。關於MySQLProxy更為詳細的實施細則在MySQL官方文件中有非常詳細的介紹和示例，感興趣的讀者朋友可以直接從MySQL官方網站免費下載或者線上閱讀，我這裡就不累述浪費紙張了。

★利用Amoeba實現資料切分及整合

Amoeba是一個基於Java開發的，專注於解決分散式資料庫資料來源整合Proxy程式的開源框架，基於GPL3開源協議。目前，Amoeba已經具有Query路由，Query過濾，讀寫分離，負載均衡以及HA機制等相關內容。

Amoeba 主要解決的以下幾個問題：

1. 資料切分後複雜資料來源整合；

2. 提供資料切分規則並降低資料切分規則給資料庫帶來的影響；

3. 降低資料庫與客戶端的連線數；

4. 讀寫分離路由；

我們可以看出，Amoeba所做的事情，正好就是我們通過資料切分來提升資料庫的擴充套件性所需要的。

Amoeba並不是一個代理層的Proxy程式，而是一個開發資料庫代理層Proxy程式的開發框架，目前基於Amoeba所開發的Proxy程式有AmoebaForMySQL和AmoebaForAladin兩個。

AmoebaForMySQL主要是專門針對MySQL資料庫的解決方案，前端應用程式請求的協議以及後端連線的資料來源資料庫都必須是MySQL。對於客戶端的任何應用程式來說，AmoebaForMySQL和一個MySQL資料庫沒有什麼區別，任何使用MySQL協議的客戶端請求，都可以被AmoebaForMySQL解析並進行相應的處理。下如可以告訴我們AmoebaForMySQL的架構資訊（出自Amoeba開發者部落格）：

AmoebaForAladin則是一個適用更為廣泛，功能更為強大的Proxy程式。他可以同時連線不同資料庫的資料來源為前端應用程式提供服務，但是僅僅接受符合MySQL協議的客戶端應用程式請求。也就是說，只要前端應用程式通過MySQL協議連線上來之後，AmoebaForAladin會自動分析Query語句，根據Query語句中所請求的資料來自動識別出該所Query的資料來源是在什麼型別資料庫的哪一個物理主機上面。下圖展示了AmoebaForAladin的架構細節（出自Amoeba開發者部落格）：

咋一看，兩者好像完全一樣嘛。細看之後，才會發現兩者主要的區別僅在於通過MySQLProtocalAdapter處理之後，根據分析結果判斷出資料來源資料庫，然後選擇特定的JDBC驅動和相應協議連線後端資料庫。

其實通過上面兩個架構圖大家可能也已經發現了Amoeba的特點了，他僅僅只是一個開發框架，我們除了選擇他已經提供的ForMySQL和ForAladin這兩款產品之外，還可以基於自身的需求進行相應的二次開發，得到更適應我們自己應用特點的Proxy程式。

當對於使用MySQL資料庫來說，不論是AmoebaForMySQL還是AmoebaForAladin都可以很好的使用。當然，考慮到任何一個系統越是複雜，其效能肯定就會有一定的損失，維護成本自然也會相對更高一些。所以，對於僅僅需要使用MySQL資料庫的時候，我還是建議使用AmoebaForMySQL。

AmoebaForMySQL的使用非常簡單，所有的配置檔案都是標準的XML檔案，總共有四個配置檔案。分別為：

◆amoeba.xml：主配置檔案，配置所有資料來源以及Amoeba自身的引數設定；

◆rule.xml：配置所有Query路由規則的資訊；

◆functionMap.xml：配置用於解析Query中的函式所對應的Java實現類；

◆ rullFunctionMap.xml：配置路由規則中需要使用到的特定函式的實現類；

如果您的規則不是太複雜，基本上僅需要使用到上面四個配置檔案中的前面兩個就可完成所有工作。Proxy程式常用的功能如讀寫分離，負載均衡等配置都在amoeba.xml中進行。此外，Amoeba已經支援了實現資料的垂直切分和水平切分的自動路由，路由規則可以在rule.xml進行設定。

目前Amoeba少有欠缺的主要就是其線上管理功能以及對事務的支援了，曾經在與相關開發者的溝通過程中提出過相關的建議，希望能夠提供一個可以進行線上維護管理的命令列管理工具，方便線上維護使用，得到的反饋是管理專門的管理模組已經納入開發日程了。另外在事務支援方面暫時還是Amoeba無法做到的，即使客戶端應用在提交給Amoeba的請求是包含事務資訊的，Amoeba也會忽略事務相關資訊。當然，在經過不斷完善之後，我相信事務支援肯定是Amoeba重點考慮增加的feature。

關於Amoeba更為詳細的使用方法讀者朋友可以通過Amoeba開發者部落格（http://amoeba.sf.net）上面提供的使用手冊獲取，這裡就不再細述了。

★利用HiveDB實現資料切分及整合

和前面的MySQLProxy以及Amoeba一樣，HiveDB同樣是一個基於Java針對MySQL資料庫的提供資料切分及整合的開源框架，只是目前的HiveDB僅僅支援資料的水平切分。主要解決大資料量下資料庫的擴充套件性及資料的高效能訪問問題，同時支援資料的冗餘及基本的HA機制。

HiveDB的實現機制與MySQLProxy和Amoeba有一定的差異，他並不是藉助MySQL的Replication功能來實現資料的冗餘，而是自行實現了資料冗餘機制，而其底層主要是基於HibernateShards來實現的資料切分工作。

在HiveDB中，通過使用者自定義的各種Partitionkeys（其實就是制定資料切分規則），將資料分散到多個MySQLServer中。在訪問的時候，在執行Query請求的時候，會自動分析過濾條件，並行從多個MySQLServer中讀取資料，併合並結果集返回給客戶端應用程式。

單純從功能方面來講，HiveDB可能並不如MySQLProxy和Amoeba那樣強大，但是其資料切分的思路與前面二者並無本質差異。此外，HiveDB並不僅僅只是一個開源愛好者所共享的內容，而是存在商業公司支援的開源專案。

下面是HiveDB官方網站上面一章圖片，描述了HiveDB如何來組織資料的基本資訊，雖然不能詳細的表現出太多架構方面的資訊，但是也基本可以展示出其在資料切分方面獨特的一面了。

★ 其他實現資料切分及整合的解決方案

除了上面介紹的幾個資料切分及整合的整體解決方案之外，還存在很多其他同樣提供了資料切分與整合的解決方案。如基於MySQLProxy的基礎上做了進一步擴充套件的HSCALE，通過Rails構建的SpockProxy，以及基於Pathon的Pyshards等等。

不管大家選擇使用哪一種解決方案，總體設計思路基本上都不應該會有任何變化，那就是通過資料的垂直和水平切分，增強資料庫的整體服務能力，讓應用系統的整體擴充套件能力盡可能的提升，擴充套件方式儘可能的便捷。

只要我們通過中間層Proxy應用程式較好的解決了資料切分和資料來源整合問題，那麼資料庫的線性擴充套件能力將很容易做到像我們的應用程式一樣方便，只需要通過新增廉價的PCServer伺服器，即可線性增加資料庫叢集的整體服務能力，讓資料庫不再輕易成為應用系統的效能瓶頸。

資料切分與整合可能存在的問題

這裡，大家應該對資料切分與整合的實施有了一定的認識了，或許很多讀者朋友都已經根據各種解決方案各自特性的優劣基本選定了適合於自己應用場景的方案，後面的工作主要就是實施準備了。

在實施資料切分方案之前，有些可能存在的問題我們還是需要做一些分析的。一般來說，我們可能遇到的問題主要會有以下幾點：

◆ 引入分散式事務的問題；

◆跨節點Join的問題；

◆ 跨節點合併排序分頁問題；

1. 引入分散式事務的問題

一旦資料進行切分被分別存放在多個MySQLServer中之後，不管我們的切分規則設計的多麼的完美（實際上並不存在完美的切分規則），都可能造成之前的某些事務所涉及到的資料已經不在同一個MySQLServer中了。

在這樣的場景下，如果我們的應用程式仍然按照老的解決方案，那麼勢必需要引入分散式事務來解決。而在MySQL各個版本中，只有從MySQL5.0開始以後的各個版本才開始對分散式事務提供支援，而且目前僅有Innodb提供分散式事務支援。不僅如此，即使我們剛好使用了支援分散式事務的MySQL版本，同時也是使用的Innodb儲存引擎，分散式事務本身對於系統資源的消耗就是很大的，效能本身也並不是太高。而且引入分散式事務本身在異常處理方面就會帶來較多比較難控制的因素。

怎麼辦？其實我們可以可以通過一個變通的方法來解決這種問題，首先需要考慮的一件事情就是：是否資料庫是唯一一個能夠解決事務的地方呢？其實並不是這樣的，我們完全可以結合資料庫以及應用程式兩者來共同解決。各個資料庫解決自己身上的事務，然後通過應用程式來控制多個數據庫上面的事務。

也就是說，只要我們願意，完全可以將一個跨多個數據庫的分散式事務分拆成多個僅處於單個數據庫上面的小事務，並通過應用程式來總控各個小事務。當然，這樣作的要求就是我們的俄應用程式必須要有足夠的健壯性，當然也會給應用程式帶來一些技術難度。

2.跨節點Join的問題

上面介紹了可能引入分散式事務的問題，現在我們再看看需要跨節點Join的問題。資料切分之後，可能會造成有些老的Join語句無法繼續使用，因為Join使用的資料來源可能被切分到多個MySQLServer中了。

怎麼辦？這個問題從MySQL資料庫角度來看，如果非得在資料庫端來直接解決的話，恐怕只能通過MySQL一種特殊的儲存引擎Federated來解決了。Federated儲存引擎是MySQL解決類似於Oracle的DBLink之類問題的解決方案。和OracleDBLink的主要區別在於Federated會儲存一份遠端表結構的定義資訊在本地。咋一看，Federated確實是解決跨節點Join非常好的解決方案。但是我們還應該清楚一點，那就似乎如果遠端的表結構發生了變更，本地的表定義資訊是不會跟著發生相應變化的。如果在更新遠端表結構的時候並沒有更新本地的Federated表定義資訊，就很可能造成Query執行出錯，無法得到正確的結果。

對待這類問題，我還是推薦通過應用程式來進行處理，先在驅動表所在的MySQLServer中取出相應的驅動結果集，然後根據驅動結果集再到被驅動表所在的MySQLServer中取出相應的資料。可能很多讀者朋友會認為這樣做對效能會產生一定的影響，是的，確實是會對效能有一定的負面影響，但是除了此法，基本上沒有太多其他更好的解決辦法了。而且，由於資料庫通過較好的擴充套件之後，每臺MySQLServer的負載就可以得到較好的控制，單純針對單條Query來說，其響應時間可能比不切分之前要提高一些，所以效能方面所帶來的負面影響也並不是太大。更何況，類似於這種需要跨節點Join的需求也並不是太多，相對於總體效能而言，可能也只是很小一部分而已。所以為了整體效能的考慮，偶爾犧牲那麼一點點，其實是值得的，畢竟系統優化本身就是存在很多取捨和平衡的過程。

3. 跨節點合併排序分頁問題

一旦進行了資料的水平切分之後，可能就並不僅僅只有跨節點Join無法正常執行，有些排序分頁的Query語句的資料來源可能也會被切分到多個節點，這樣造成的直接後果就是這些排序分頁Query無法繼續正常執行。其實這和跨節點Join是一個道理，資料來源存在於多個節點上，要通過一個Query來解決，就和跨節點Join是一樣的操作。同樣Federated也可以部分解決，當然存在的風險也一樣。

還是同樣的問題，怎麼辦？我同樣仍然繼續建議通過應用程式來解決。

如何解決？解決的思路大體上和跨節點Join的解決類似，但是有一點和跨節點Join不太一樣，Join很多時候都有一個驅動與被驅動的關係，所以Join本身涉及到的多個表之間的資料讀取一般都會存在一個順序關係。但是排序分頁就不太一樣了，排序分頁的資料來源基本上可以說是一個表（或者一個結果集），本身並不存在一個順序關係，所以在從多個數據源取資料的過程是完全可以並行的。這樣，排序分頁資料的取數效率我們可以做的比跨庫Join更高，所以帶來的效能損失相對的要更小，在有些情況下可能比在原來未進行資料切分的資料庫中效率更高了。當然，不論是跨節點Join還是跨節點排序分頁，都會使我們的應用伺服器消耗更多的資源，尤其是記憶體資源，因為我們在讀取訪問以及合併結果集的這個過程需要比原來處理更多的資料。

分析到這裡，可能很多讀者朋友會發現，上面所有的這些問題，我給出的建議基本上都是通過應用程式來解決。大家可能心裡開始犯嘀咕了，是不是因為我是DBA，所以就很多事情都扔給應用架構師和開發人員了？

其實完全不是這樣，首先應用程式由於其特殊性，可以非常容易做到很好的擴充套件性，但是資料庫就不一樣，必須藉助很多其他的方式才能做到擴充套件，而且在這個擴充套件過程中，很難避免帶來有些原來在集中式資料庫中可以解決但被切分開成一個數據庫叢集之後就成為一個難題的情況。要想讓系統整體得到最大限度的擴充套件，我們只能讓應用程式做更多的事情，來解決資料庫叢集無法較好解決的問題。

小結

通過資料切分技術將一個大的MySQLServer切分成多個小的MySQLServer，既解決了寫入效能瓶頸問題，同時也再一次提升了整個資料庫叢集的擴充套件性。不論是通過垂直切分，還是水平切分，都能夠讓系統遇到瓶頸的可能性更小。尤其是當我們使用垂直和水平相結合的切分方法之後，理論上將不會再遇到擴充套件瓶頸了。