AI Skills
mongodb-schema-design

mongodb-schema-design

熱門

MongoDB 資料庫綱要設計模式與反模式。用於設計資料模型、審查綱要、從 SQL 遷移，或排除因綱要問題導致的效能問題。觸發關鍵字：「設計綱要」、「嵌入 vs 參考」、「MongoDB 資料模型」、「綱要審查」、「無界陣列」、「一對多」、「樹狀結構」、「16MB 限制」、「綱要驗證」、「JSON Schema」、「時間序列」、「綱要遷移」、「多型」、「TTL」、「資料生命週期」、「封存」、「索引爆炸」、「不必要的索引」、「近似模式」、「文件版本管理」。

161星標
29分支
更新於 2026/7/20
獲取技能源代碼

相關技能

recsys-pipeline-architect24萬context-window-management4.6萬brainstorming4.5萬
SKILL.md
唯讀
名稱
mongodb-schema-design
描述

MongoDB 資料庫綱要設計模式與反模式。用於設計資料模型、審查綱要、從 SQL 遷移，或排除因綱要問題導致的效能問題。觸發關鍵字：「設計綱要」、「嵌入 vs 參考」、「MongoDB 資料模型」、「綱要審查」、「無界陣列」、「一對多」、「樹狀結構」、「16MB 限制」、「綱要驗證」、「JSON Schema」、「時間序列」、「綱要遷移」、「多型」、「TTL」、「資料生命週期」、「封存」、「索引爆炸」、「不必要的索引」、「近似模式」、「文件版本管理」。

MongoDB 綱要設計

由 MongoDB 維護的資料建模模式與反模式。不良的綱要是大多數 MongoDB 效能與成本問題的根源——查詢與索引無法修補根本錯誤的模型。

何時套用

在以下情況參考這些指南：

  • 從頭設計新的 MongoDB 綱要
  • 從 SQL/關聯式資料庫遷移至 MongoDB
  • 審查現有資料模型的效能問題
  • 排除慢查詢或文件大小持續增長的問題
  • 決定嵌入或參考
  • 建模關係（一對一、一對多、多對多）
  • 實作樹狀/階層結構
  • 看到 Atlas 綱要建議或效能顧問警告
  • 達到 16MB 文件限制
  • 為現有集合新增綱要驗證

快速參考

1. 綱要反模式 - 3 條規則

  • antipattern-unnecessary-collections - 將同質資料拆分到多個集合通常是反模式；請參考此文件確認是否為此情況。
  • antipattern-excessive-lookups - 遇到過度正規化且互相參考的集合，或頻繁且可能緩慢的 $lookup 操作時，請參考此文件確認問題所在及如何修正。
  • antipattern-unnecessary-indexes - 當索引重疊或未被查詢使用時，請參考此文件識別並移除不必要的索引，這些索引只會增加負擔而無效益。

2. 綱要基礎 - 4 條規則

  • fundamental-embed-vs-reference - 參考此文件了解不同關係類型（1:1、1:少數、1:多數、多:多、樹狀/階層資料）的建模方法，以及如何根據存取模式決定嵌入或參考。
  • fundamental-document-model - 文件模型的基礎。從 SQL 或其他正規化資料遷移至 MongoDB 等文件資料庫時，請參考此文件。
  • fundamental-schema-validation - 建立新集合或為現有集合新增驗證時（例如因發現不一致的文件結構或資料品質問題），請參考此文件。
  • fundamental-document-size - 當文件達到 16MB 硬限制，或因文件過大導致存取比預期慢時，請參考此文件。

3. 設計模式 - 11 條規則

存取模式分析

不要未了解整體脈絡就立即建議模式或綱要變更。與使用者一起分析存取模式，找出痛點與最佳化機會。

工作流程

步驟 1：評估環境
詢問使用者：

  • 這是全新設計，還是已有生產資料庫及現有存取模式可分析？
  • 如果有生產資料，是否在 Atlas 上？若是，是哪個層級？（M0/M2/M5 或 M10+）

步驟 2：確定工作負載類型
工作負載是讀取密集型、寫入密集型還是平衡型？這會影響哪些診斷來源最相關。
詢問使用者：

  • 這些集合的主要工作負載是什麼——讀取密集型（分析、報表、搜尋）、寫入密集型（日誌、IoT 資料擷取、頻繁更新），還是平衡型？

透過 db.serverStatus().opcounters 驗證。

步驟 3：與使用者合作選擇最佳來源
根據情況推薦最佳來源，並說明取捨。對於綱要設計決策，通常需要結合多個來源才能獲得完整圖像。

步驟 4：進行分析
只有在選定來源後，才擷取資料或引導使用者進行分析。

來源
  • 查詢統計 - 回傳記錄查詢的執行時期統計資料，顯示查詢形狀與頻率。限制：目前僅擷取讀取操作（需搭配其他來源以了解寫入模式）。需要 Atlas M10+ 層級。
  • Atlas 慢查詢日誌 - 檢視慢查詢（實際查詢，非形狀）以識別效能瓶頸。擷取所有讀取與寫入。需要 Atlas M10+ 層級。
  • 程式碼庫 - 檢查應用程式程式碼中的實際查詢以了解存取模式，特別適用於新應用程式或工作負載變更時。可與查詢統計搭配使用以獲得更完整的圖像。
  • 自然語言輸入 - 請使用者以自然語言描述其典型查詢與存取模式。可作為唯一來源，或補充與驗證其他來源——使用者可能擁有資料或程式碼庫中未反映的脈絡知識。

結合查詢統計與慢查詢日誌：

兩者一起使用以進行全面分析：

  1. 查詢統計 → 識別頻繁的存取模式（哪些查詢最常執行）
  2. 慢查詢日誌 → 識別效能瓶頸（哪些查詢較慢）
  3. 將綱要最佳化重點放在既頻繁又慢的查詢上（影響最大）

關鍵原則

「一起存取的資料應該一起儲存。」

這是 MongoDB 的核心哲學。嵌入相關資料可消除聯結、減少往返次數，並實現原子更新。只有在必要時才參考。

實作此哲學的核心方式是 MongoDB 提供彈性綱要。這表示您可以在不同文件中擁有不同欄位，甚至不同結構。這讓您可以根據存取模式以最佳方式建模資料，而不受僵化綱要的限制。例如，如果不同文件有不同的欄位集合，只要符合應用程式需求，就完全沒問題。您也可以使用綱要驗證來強制執行某些規則，同時仍保有彈性。

關鍵原則的另一個含義是，預期的讀取與寫入工作負載資訊對綱要設計變得非常重要。如果來自不同實體的資訊經常一起查詢或更新，那麼優先將這些資料共置於同一文件中，可以帶來顯著的效能優勢。另一方面，如果某些資訊很少一起存取，則可能應該分開儲存，以避免載入不必要的資料。

綱要基礎摘要
  • 嵌入 vs 參考：根據存取模式選擇嵌入或參考：當資料總是同時存取時嵌入（1:1、1:少數、有界陣列、需要原子更新）；當資料獨立存取、關係為多對多，或陣列可能無界增長時參考。
  • 一起存取的資料一起儲存：MongoDB 的核心原則：圍繞查詢而非實體設計綱要。嵌入相關資料以消除跨集合聯結並減少往返次數。識別您的 API 端點/頁面，列出每個端點回傳的資料，然後塑造文件以符合這些查詢。
  • 擁抱文件模型：不要將 SQL 表格 1:1 重新建立為 MongoDB 集合。相反地，將聯結的表格反正規化為豐富的文件，以實現單一查詢讀取與原子更新。從 SQL 遷移時，識別總是聯結在一起的表格，並將它們合併為單一文件。
  • 綱要驗證：使用 MongoDB 內建的 $jsonSchema 驗證器在資料庫層級捕捉無效資料（型別檢查、必填欄位、列舉約束、陣列大小限制）。對現有集合從 validationLevel: "moderate" 和 validationAction: "warn" 開始，然後收緊為 strict/error。
  • 16MB 文件限制：MongoDB 文件不能超過 16MB——這是硬限制，而非指南。常見原因：無界陣列、大型內嵌二進位資料、深度巢狀物件。透過將無界資料移至獨立集合，並使用 $bsonSize 監控文件大小來緩解。

嵌入/參考決策框架

關係 基數 存取模式 建議
一對一 1:1 總是同時 嵌入
一對少數 1:N (N < 100) 通常同時 嵌入陣列
一對多數 1:N (N > 100) 經常分開 參考
多對多 M:N 視情況 雙向參考

這是粗略指南，是否嵌入或參考取決於您的特定存取模式、資料大小與讀寫頻率。務必根據實際工作負載驗證。

如何使用

上述每個參考檔案都包含詳細說明與程式碼範例。使用快速參考中的描述來識別哪些檔案與您目前的任務相關。

每個參考檔案包含：

  • 為何重要的簡要說明
  • 錯誤的程式碼範例與說明
  • 正確的程式碼範例與說明
  • 「何時不該使用」的例外情況
  • 效能影響與指標
  • 驗證診斷

這些規則如何運作

MongoDB MCP 整合

如需自動驗證，請連接 MongoDB MCP Server。

如果 MCP 伺服器正在執行且已連線，我可以自動執行驗證命令來檢查您的實際綱要、文件大小、陣列長度、索引使用情況、慢查詢日誌等。這讓我能根據您的真實資料（而不僅是程式碼模式）提供量身訂做的建議。

⚠️ 安全性：使用 --readOnly 以確保安全。僅在需要寫入操作時才移除。

連線後，我可以自動：

  • 透過 mcp__mongodb__collection-schema 推斷綱要
  • 透過 mcp__mongodb__aggregate 測量文件/陣列大小
  • 透過 mcp__mongodb__db-stats 檢查集合統計資料

⚠️ 行動政策

未經您明確同意，我絕不會執行寫入操作。

在透過 MCP 執行任何寫入或破壞性操作之前，我將：(1) 總結確切操作（集合、索引/驗證器、估計受影響文件數），以及 (2) 要求明確確認（是/否）。我不會在部分或模糊的同意下繼續執行。

操作類型 MCP 工具 行動
讀取（安全） find、aggregate、collection-schema、db-stats、count 我可自動執行以驗證
寫入（需核准） update-many、insert-many、create-collection 我會顯示命令並等待您說「是」
破壞性（需核准） delete-many、drop-collection、drop-database 我會警告您並要求明確確認

當我建議綱要變更或資料修改時：

  1. 我會說明要做什麼及為什麼
  2. 我會顯示確切命令
  3. 我會等待您的核准後才執行
  4. 如果您說「請繼續」或「是」，我才會執行

您的資料庫，您的決定。 我在這裡提供建議，而非單方面行動。

共同合作

如果您對某項建議不確定：

  1. 執行我提供的驗證命令
  2. 與我分享輸出結果
  3. 我會根據您的實際資料調整建議

我們是團隊——一起把事情做對。