[Note] Sharding and Partition
大量的資料都存在一張表, 查詢, 更新都會成為瓶頸, 所以需要做到分庫分表. 不管是I/O瓶頸, 還是CPU瓶頸, 最終都會導致資料庫的活躍連接數增加, 進而逼近甚至達到資料庫可乘載的活躍連接數的閥值. 可以使用分庫分表來緩解資料庫的壓力問題.
source : 支付架构实战
Sharding : 分庫
分庫具體就是Process甚至機器是獨立的 所以分庫能降低單台機器的負載, 像是CPU瓶頸, 網路連線數瓶頸, IO瓶頸等;
Partition : 分表
分表則只是把資料做了冷熱分開放 分表則是提高數據訪問的效率, 主要是解決IO瓶頸跟CPU瓶頸.
Horizontal 水平
每個(表/庫)的結構都一樣, 每個(表/庫)的數據都不一樣 以字段為依據, 依照一定的策略(Hash, Range 等) 將一個(表/庫)中的數據拆分到多個(表/庫)中
Vertical 垂直
每個(表/庫)的結構都不一樣, 每個(表/庫)中的數據也不一樣
1. Horizontal Sharding 水平分庫
思路
以字段為依據, 依照一定的策略(Hash, Range 等) 將一個庫中的數據拆分到多個庫中
結果
每個庫的結構都一樣, 每個庫中的數據都不一樣, 沒有交集, 所有庫的聯集是全部的數據
使用場景
系統絕對併發數量增加了, 分表難以從根本上解決問題, 並且還沒有明顯的業務歸屬來垂直分庫
分析
拆分的庫多了, I/O 和 CPU 的壓力自然可以成倍緩解. 比如原來的 QPS 是 500 拆成兩個庫之後每個庫的 QPS 為 250.
2. Horizontal Partitioning 水平分表
思路
已字段為依據, 依照一定的策略(Hash, Range 等) 將一個表的數據拆分到多個表中
結果
每個表的結構都一樣, 每個表的數據都不一樣, 沒有交集, 所有表的聯集是全部的數據
使用場景
系統絕對並發量沒有增加, 只是單表的數據量太多, 影響了 SQL效率, 加重了 CPU 負擔, 以至於成為性能瓶頸
分析
表的數據量少了, 單次 SQL 執行效率提高, 自然減輕了 CPU 的負擔. 另外, 拆分的表多了, 單個表的數據查詢量會成倍減少
3. Vertical Sharding 垂直分庫
思路
以表為依據, 依照業務歸屬將不同的表拆分到不同的庫中
結果
每個庫的結構都不一樣, 每個庫中的數據也不一樣, 沒有交集, 所有庫的聯集是全量數據
使用場景
系統絕對並發量增加, 單庫無法承擔並發量, 可以抽象出單體的業務模塊, 把單獨的業務模塊拆分出來形成一個新的庫
分析
隨著業務的發展, 公用的配置表, 字典表等越來越多, 這時可以將這些表拆分到單獨的庫中
4. Vertical Partitioning 垂直分表
思路
以字段為依據, 依照字段的活躍性江表中字段拆分到不同的表(主表和擴充表)中
結果
每個表的結構都不一樣, 每個表中的數據也不一樣, 每個表的字段至少有一列交集, 一般是主鍵, 用於關聯數據, 所有表的聯集是全量數據
使用場景
系統絕對並發量沒有增加, 表的紀錄並不多, 但是字段多, 並且熱點數據和非熱點數據在一起, 單行數據所需的存儲空間較大, 以至於數據庫緩存的數據行減少, 查詢時會去讀取磁盤數據, 從而產生大量的隨機讀取 I/O, 出現 I/O 瓶頸
分析
可以用列表和行情頁來幫助理解. 垂直分表的拆分原則就是將熱點數據放在一起作為主表, 非熱點數據放在一起作為擴充表. 這樣更多的熱點數據就能被緩存下來, 進而減少隨機讀 I/O. 拆分之後, 要獲得全部數據就需要關聯兩個表來獲取數據. 但是千萬別用 Join, 因為 Join 不僅會增加 CPU 負擔, 而且會將兩個表耦合在一起 (必須在一個數據庫實例上). 應該在業務 Severice 層實現數據的關聯, 分別獲取主表和擴充表數據, 然後用關聯字段關聯得到全部數據
Summary
| Horizontal Sharding | Horizontal Partitioning | Vertical Sharding | Vertical Partitioning | |
|---|---|---|---|---|
| 依據 | 字段 | 字段 | 表 | 字段 |
| 結構 | 庫結構一樣, 每個庫數據都不一樣 | 表結構一樣, 每個表中數據都不一樣 | 庫結構不一樣, 每個庫中數據都不一樣 | 表結構不一樣, 每個表中數據都不一樣 |
| 適合系統絕對並發量增加 | O | X | O | X |
| 解決 | 網路 I/O 瓶頸 | CPU 瓶頸 | 磁盤讀 I/O 瓶頸 | 磁盤讀 I/O 瓶頸 |
Horizontal Sharding & Partitioning
