schema設計，mongodbschema設計
Schema設計
Schema：表的模式；
設計數據的表，索引，以及表和表的關系
關系模型圖：
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設計與前瞻性
