歷史背景
MySql性能瓶頸
- 1. 表資料量過大
- 2. Sql查詢過于復雜
- 3. Sql沒走索引
- 4. 資料庫服務器性能低
解決方案
阿里開發手冊：單表行數超過500W或者單表容量超過2G
資料庫分庫分表
- 分庫分表
- 冷熱資料分離
- 歷史資料分離
資料庫分庫分表
- 1. 垂直拆分
- 垂直分表（大表拆成多個小表）
優點
- 防止單表欄位過多產生頁分裂從而導致IO次數過多，效率差的問題
- 可以達到最大化利用Cache的目的，具體在垂直拆分的時候可以將不常變的欄位放一起，將經常改變的放一起
缺點
1. 主鍵出現冗余，需要管理冗余例
2. 會引起表連接JOIN操作(增加CPU開銷
3. sql以及事務處理復雜
- 垂直分庫（單個庫拆成多個庫 微服務系統）
優點
分散單庫訪問壓力
缺點
分布式事務問題
- 2. 水平拆分
- 1. 水平分表
優點
1.單庫單表的資料能保持在一定的量級，有助于性能的提高，
2.切分的表結構相同，應用層改造較少，只需要增加路由規則即可，
3.提高了系統的穩定性和負載能力，
缺點
- 切分后，資料是分散的，跨庫join操作難和性能差
- 拆分規則難以抽象
- 分片事務的一致性難以解決
- 資料擴容的難度和維護量極大
- 2. 水平分庫
分庫分表演算法
- 1. 哈希取模演算法
優點
演算法簡單，資料分布相對均勻
缺點
擴容問題，需要哈希取模全部資料遷移（比如增加user_05,演算法變成id%5,01-04里面資料全部需要重新分布）
- 2. 一致性哈希演算法
當B需要移除時
hash環的偏斜
在實際的映射中，服務器可能會被映射成如下模樣，
如果服務器被映射成上圖中的模樣，那么被快取的物件很有可能大部分集中快取在某一臺服務器上，如下圖所示，
虛擬節點（定義虛擬節點，讓哈希環分布均勻）
- 3. 按照范圍分片演算法（按照不同的資料業務特性定義分片鍵）
- 按照商家
- 按照時間月份
- 按照地域
案例
用戶表
- 1. 功能
注冊，登錄，查詢，修改
- 2. 使用范圍
- 1. 用戶端（用戶登錄，修改用戶，資訊查詢）
1.根據用戶ID查詢用戶資訊->90%
2.根據phone,email查詢用戶資訊->10%
- 2. 管理員端
- 統計用戶資訊
- 查詢條件多變查詢
可以根據用戶ID進行分片
分庫分表中間件
- 1. 分庫分表組件（Sharding-JDBC 代碼實作）
- 2. 服務端代理(MyCat)
分庫分表問題
- 1. 歷史資料遷移
- 2. 復雜SQL聯合查詢
- 3. 分頁問題
- 4. 事務問題
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/402434.html
標籤：其他