MongoDB Schema 設計系列 (一)：Workflow 與核心設計原則
這篇是從我的 Medium 搬過來的 MongoDB University Data Modeling 上課筆記。
當初在工作上做資料分析和算法開發時，發現資料儲存的格式和實際被使用的方式差異很大，導致分析工作有過半時間耗費在資料的存取與整理上。為了解決這個痛點，我開啟了優化計劃，並在 MongoDB 社群中找到了更適合的 Schema 設計。
這次經驗讓我深刻體會到 Schema 設計對系統效能與維護成本的巨大影響，因而促使我到 MongoDB University 進修，深入研究如何系統化地設計 Schema。這系列文章就是我的學習筆記與心得分享。
什麼是 Data Modeling？
簡單來說，Data Modeling 就是找出適合 Application 的資料儲存方式，這其中包含了定義資料類型以及不同類型資料之間的關聯。
整個建模的過程主要包括：
- 了解應用場景以定義資料類型
- 定義關係與關聯方式
- 評估 Workload
- 透過 Design Pattern 解決效能瓶頸
1. 了解應用場景來定義資料類型
例如在社交平台中，使用者可以發布文章。這時我們能確定需要儲存兩種資料類型（Entity）：使用者 與 文章。至於具體的欄位，則是由應用程式的實際需求來決定需要記錄哪些資訊。
2. 定義關係與關聯
在實體關係（Entity Relationship）中，關係主要分為三種：
- 1 to 1（一對一）
- 1 to many（一對多）
- many to many（多對多）
以 使用者 與 文章 為例，它們是 1 to many 的關係，因為一位使用者可以發表多篇文章，而每篇文章只屬於一位使用者。明確定義這些關係有助於我們評估實體之間該如何建立連結。
在 MongoDB 中，資料關聯主要有兩種實作方式：
- Embedding（嵌入）：將一個 Document 直接嵌套在另一個 Document 內部。
- Referencing（引用）：透過特定欄位（如 ID）來建立兩份 Document 之間的關聯。
這兩種方式各有優缺點與適合的場景，釐清 Entity 之間的關係能引導我們做出更好的架構選擇。
3. 評估 Workload
在確定了 Entity 與應用場景後，我們需要評估 Workload。例如：預估一年會產生多少資料儲存空間？網路傳輸流量的負載有多大？這項評估能幫助我們精確預測系統成本以及硬體所需的承載能力。
4. 透過 Pattern 解決問題
當走完前面的步驟後，不論怎麼調整 Schema 設計，如果依然發現某些特定場景的查詢效率很差，這時就像寫程式有 Design Pattern 一樣，Schema 設計同樣有對應的 Pattern 可以套用來優化性能（這部分我會在之後的文章詳細介紹）。
核心設計原則 (Modeling Principle)
在 MongoDB 的資料建模中，我認為最重要的只有以下兩點原則：
- 從簡單的設計開始，切忌過度設計 一切都先從最簡單的 Schema 開始。實務上，將簡單的 Schema 轉換成複雜的設計相對容易，但要把過度設計的複雜 Schema 簡化則非常困難。
- 常在一起出現的資料盡量放在一起 如果某些資料經常需要同時讀取，應儘量將它們設計在同一個 Document 中，否則會導致資料庫頻繁在多個資料表之間進行關聯（Join）查詢，這不僅沒有效率，也會消耗額外的運算成本。