Schema設計

Schema：表的模式；
 
設計數據的表，索引，以及表和表的關係

1. 在數據建模的基礎上將關係模型轉爲數據庫表
2. 知足業務模型須要基礎上根據數據庫和應用特色優化表結構

 
關係模型圖：

 

 

Schema關係到應用程序功能與性能

• 知足業務功能需求
• 同性能密切相關
• 數據庫擴展性
• 知足周邊需求（統計，遷移等）

 
關係型數據庫修改Schema常常是高危操做
     Schema設計要體現必定的前瞻性
 
徹底由開發者主導的Schema設計

• 着眼於實現當前功能
• 徹底基於功能的設計可能存在一些隱患
• •    不合理的表結構或索引設計形成性能問題
  •    沒有合理評估到數據量的增加形成空間緊張並且難以維護
  •    需求頻繁修改形成表結構常常變動
  •    業務重大調整致使數據常常須要重構訂正

 
基於性能的表設計

• 根據查詢須要設計好索引
• 根據核心查詢需求， 適當調整表結構
• 基於一些特殊業務需求，調整實現方式

 
索引

• 正確使用索引
• 更新儘量使用主鍵或惟一索引
• 主鍵儘量使用自增ID字段
• 核心查詢使用覆蓋索引
• •           用戶登陸須要根據用戶名返回密碼用於驗證
  •           create index idx_uname_passwd on tb_user (username,passwd);
  •           創建聯合索引避免回表取數據

 
 
設計舉例
 
1 反範式，冗餘必要字段


2 拆分大字段

 

3 避免過多字段或過長行
 
 
4 分頁查詢：

 
 
 5  熱點讀數據特殊處理


 
 
 6 熱點寫數據特殊處理

 

 

7 準實時統計

 

實時統計改進1--觸發器實時統計

 

實時統計改進2-緩存實時統計

 

實時統計改進3-最大自增ID獲取總數

 

 
8  可擴展性設計

 

9 分區表與數據淘汰
range分區

 

list分區

 

hash分區


 
10 知足周邊需求


統計和後臺需求


11 自動更新時間戳

 
Schema設計與前瞻性

• 基於歷史經驗教訓，預防和解決同類問題
• 把折騰DBA夠嗆的索引Schema改造的緣由記錄並分析總結

例子：
業務爲了用戶信息加密作了大改造

•  數據庫結果大量改動，增長了加密字段，驗證策略表，全部表從新訂正數據等等
•  是否全部用到用戶信息管理的應用都要去上線就用密文？

 

 總結

 

•  schema設計關係性能
•  反範式，冗餘必要字段
•  拆分大字段
•  避免過多字段或過長字段
•  分頁查詢
•  熱點讀數據特殊處理：置頂表與普通表分開
•  熱點寫數據特殊處理：
• • 微博普通用戶發消息，則寫入關注他的人的消息列表中；微博大V發消息，則關注他的人都去讀他的消息列表；
•  準實時統計：
• • 定時統計表，更據上次更新時間統計全表中增量sum值，每分鐘更新統計表；
•  實時統計：
• • 觸發器實時統計，在用戶插入時，更新統計表；
  • 緩存實時統計，應用將用戶新增寫在內存緩存中，業務平時從緩存中讀，緩存失效，從數據庫作一次查詢，接着寫在緩存；
• 分區表與數據淘汰
• 知足周邊需求：
• • 如後臺統計任務而增長特殊索引，
  • 爲數據遷移或統計增長時間戳
• 自動更新時間戳
• schema設計與前瞻性