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