數據庫的垂直拆分和水平拆分

    當咱們使用讀寫分離、緩存後，數據庫的壓力仍是很大的時候，這就須要使用到數據庫拆分了。

    數據庫拆分簡單來講，就是指經過某種特定的條件，按照某個維度，將咱們存放在同一個數據庫中的數據分散存放到多個數據庫（主機）上面以達到分散單庫（主機）負載的效果。 

    切分模式： 垂直（縱向）拆分、水平拆分。

 

垂直拆分

        專庫專用

        一個數據庫由不少表的構成，每一個表對應着不一樣的業務，垂直切分是指按照業務將表進行分類，分佈到不一樣的數據庫上面，這樣也就將數據或者說壓力分擔到不一樣的庫上面，以下圖：

優勢：

        1. 拆分後業務清晰，拆分規則明確。

        2. 系統之間整合或擴展容易。

        3. 數據維護簡單。

缺點：

        1. 部分業務表沒法join，只能經過接口方式解決，提升了系統複雜度。

        2. 受每種業務不一樣的限制存在單庫性能瓶頸，不易數據擴展跟性能提升。

        3. 事務處理複雜。

 

水平拆分

        垂直拆分後遇到單機瓶頸，可使用水平拆分。相對於垂直拆分的區別是：垂直拆分是把不一樣的表拆到不一樣的數據庫中，而水平拆分是把同一個表拆到不一樣的數據庫中。

        相對於垂直拆分，水平拆分不是將表的數據作分類，而是按照某個字段的某種規則來分散到多個庫之中，每一個表中包含一部分數據。簡單來講，咱們能夠將數據的水平切分理解爲是按照數據行的切分，就是將表中 的某些行切分到一個數據庫，而另外的某些行又切分到其餘的數據庫中，主要有分表，分庫兩種模式，如圖：

優勢：

        1. 不存在單庫大數據，高併發的性能瓶頸。

        2. 對應用透明，應用端改造較少。     

        3. 按照合理拆分規則拆分，join操做基本避免跨庫。

        4. 提升了系統的穩定性跟負載能力。

缺點：

        1. 拆分規則難以抽象。

        2. 分片事務一致性難以解決。

        3. 數據屢次擴展難度跟維護量極大。

        4. 跨庫join性能較差。

 

拆分的處理難點

兩張方式共同缺點

        1. 引入分佈式事務的問題。

        2. 跨節點Join 的問題。

        3. 跨節點合併排序分頁問題。

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

        A. 客戶端模式，在每一個應用程序模塊中配置管理本身須要的一個（或者多個）數據源，直接訪問各個 數據庫，在模塊內完成數據的整合。 

        優勢：相對簡單，無性能損耗。   

        缺點：不夠通用，數據庫鏈接的處理複雜，對業務不夠透明，處理複雜。

       B. 經過中間代理層來統一管理全部的數據源，後端數據庫集羣對前端應用程序透明；   

        優勢：通用，對應用透明，改造少。   

        缺點：實現難度大，有二次轉發性能損失。

拆分原則

        1. 儘可能不拆分，架構是進化而來，不是一蹴而就。(SOA)

        2. 最大可能的找到最合適的切分維度。

        3. 因爲數據庫中間件對數據Join 實現的優劣難以把握，並且實現高性能難度極大，業務讀取  儘可能少使用多表Join -儘可能經過數據冗餘，分組避免數據垮庫多表join。

        4. 儘可能避免分佈式事務。

        5. 單表拆分到數據1000萬之內。

切分方案

        範圍、枚舉、時間、取模、哈希、指定等

 

===============================================================================

 

案例分析

 

場景一

創建一個歷史his系統，將公司的一些歷史我的遊戲數據保存到這個his系統中，主要是寫入，還有部分查詢，讀寫比約爲1:4；因爲是全部數據的歷史存取，因此併發要求比較高； 

 

分析：

歷史數據

寫多都少

越近日期查詢越頻繁？

什麼業務數據？用戶遊戲數據

有沒有大規模分析查詢？

數據量多大？

保留多久？

機器資源有多少？

 

方案1：按照日期每個月一個分片

帶來的問題：1.數據熱點問題（壓力不均勻）

 

方案2：按照用戶取模，  --by Jerome 就這個比較合適了

帶來的問題：後續擴容困難

 

方案3：按用戶ID範圍分片（1-1000萬=分片1，xxx）

帶來的問題：用戶活躍度沒法掌握，可能存在熱點問題

 

場景二

創建一個商城訂單系統，保存用戶訂單信息。

 

分析：

電商系統

一號店或京東類？淘寶或天貓？

實時性要求高

存在瞬時壓力

基本不存在大規模分析

數據規模？

機器資源有多少？

維度？商品？用戶？商戶？

 

方案1：按照用戶取模，

帶來的問題：後續擴容困難

 

方案2：按用戶ID範圍分片（1-1000萬=分片1，xxx）

帶來的問題：用戶活躍度沒法掌握，可能存在熱點問題

 

方案3：按省份地區或者商戶取模

數據分配不必定均勻

 

場景3

上海公積金，養老金，社保系統

 

分析：

社保系統

實時性要求不高

不存在瞬時壓力

大規模分析？

數據規模大

數據重要不可丟失

偏於查詢？

 

方案1：按照用戶取模，

帶來的問題：後續擴容困難

 

方案2：按用戶ID範圍分片（1-1000萬=分片1，xxx）

帶來的問題：用戶活躍度沒法掌握，可能存在熱點問題

 

方案3：按省份區縣地區枚舉

數據分配不必定均勻