本文更新于2021-12-11，使用MongoDB 4.4.5，
目錄- 范式化與反范式化
- 優化資料操作
- 一致性管理
- 模式遷移
范式化與反范式化
范式化（normalization）將資料分散到多個集合，不同集合之間相互參考資料，反范式化（denormalization）將每個檔案所需資料都嵌入檔案內部，
一個集合中包含的對其他集合的參考數量叫基數（cardinality），常見的關系有一對一、一對多、多對多，
內嵌資料與參考資料的比較：
| 更適合內嵌 | 更適合參考 |
|---|---|
| 資料較小 | 資料較大 |
| 資料不會定期改變 | 資料經常改變 |
| 最終資料一致即可 | 中間階段的資料必須一致 |
| 檔案資料小幅增加 | 檔案資料大幅增加 |
| 資料通常需要執行二次查詢才能獲得 | 資料通常不包含在結果中 |
| 快速讀取 | 快速寫入 |
| 基數較少 | 基數較多 |
也可以混合使用內嵌資料和參考資料：創建一個內嵌檔案用于保存常用資訊，需要查詢更詳細資訊時通過參考找到實際的檔案，
優化資料操作
更新資料時，需要明確是否會導致檔案體積增長，以及增長程度，如果檔案中有欄位需要增長，應盡可能將這個欄位放在檔案最后的位置，
有三種常見的方式用于洗掉舊資料：使用固定集合，使用TTL集合，使用多個集合并定期洗掉集合，
一致性管理
服務器為每個資料庫連接維護一個請求佇列，一個連接擁有一個一致的資料庫視圖，總時可以讀取到這個連接最新寫入的資料，
模式遷移
隨著需求的變化，資料庫模式可能需要相應地改變，不管使用以下哪種方法，都要小心保存應用程式使用過的每一個模式：
- 確保應用程式能支持所有舊版的模式，這種方式可能導致混亂，尤其是不同版本的模式之間有沖突時，
- 在每個檔案中包含一個類似“version”的欄位，使用這個欄位來決定應用程式接受的檔案結構，這仍然需要支持各種舊版本，
- 當模式發生變化時將資料進行遷移，通常來說這不是個好主意：MongoDB允許使用動態模式，以避免執行遷移，因為遷移會對系統造成很大的壓力，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/431459.html
標籤：其他
上一篇：mysql練習題emp,dept