詳見：http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt330
雖然在雲計算時代，傳統數據庫存在着先天性的弊端，但是NoSQL數據庫又無法將其替代，NoSQL只能作為傳統數據的補充而不能將其替代，所以規避傳統數據庫的缺點是目前大數據時代必須要解決的問題。如果傳統數據易於擴展，可切分，就可以避免單機（單庫）的性能缺陷，但是由於目前開源或者商用的傳統數據庫基本不支持大規模自動擴展，所以就需要借助第三方來做處理，下面就來分析一下如何進行數據切分。
何為數據切分？
簡單來說，就是指通過某種特定的條件，將我們存放在同一個數據庫中的數據分散存放到多個數據庫（主機）上面，以達到分散單台設備負載的效果。
數據的切分（Sharding）根據其切分規則的類型，可以分為兩種切分模式。一種是按照不同的表（或者Schema）來切分到不同的數據庫（主機）之上，這種切可以稱之為數據的垂直（縱向）切分；另外一種則是根據表中的數據的邏輯關系，將同一個表中的數據按照某種條件拆分到多台數據庫（主機）上面，這種切分稱之為數據的水平（橫向）切分。
垂直切分的最大特點就是規則簡單，實施也更為方便，尤其適合各業務之間的耦合度非常低，相互影響很小，業務邏輯非常清晰的系統。在這種系統中，可以很容易做到將不同業務模塊所使用的表分拆到不同的數據庫中。根據不同的表來進行拆分，對應用程序的影響也更小，拆分規則也會比較簡單清晰。
水平切分於垂直切分相比，相對來說稍微復雜一些。因為要將同一個表中的不同數據拆分到不同的數據庫中，對於應用程序來說，拆分規則本身就較根據表名來拆分更為復雜，后期的數據維護也會更為復雜一些。
垂直切分
一個數據庫由很多表的構成，每個表對應着不同的業務，垂直切分是指按照業務將表進行分類，分布到不同的數據庫上面，這樣也就將數據或者說壓力分擔到不同的庫上面，如下圖：
系統被切分成了，用戶，訂單交易，支付幾個模塊。
一個架構設計較好的應用系統，其總體功能肯定是由很多個功能模塊所組成的，而每一個功能模塊所需要的數據對應到數據庫中就是一個或者多個表。而在架構設計中，各個功能模塊相互之間的交互點越統一越少，系統的耦合度就越低，系統各個模塊的維護性以及擴展性也就越好。這樣的系統，實現數據的垂直切分也就越容易。
但是往往系統之有些表難以做到完全的獨立，存在這擴庫join的情況，對於這類的表，就需要去做平衡，是數據庫讓步業務，共用一個數據源，還是分成多個庫，業務之間通過接口來做調用。在系統初期，數據量比較少，或者資源有限的情況下，會選擇共用數據源，但是當數據發展到了一定的規模，負載很大的情況，就需要必須去做分割。
一般來講業務存在着復雜join的場景是難以切分的，往往業務獨立的易於切分。如何切分，切分到何種程度是考驗技術架構的一個難題。
下面來分析下垂直切分的優缺點：
優點：
拆分后業務清晰，拆分規則明確。
系統之間整合或擴展容易。
數據維護簡單。
缺點：
部分業務表無法join，只能通過接口方式解決，提高了系統復雜度。
受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高。
事務處理復雜。
由於垂直切分是按照業務的分類將表分散到不同的庫，所以有些業務表會過於龐大，存在單庫讀寫與存儲瓶頸，所以就需要水平拆分來做解決。
水平切分
相對於垂直拆分，水平拆分不是將表做分類，而是按照某個字段的某種規則來分散到多個庫之中，每個表中包含一部分數據。簡單來說，我們可以將數據的水平切分理解為是按照數據行的切分，就是將表中的某些行切分到一個數據庫，而另外的某些行又切分到其他的數據庫中，如圖：
拆分數據就需要定義分片規則。關系型數據庫是行列的二維模型，拆分的第一原則是找到拆分維度。比如：從會員的角度來分析，商戶訂單交易類系統中查詢會員某天某月某個訂單，那么就需要按照會員結合日期來拆分，不同的數據按照會員ID做分組，這樣所有的數據查詢join都會在單庫內解決；如果從商戶的角度來講，要查詢某個商家某天所有的訂單數，就需要按照商戶ID做拆分；但是如果系統既想按會員拆分，又想按商家數據，則會有一定的困難。如何找到合適的分片規則需要綜合考慮衡量。
幾種典型的分片規則包括：
按照用戶ID求模，將數據分散到不同的數據庫，具有相同數據用戶的數據都被分散到一個庫中。
按照日期，將不同月甚至日的數據分散到不同的庫中。
按照某個特定的字段求摸，或者根據特定范圍段分散到不同的庫中。
如圖，切分原則都是根據業務找到適合的切分規則分散到不同的庫，下面用用戶ID求模舉例：
既然數據做了拆分有優點也就優缺點。
優點有：
拆分規則抽象好，join操作基本可以數據庫做。
不存在單庫大數據，高並發的性能瓶頸。
應用端改造較少。
提高了系統的穩定性跟負載能力。
缺點有：
拆分規則難以抽象。
分片事務一致性難以解決。
數據多次擴展難度跟維護量極大。
跨庫join性能較差。
前面講了垂直切分跟水平切分的不同跟優缺點，會發現每種切分方式都有缺點，但共同的特點缺點有：
引入分布式事務的問題。
跨節點Join的問題。
跨節點合並排序分頁問題。
多數據源管理問題。
針對數據源管理，目前主要有兩種思路：
A. 客戶端模式，在每個應用程序模塊中配置管理自己需要的一個（或者多個）數據源，直接訪問各個數據庫，在模塊內完成數據的整合；
B. 通過中間代理層來統一管理所有的數據源，后端數據庫集群對前端應用程序透明；
可能90%以上的人在面對上面這兩種解決思路的時候都會傾向於選擇第二種，尤其是系統不斷變得龐大復雜的時候。確實，這是一個非常正確的選擇，雖然短期內需要付出的成本可能會相對更大一些，但是對整個系統的擴展性來說，是非常有幫助的。
由於數據切分后數據Join的難度在此也分享一下數據切分的經驗：
第一原則：能不切分盡量不要切分。
第二原則：如果要切分一定要選擇合適的切分規則，提前規划好。
第三原則：數據切分盡量通過數據冗余或表分組（Table Group）來降低跨庫Join的可能。
第四原則：由於數據庫中間件對數據Join實現的優劣難以把握，而且實現高性能難度極大，業務讀取盡量少使用多表Join。