分佈式數據庫切分規則介紹

數據切分：
        就是指經過某種特定的條件，將咱們存放在同一個數據庫中的數據分散存放到多個數據庫（主機）上面，以達到分散單臺設備負載的效果。

根據切分規則，能夠分爲兩種切分模式：
垂直（縱向）切分；

        按照業務，把業務不一樣的表(或者Schema)來切分到不一樣的數據庫（主機）之上。
        一個數據庫由不少表的構成，每一個表對應着不一樣的業務，垂直切分是指按照業務將表進行分類，分佈到不一樣的數據庫上面，這樣也就將數據或者說壓力分擔到不一樣的庫上面。根據業務模塊之間的耦合度狀況，來制定垂直切分規則。實施起來思路比較清晰，容易進行。

       一個架構設計較好的應用系統，其整體功能確定是由不少個功能模塊所組成的，而每個功能模塊所須要的數據對應到數據庫中就是一個或者多個表。而在構架設計中，各個功能模塊相互之間的交互點越統一越少，系統的耦合度就越低，系統各個模塊的維護性以及擴展性也就越好。這樣的系統，實現數據的垂直切分也就越容易。
      可是每每系統裏有些表難以作到徹底的獨立，存在這擴庫join的狀況，對於這類的表，就須要去作平衡，是數據庫讓業務，共用一個數據源，仍是分紅多個庫，業務之間經過接口來作調用。在系統初期，數據量比較少，或者資源有限的狀況下，會選擇共用數據源，可是當數據發展到了必定的規模，負載很大的狀況，就須要必須去作分割。 通常來說業務存在着複雜join的場景是難以切分的。如何切分，切分到何種程度是考驗技術架構的一個難題。

垂直切分優勢：
        拆分後業務清晰，拆分規則明確
        系統之間整合或擴展容易
        數據維護簡單
垂直切分缺點：
        部分業務表沒法join，只能經過接口方式解決，提升了系統複雜度。
        受每種業務不一樣的限制存在單庫性能瓶頸，不易數據擴展跟性能提升。
        事務處理複雜。 

因爲垂直切分是按照業務的分類將表分散到不一樣庫，因此有些業務表會過於龐大，存在單庫讀寫與存儲瓶頸，因此就須要水平拆分來作解決。

水平（橫向）切分；

       根據表中數據的邏輯關係，將同一個表中數據按照某種條件拆分到多臺數據庫（主機）上面。
       相對於垂直拆分，水平拆分不是將表作分類，而是按照某個字段的某種規則來分散到多個庫之中，每一個表中包含一部分數據。簡單來講，咱們能夠將數據的水平切分理解爲是按照數據行的切分，就是將表中的某些行切分到一個數據庫，而另外的某些行又切分到其餘的數據庫中。

       拆分數據就須要定義分片規則。關係型數據庫是行列的二維模型，拆分的第一原則是找到拆分維度。好比：從會員的角度來分析，商戶訂單交易類系統中查詢會員某天某月某個訂單，那麼就須要按照會員結合日期來拆分，不一樣的數據按照會員ID作分組，這樣全部的數據查詢join都會在單庫內解決；若是從商戶的角度來說，要查詢某個商家某天全部的訂單數，就須要按照商戶ID作拆分；可是若是系統既想按會員拆分，又想按商家數據拆分，則會有必定的難度。如何找到合適的分片規則須要綜合考慮衡量。

 幾種典型的分片規則包括：
     按照用戶ID求模，將數據分散到不一樣的數據庫，具備相同數據用戶的數據都被分散到一個庫中。
     按照日期，將不一樣月甚至日的數據分散到不一樣的庫中。
     按照某個特定的字段求模，或者根據特定範圍段分散到不一樣的庫中。

水平拆分優勢：
        拆分規則抽象好，join操做基本能夠數據庫作。
        不存在單庫大數據，高併發的性能瓶頸。
        應用端改造較少。
        提升了系統的穩定性跟負載能力。
水平拆分缺點：
        拆分規則難以抽象。
        分片事務一致性難以解決。
        數據屢次擴展難度跟維護量級大。
        跨庫join性能較差 

前面講了垂直切分跟水平切分的不一樣跟優缺點，會發現每種切分方式都有缺點，但共同的特色缺點有：

        引入分佈式事務的問題。
        跨節點join的問題。
        跨節點合併排序分頁問題。
        多數據源管理問題。 

針對數據源管理，目前主要有兩種思路：

A：客戶端模式，在每一個應用程序模塊中配置管理本身須要的一個（或者多個）數據源，直接訪問各個數據庫，在模塊內完成數據的整合；
B：經過中間代理層來統一管理全部的數據源，後端數據庫集羣對前端應用程序透明；
可能90%以上的人在面對上面這兩種解決思路的時候都會傾向於選擇第二種，尤爲是系統不斷變得龐大複雜的時候。確實，這是一個很是正確的選擇，雖然短時間內須要付出的成本可能會相對更大一些，可是對整個系統的擴展性來講，是很是有幫助的。

對於切分原則，建議以下：

第一原則：能不切分儘可能不要切分。 第二原則：若是要切分必定要選擇合適的切分規則，提早規劃好。 第三原則：數據切分儘可能經過數據冗餘或表分組（Table Group）來下降跨庫Join的可能。 第四原則：因爲數據庫中間件對數據Join實現的優劣難以把握，並且實現高性能難度極大，業務讀取儘可能少使用多表Join。