replication的限制:一旦數(shù)據(jù)庫過于龐大，尤其是當寫入過于頻繁，很難由一臺主機支撐的時候，我們還是會面臨到擴展瓶頸。數(shù)據(jù)切分(sharding):通過某種特定的條件，將我們存放在同一個數(shù)據(jù)庫中的數(shù)據(jù)分散存放到多個數(shù)據(jù)庫（主機）上面，以達到分散單臺設備負載的效果。。數(shù)據(jù)的切分同時還可以提高系統(tǒng)的總體可用性，因為單臺設備Crash之后，只有總體數(shù)據(jù)的某部分不可用，而不是所有的數(shù)據(jù)。
數(shù)據(jù)的切分（Sharding）模式
一種是按照不同的表（或者Schema）來切分到不同的數(shù)據(jù)庫（主機）之上，這種切可以稱之為數(shù)據(jù)的垂直（縱向）切分；另外一種則是根據(jù)表中的數(shù)據(jù)的邏輯關系，將同一個表中的數(shù)據(jù)按照某種條件拆分到多臺數(shù)據(jù)庫（主機）上面，這種切分稱之為數(shù)據(jù)的水平（橫向）切分。
垂直切分:一個架構設計較好的應用系統(tǒng)，其總體功能肯定是由很多個功能模塊所組成的，而每一個功能模塊所需要的數(shù)據(jù)對應到數(shù)據(jù)庫中就是一個或者多個表。而在架構設計中，各個功能模塊相互之間的交互點越統(tǒng)一越少，系統(tǒng)的耦合度就越低，系統(tǒng)各個模塊的維護性以及擴展性也就越好。這樣的系統(tǒng)，實現(xiàn)數(shù)據(jù)的垂直切分也就越容易。
一般來說，如果是一個負載相對不是很大的系統(tǒng)，而且表關聯(lián)又非常的頻繁，那可能數(shù)據(jù)庫讓步，將幾個相關模塊合并在一起減少應用程序的工作的方案可以減少較多的工作量，這是一個可行的方案。一個垂直拆分的例子:
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
- 群組討論模塊和用戶模塊之間主要存在通過用戶或者是群組關系來進行關聯(lián)。一般關聯(lián)的時候都會是通過用戶的id或者nick_name以及group的id來進行關聯(lián)，通過模塊之間的接口實現(xiàn)不會帶來太多麻煩；
- 相冊模塊僅僅與用戶模塊存在通過用戶的關聯(lián)。這兩個模塊之間的關聯(lián)基本就有通過用戶id關聯(lián)的內容，簡單清晰，接口明確；
- 事件模塊與各個模塊可能都有關聯(lián)，但是都只關注其各個模塊中對象的ID信息，同樣可以做到很容易分拆。
垂直切分的優(yōu)點 - 數(shù)據(jù)庫的拆分簡單明了，拆分規(guī)則明確；
- 應用程序模塊清晰明確，整合容易；
- 數(shù)據(jù)維護方便易行，容易定位；
垂直切分的缺點 - 部分表關聯(lián)無法在數(shù)據(jù)庫級別完成，需要在程序中完成；
- 對于訪問極其頻繁且數(shù)據(jù)量超大的表仍然存在性能瓶頸，不一定能滿足要求；
- 事務處理相對更為復雜；
- 切分達到一定程度之后，擴展性會遇到限制；
- 過讀切分可能會帶來系統(tǒng)過渡復雜而難以維護。
水平切分將某個訪問極其頻繁的表再按照某個字段的某種規(guī)則來分散到多個表之中，每個表中包含一部分數(shù)據(jù)。
對于上面的例子:所有數(shù)據(jù)都是和用戶關聯(lián)的，那么我們就可以根據(jù)用戶來進行水平拆分，將不同用戶的數(shù)據(jù)切分到不同的數(shù)據(jù)庫中。
現(xiàn)在互聯(lián)網(wǎng)非常火爆的Web2.0類型的網(wǎng)站，基本上大部分數(shù)據(jù)都能夠通過會員用戶信息關聯(lián)上，可能很多核心表都非常適合通過會員ID來進行數(shù)據(jù)的水平切分。而像論壇社區(qū)討論系統(tǒng)，就更容易切分了，非常容易按照論壇編號來進行數(shù)據(jù)的水平切分。切分之后基本上不會出現(xiàn)各個庫之間的交互。
水平切分的優(yōu)點 - 表關聯(lián)基本能夠在數(shù)據(jù)庫端全部完成；
- 不會存在某些超大型數(shù)據(jù)量和高負載的表遇到瓶頸的問題；
- 應用程序端整體架構改動相對較少；
- 事務處理相對簡單；
- 只要切分規(guī)則能夠定義好，基本上較難遇到擴展性限制；
水平切分的缺點 - 切分規(guī)則相對更為復雜，很難抽象出一個能夠滿足整個數(shù)據(jù)庫的切分規(guī)則；
- 后期數(shù)據(jù)的維護難度有所增加，人為手工定位數(shù)據(jù)更困難；
- 應用系統(tǒng)各模塊耦合度較高，可能會對后面數(shù)據(jù)的遷移拆分造成一定的困難。
兩種切分結合用:一般來說，我們數(shù)據(jù)庫中的所有表很難通過某一個（或少數(shù)幾個）字段全部關聯(lián)起來，所以很難簡單的僅僅通過數(shù)據(jù)的水平切分來解決所有問題。而垂直切分也只能解決部分問題，對于那些負載非常高的系統(tǒng)，即使僅僅只是單個表都無法通過單臺數(shù)據(jù)庫主機來承擔其負載。我們必須結合“垂直”和“水平”兩種切分方式同時使用
每一個應用系統(tǒng)的負載都是一步一步增長上來的，在開始遇到性能瓶頸的時候，大多數(shù)架構師和DBA都會選擇先進行數(shù)據(jù)的垂直拆分，因為這樣的成本最先，最符合這個時期所追求的最大投入產出比。然而，隨著業(yè)務的不斷擴張，系統(tǒng)負載的持續(xù)增長，在系統(tǒng)穩(wěn)定一段時期之后，經過了垂直拆分之后的數(shù)據(jù)庫集群可能又再一次不堪重負，遇到了性能瓶頸。
如果我們再一次像最開始那樣繼續(xù)細分模塊，進行數(shù)據(jù)的垂直切分，那我們可能在不久的將來，又會遇到現(xiàn)在所面對的同樣的問題。而且隨著模塊的不斷的細化，應用系統(tǒng)的架構也會越來越復雜，整個系統(tǒng)很可能會出現(xiàn)失控的局面。
這時候我們就必須要通過數(shù)據(jù)的水平切分的優(yōu)勢，來解決這里所遇到的問題。而且，我們完全不必要在使用數(shù)據(jù)水平切分的時候，推倒之前進行數(shù)據(jù)垂直切分的成果，而是在其基礎上利用水平切分的優(yōu)勢來避開垂直切分的弊端，解決系統(tǒng)復雜性不斷擴大的問題。而水平拆分的弊端（規(guī)則難以統(tǒng)一）也已經被之前的垂直切分解決掉了，讓水平拆分可以進行的得心應手。
示例數(shù)據(jù)庫:
假設在最開始，我們進行了數(shù)據(jù)的垂直切分，然而隨著業(yè)務的不斷增長，數(shù)據(jù)庫系統(tǒng)遇到了瓶頸，我們選擇重構數(shù)據(jù)庫集群的架構。如何重構？考慮到之前已經做好了數(shù)據(jù)的垂直切分，而且模塊結構清晰明確。而業(yè)務增長的勢頭越來越猛，即使現(xiàn)在進一步再次拆分模塊，也堅持不了太久。
==>選擇了在垂直切分的基礎上再進行水平拆分。
==>在經歷過垂直拆分后的各個數(shù)據(jù)庫集群中的每一個都只有一個功能模塊，而每個功能模塊中的所有表基本上都會與某個字段進行關聯(lián)。如用戶模塊全部都可以通過用戶ID進行切分，群組討論模塊則都通過群組ID來切分，相冊模塊則根據(jù)相冊ID來進切分，最后的事件通知信息表考慮到數(shù)據(jù)的時限性（僅僅只會訪問最近某個事件段的信息），則考慮按時間來切分。
數(shù)據(jù)切分以及整合方案.數(shù)據(jù)庫中的數(shù)據(jù)在經過垂直和（或）水平切分被存放在不同的數(shù)據(jù)庫主機之后，應用系統(tǒng)面臨的最大問題就是如何來讓這些數(shù)據(jù)源得到較好的整合，其中存在兩種解決思路：
- 在每個應用程序模塊中配置管理自己需要的一個（或者多個）數(shù)據(jù)源，直接訪問各個數(shù)據(jù)庫，在模塊內完成數(shù)據(jù)的整合；
- 通過中間代理層來統(tǒng)一管理所有的數(shù)據(jù)源，后端數(shù)據(jù)庫集群對前端應用程序透明；
第二種方案,雖然短期內需要付出的成本可能會相對更大一些，但是對整個系統(tǒng)的擴展性來說，是非常有幫助的。針對第二種方案，可以選擇的方法和思路有：
1.利用MySQLProxy 實現(xiàn)數(shù)據(jù)切分及整合.可用來監(jiān)視、分析或者傳輸他們之間的通訊信息。他的靈活性允許你最大限度的使用它，目前具備的功能主要有連接路由，Query分析，Query過濾和修改，負載均衡，以及基本的HA機制等。MySQLProxy 本身并不具有上述所有的這些功能，而是提供了實現(xiàn)上述功能的基礎。要實現(xiàn)這些功能，還需要通過我們自行編寫LUA腳本來實現(xiàn)。
原理:MySQLProxy 實際上是在客戶端請求與MySQLServer 之間建立了一個連接池。所有客戶端請求都是發(fā)向MySQLProxy，然后經由MySQLProxy 進行相應的分析，判斷出是讀操作還是寫操作，分發(fā)至對應的MySQLServer 上。對于多節(jié)點Slave集群，也可以起做到負載均衡的效果。
2.利用Amoeba實現(xiàn)數(shù)據(jù)切分及整合Amoeba是一個基于Java開發(fā)的，專注于解決分布式數(shù)據(jù)庫數(shù)據(jù)源整合Proxy程序的開源框架，Amoeba已經具有Query路由，Query過濾，讀寫分離，負載均衡以及HA機制等相關內容。Amoeba主要解決的以下幾個問題：
- 數(shù)據(jù)切分后復雜數(shù)據(jù)源整合；
- 提供數(shù)據(jù)切分規(guī)則并降低數(shù)據(jù)切分規(guī)則給數(shù)據(jù)庫帶來的影響；
- 降低數(shù)據(jù)庫與客戶端的連接數(shù)；
- 讀寫分離路由；
AmoebaFor MySQL 主要是專門針對MySQL數(shù)據(jù)庫的解決方案，前端應用程序請求的協(xié)議以及后端連接的數(shù)據(jù)源數(shù)據(jù)庫都必須是MySQL。對于客戶端的任何應用程序來說，AmoebaForMySQL 和一個MySQL數(shù)據(jù)庫沒有什么區(qū)別，任何使用MySQL協(xié)議的客戶端請求，都可以被AmoebaFor MySQL 解析并進行相應的處理。
Proxy程序常用的功能如讀寫分離，負載均衡等配置都在amoeba.xml中進行。Amoeba已經支持了實現(xiàn)數(shù)據(jù)的垂直切分和水平切分的自動路由，路由規(guī)則可以在rule.xml進行設置。
3.利用HiveDB實現(xiàn)數(shù)據(jù)切分及整合HiveDB同樣是一個基于Java針對MySQL數(shù)據(jù)庫的提供數(shù)據(jù)切分及整合的開源框架，只是目前的HiveDB僅僅支持數(shù)據(jù)的水平切分。主要解決大數(shù)據(jù)量下數(shù)據(jù)庫的擴展性及數(shù)據(jù)的高性能訪問問題，同時支持數(shù)據(jù)的冗余及基本的HA機制。
HiveDB的實現(xiàn)機制與MySQLProxy 和Amoeba有一定的差異，他并不是借助MySQL的Replication功能來實現(xiàn)數(shù)據(jù)的冗余，而是自行實現(xiàn)了數(shù)據(jù)冗余機制，而其底層主要是基于HibernateShards 來實現(xiàn)的數(shù)據(jù)切分工作。數(shù)據(jù)切分與整合中可能存在的問題
引入分布式事務的問題?一旦數(shù)據(jù)進行切分被分別存放在多個MySQLServer中之后，不管我們的切分規(guī)則設計的多么的完美（實際上并不存在完美的切分規(guī)則），都可能造成之前的某些事務所涉及到的數(shù)據(jù)已經不在同一個MySQLServer 中了。
==>將一個跨多個數(shù)據(jù)庫的分布式事務分拆成多個僅處于單個數(shù)據(jù)庫上面的小事務，并通過應用程序來總控各個小事務。
跨節(jié)點Join的問題?==>先從一個節(jié)點取出數(shù)據(jù),然后根據(jù)這些數(shù)據(jù),再到另一個表中取數(shù)據(jù).
==>使用Federated存儲引擎,問題是:乎如果遠端的表結構發(fā)生了變更，本地的表定義信息是不會跟著發(fā)生相應變化的。
跨節(jié)點合并排序分頁問題?==>Join本身涉及到的多個表之間的數(shù)據(jù)讀取一般都會存在一個順序關系。但是排序分頁就不太一樣了，排序分頁的數(shù)據(jù)源基本上可以說是一個表（或者一個結果集），本身并不存在一個順序關系，所以在從多個數(shù)據(jù)源取數(shù)據(jù)的過程是完全可以并行的。這樣，排序分頁數(shù)據(jù)的取數(shù)效率我們可以做的比跨庫Join更高，所以帶來的性能損失相對的要更小。