深刻理解關係型數據庫的數據水平切分和垂直切分

詳見：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。