網站跟服務隨著用戶數量線性上升後, 幾乎時常接受著大流量、高併發、海量數據的洗禮.
單庫的行能瓶頸會浮現出來. 海量數據下, 數據庫的查詢效率會遞減, 慢慢的就出現越來越多Slow SQL.
雖然現在有NoSQL能把非結構化/半結構化的資料儲存來提昇性能, 但重要的業務資料會將之結構化, 落地到SQL上(為了滿足ACID).

結構化資料 vs 半結構化資料 vs 非結構化資料

• 結構化資料: 固定欄位、固定格式、固定順序, 關聯式資料庫 => 先有結構, 再有資料
• 半結構化資料 : 一樣是具有欄位, 也有格式, 但未必完整; 像是JSON, 隨時能擴充或是只給部份字段欄位 => 先有資料, 再有結構
• 非結構化資料: 沒特定格式欄位的數據, 像是圖片、爬到的網頁、影片、二進位檔案、PDF, 都是 => 重點是資料的格式, 才知道怎解析資料本質.

接著講, 怎提昇RDBMS的並行處理能力跟查詢效率, 就成了需要思考跟解決的議題.
如果只有單一個資料庫, 只要DB crash, 系統就也下線了. 所以怎讓後端儲存系統具備HA、擴容, 就成了成長快速的服務一個要面對的議題.

資料庫的架構演變

RDBMS常見的性能瓶頸有

• 大量的併發讀/寫操作, 導致單庫出現難以承受的負載
• 單表儲存資料亮過大, 導致查詢效率差

還記得DAY3提到的AKF拆分原則吧?
不少概念是從中衍生的.

讀/寫分離 Read/Write Splitting

一個系統或是服務剛上線時, 基本上併發量跟數據都不會太多.
所以很常一開始都是把資料儲存在單庫上, 並進行讀/寫操作.
但隨著用戶數量開始上升, 活躍人數激增! 單庫的TPS/QPS會越來越低.

QPS、TPS

QPS : Queries Per Second, 每秒能應付的查詢次數
TPS : Transasction Per Second 每秒處理的事務數量

當API收到請求時, 會對SQL發出事務請求,這事務可能包含很多命令, 但就只看一秒能事務完成的數量, 就是TPS.
QPS就是查詢, 剛剛的事務要是包含了2個查詢語句, 那就等於產生了2個Queries.

通常一開始DBA都會選擇先做讀/寫分離架構(大部分都採用1主1從 或是1主多從, 能參考Day4&Day5); 由主節點負責寫操作, 從庫節點作為備庫, 會允許讀取操作, 主從之間保持數據同步就好.

根據二八法則, 幾乎80%的資料庫流量都在讀取操作上, 20%左右是寫入操作, 所以經過讀/寫分離架構的改造後, 可以大幅提昇單庫無法支撐的負載(至少主庫會很有感).

垂直分庫 Vertical Sharding

雖然我們把架構做了讀/寫分離了, 但是無法解決海量業務數據的問題.
寫入操作, 常見場景都是用Auto_Increment PK是順序寫入的, 性能不是大問題.

自增有序的優點

• INT佔用的bit數相對小(通常都是BIGINT), 對一個page 16kb能塞的資料就能多很多
• INT是基礎型別
• 因為是有序, 所以當B+Tree的葉子節點放滿了, 就只會在該節點分裂. 減少分裂頁的產生, 資料移動跟空間碎片減少發生.
  B+Tree Visualization
• 資料插入時, 也能確保邏輯相鄰的資料也相鄰, 方便範圍查找

當然有缺點, 在Day9稍微提到過

這時候通常會對自身業務做業務拆分, 把原本冗於在單庫的表拆分到不同的業務資料庫中, 實現分而治之的資料管理跟讀寫操作.

這時會發生, 有些操作原本需要兩個不同業務的表做Join, 就無法了.
之後慢慢分享怎做, 或者原本的作法跟後來的作法的比較.

先講分庫跟分表.

分庫與分表

分庫具體就是Process甚至機器是獨立的, 分表則只是把資料做了冷熱分開放.

所以分庫能降低單台機器的負載, 像是CPU瓶頸, 網路連線數瓶頸, IO瓶頸等;
分表則是提高數據訪問的效率, 主要是解決IO瓶頸跟CPU瓶頸.

今天分享的都是分庫, 為的是降低單機的負載.

Partition vs Sharding

Partition分片, Sharding分區
兩個都有分而治之的核心概念.
差別在於Sharding是指資料分佈在多台機器節點上, 但Partition沒有.
這兩個名詞沒搞清楚, 之後就會混亂了XD

• Partition

• Sharding