資料庫的問題

遇上的資料庫相關效能處理問題，處理方式記錄。

讀寫分離架構

master : 主要用寫的服務，會與 slave進行資料同步。
slave : 主要用來讀的服務。

• 適用於讀多寫少情況。

分表

• 時機: 單表資料量太大讀寫遇上瓶頸，增加slave、優化索引仍然無法解決時。

分庫

• 時機: 單機讀寫遇上瓶頸，增加slave、優化索引仍然無法解決時。
• 目的就在於減少單台資料庫讀寫的負擔，縮短查詢時間。

DB遇上瓶頸，初步判斷各種可能的解決方法

• IO
  • 磁盤讀IO瓶頸，熱點資料太多，資料庫cache放不下，每次查詢時會產生大量的IO，降低查詢速度。
    • 圖片、檔案、影片等不存資料庫，降低負擔(檔案放入Amazon S3、FTP server等做存取，DB只做該檔案資料純文字索引)。
    • 讀寫分離
    • 另外架cache server 降低資料庫負擔(eg. Redis)。
    • 分庫和垂直分表
  • 網絡IO瓶頸，請求的資料太多，網絡帶寬不夠
    • 減少一次請求的資料(這比較實際，有些工程師為了方便一次性查詢把所有資料查回來，但該階段根本用不到的資料(圖片、影片等單次請求)也一起回來了)
    • 分庫
• CPU
  • SQL問題，如SQL中包含join，group by，order by，非索引字段條件查詢等，增加CPU運算的操作
    • 建立合適的索引，在Application layer進行計算(不透過資料庫處理複雜運算)。
  • 單表資料量太大，查詢時掃描的行太多，SQL效率低，增加CPU運算的操作
    • 水平分表(使用者人數多的時候有機會遇到，根據資料熱點區間分散)。

總結

須根據系統實際狀況處理，沒有一定法則。
以下是過取處理案子時的處理方式:

• 選擇處理方案優先序:
  1. Application layer(應用程式問題)
  2. 檔案相關IO
  3. 快取設計(資料預熱、增加快取Server)、 獨立資料表、靜態常數化(該資料為常用資料)
  4. 讀寫分離(主要調整資料庫設定)
  5. 分區(Partition， 分割資料表，與水平分表(針對資料創資料表)類似但有不同，針對資料內容經由資料庫創建資料的分區，例如: 1~100 1區)
  6. 分表
  7. 分庫
  8. 分庫分表(最不得以的情況，通常這調整幅度比較大，包含資料庫和應用程式的調整)

參考: 資料庫層的擴展 - 讀寫分離架構
參考: 資料庫層的擴展 - 分庫分表架構
參考: 數據庫怎麼分庫分表，垂直？水平？
參考: 資料庫分庫分表，何時分？怎樣分？