注意事項

模式設計，即在文檔中表示數據的方式，對于數據表示來說時非常關鍵的。

為 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 數據的完整性，有可能需要在應用程序中增加必要的邏輯代碼進行處理，也需要增加定時任務來保持數據的一致性。

有可能需要有以下的任務：

• 一致性修復程序：檢查計算和重復數據以確保每個人都具有一致的值
• 預填充器：創建將來需要的文檔
• 聚合：保持內聯聚合為最新
• 架構檢查器：確保當前使用的文檔集都具有一組字段，可以自動更正它們
• 定時備份：定期鎖定和轉儲數據庫