注意事項
模式設計，即在檔案中表示資料的方式，對于資料表示來說時非常關鍵的，
為 MongoDB 做模式設計時，在性能、可伸縮性和簡單性方面是重中之重，也需要考慮一些特別的注意事項，
限制條件
與常見的 SQL 相比而言，MongoDB 有自己的限制條件：
- 檔案最大限制為 16M 大小
- 從磁盤讀寫完整檔案
- 更新會重寫整個檔案
- 在檔案級別進行原子更新
訪問模式
設計模式時最需要關注的就是資料庫的讀操作，在資料庫運行程序中，應盡量減少查詢的數量，這就需要在設計時確保一起查詢的資料存盤在同一個檔案中，
其實，就是考慮是否是否可以將動態（讀/寫）資料和靜態（主要是讀）資料分離開，如未經常使用的資料應該移到不同的集合中，
在進行模式設計時，提高最常見查詢的優先級會獲得最佳的性能，
關系型別
資料之間的關系影響著檔案之間應該是內嵌還是參考，
比如說，需要弄清楚如何在不執行其他查詢的情況下參考檔案，以及當關系發生變化時需要更新多少檔案，
關系基數對于檔案之間的關系非常重要，如一對一、一對多、多對多、一對百萬、多對百萬等等關系基礎，影響的程度差距非常大，應選取最佳格式去做建模，
在關系基數的基礎上，還需關注訪問的情況、重要資料更新與讀取的比例，這些充分考慮之后，將有助于確定應采用內嵌檔案還是參考檔案，
范式化和反范式化
基本概念
通常來說，多檔案之間的關系可以使用反范式化（內嵌）或范式化（參考），
范式化是指在檔案中參考外部資料的標識，同一份資料只存在一個地方，
在查詢時，查詢完整的資料需要做 JOIN 的操作，需要查詢多次才可能獲取到所需內容；但是在更改時僅需修改一處地方，不需要擔心破壞資料的完整性，
反范式化是指將外部資料復制一份存盤在檔案中，也就是說同一份資料存在多處地方，
在查詢時，只需查詢一次即可得到所需內容，查詢效率比較可觀；而在更改時，需要更新多處地方，可能會出現資料不一致的情況，不能保證完整性，
范式化選擇
決定何時采用范式化以及何時采用反范式化是比較困難的：通常，范式化的寫入速度更快，而反范式化的讀取速度更快，
通過判斷以下因素可決策選擇使用范式化還是反范式化：
| 更適合范式化 | 更適合反范式化 |
|---|---|
| 較大子檔案 | 較小子檔案 |
| 資料經常變更 | 資料不經常變更 |
| 資料要強一致 | 資料最終一致即可 |
| 檔案資料大幅增加 | 檔案資料小幅增加 |
| 資料通常不包含在結果中 | 資料通常需要執行二次查詢才能獲得 |
| 快速寫入 | 快速讀取 |
模型設計小技巧
指導原則
通常來說，具有類似模式的檔案應該保存在同一個集合中，
對于集合來說，需要考慮的一個大問題是鎖機制（每個檔案都有一個讀/寫鎖）和存盤，
當使用 --directoryperdb 選項時，每個資料庫都可以保留在自己的目錄中，這允許你將不同的資料庫掛載到不同的卷中，
同一個應用程式連接的資料庫可以根據業務進行劃分，也許可以將高價值的業務資料存盤在 SSD 上，或者是使用 RAID10 進行存盤，而低價值的資料可以存盤在 RAID0 上，
洗掉舊資料
有些資料只在短時間內比較重要，過了這段時間，保存這些資料只是再浪費存盤空間，
洗掉舊資料有 3 種常見的方式：使用固定集合、使用 TTL 索引、使用多個集合，
最簡單的方式是使用固定集合：將集合大小設定成一個較大的值，并讓舊資料從固定集合的末尾被“洗掉”，
第二種方式是使用 TTL 集合：TTL 集合可以更精確地控制洗掉檔案的時間，但其在寫入量過大的集合中操作速度不夠快，
最后一種方式是使用多個集合：例如每個月的檔案都單獨使用一個集合，
一致性管理
MongoDB 支持多種一致性級別，從總是能夠讀取自己所寫的資料到讀取不確定的舊資料，
其內部實作是服務器端為每一個資料庫連接都維護了請求佇列，同一個連接發來的請求都會被添加到佇列的末尾，連接中的任何后續請求都將依次得到處理，
這個管理方式涉及到多個客戶端連接會出現并發問題，在一個連接中插入檔案后，在另一個連接的后續查詢卻不一定會回傳這個檔案（實際上已經插入成功），
同樣的一致性問題在 MongoDB 擁有副本集時也會出現，副本節點的資料與主節點的資料總是會有時間差，高并發的請求同樣存在讀取到舊資料的風險，
MongoDB 提供了 readConcern 選項來控制被讀取資料的一致性和隔離性，它通常與 writerConcern 組合使用，以控制為應用程式提供的一致性和可用性保證：
如果 readConcern=local，從當前實體查詢并回傳結果，不能保證資料已經寫入大多數副本集成員，默認在主庫讀，如果本次讀取使用了 causally consistent 則在從庫讀，
如果 readConcern=available，從當前實體查詢并回傳結果，不能保證資料已經寫入大多數副本集成員，默認在從庫讀，并且此選項與 causally consistent 不能同時使用，
如果 readConcern=majority，查詢結果回傳被副本集的大多數成員確認的資料，讀操作回傳的檔案是持久化的，前提是 MongoDB 必須是 WiredTiger 存盤引擎，
如果 readConcern=linearizable，查詢可能會等待并發執行的寫操作傳播到大多數副本集成員，然后再回傳結果，
如果 readConcern=snapshot，這是適用于多檔案事務中的操作，通常情況下使用較少，
模式遷移
隨著應用程式的增長和需求的變化，資料庫模式也可能需要隨之增長和改變，理想情況下，如果可以的話，應該考慮使用檔案版本控制模式，
最簡單的方式是根據應用程式的需要改進資料庫模式，以確保應用程式支持所有的舊版模式，但是這種方式可能會導致混亂，特別是當不同版本的模式存在沖突時，
為了以一種更結構化的方式處理不斷變化的需求，可以在每個檔案中包含一個 version 欄位，并使用它來確定應用程式將接受的檔案結構，
最后一種方式是在模式變更時遷移所有資料，但這通常不是一個好主意：會給系統帶來壓力，還必須確保所有檔案都被更新成功，
模式管理
MongoDB 3.2 引入了模式驗證，其可以在更新和插入操作期間對資料進行驗證，
MongoDB 3.6 又通過 $jsonSchema 運算子添加了 JSON 模式驗證，現在這是 MongoDB 中所有模式驗證的推薦方法，
只有當檔案被更改時，驗證功能才會檢查這些檔案，并且此功能是每個集合都需要單獨配置的，
要向現有集合添加驗證功能，可以在 collMod 命令中使用 validator 選項，在使用 db.createCollection() 時，可以通過指定 validator 選項將驗證添加到新集合中，
MongoDB 還提供了兩個額外的選項：
validationLevel: 決定了在更新程序中驗證規則對現有檔案檢查的嚴格程度validationAction: 決定了是應該在發生錯誤時拒絕請求，還是允許請求并發出警告
當然，更詳細的相關內容可以查看 官方檔案，
撰寫代碼來處理資料完整性問題
為保證 MongoDB 資料的完整性，有可能需要在應用程式中增加必要的邏輯代碼進行處理，也需要增加定時任務來保持資料的一致性，
有可能需要有以下的任務：
- 一致性修復程式：檢查計算和重復資料以確保每個人都具有一致的值
- 預填充器：創建將來需要的檔案
- 聚合：保持行內聚合為最新
- 架構檢查器：確保當前使用的檔案集都具有一組欄位，可以自動更正它們
- 定時備份：定期鎖定和轉儲資料庫
首發于「程式員翔仔」，點擊查看更多，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/540769.html
標籤：其他