MongoDB 多租戶架構設計：集合策略與效能考量

業務場景

平台面向個人開發者，每位開發者可自建多個集合，並透過公共 REST API 對自己的集合進行 CRUD。預期有成千上萬開發者，各自擁有多個集合，資料量極大。

兩種直觀方案的缺點

1. 單一大集合存放所有使用者資料：需額外欄位區分租戶，查詢需加租戶過濾，單一集合體積龐大，索引維護成本高，熱點資料競爭嚴重。
2. 每個自訂集合對應一個 MongoDB 集合：集合數量爆炸性增長，超過 MongoDB 單一資料庫集合數限制（預設約 24,000），元資料管理負擔重，連線池與快取效率下降。

推薦架構：多租戶設計模式

關鍵字 Multi-tenant MongoDB 有成熟解決方案，常見策略包括：

• 資料庫級隔離：每位租戶獨立資料庫，利用 MongoDB 的資料庫層級權限控管，物理隔離最徹底，適合資料敏感度高、租戶數較少的場景。
• 集合級隔離 + 前綴命名：在同一資料庫內，以 tenantId_collectionName 命名集合，配合權限驗證邏輯，平衡隔離度與管理成本。
• 共用集合 + 租戶欄位 + 部分索引：所有租戶資料存同一集合，建立 tenantId 部分索引，查詢自動命中，適合租戶數極多、單租戶資料量較小的 SaaS 應用。
• 混合策略：大租戶獨立資料庫/集合，長尾租戶共用集合，依業務彈性調整。

關鍵實作細節

• 應用層攔截器自動注入 tenantId 至查詢條件，防止跨租戶資料洩漏。
• 使用 MongoDB changeStream 或觸發器實現審計日誌。
• 針對熱門租戶配置專屬讀寫副本集，保障 SLA。

建議深入搜尋 Multi-tenant MongoDB 相關最佳實踐，結合業務特性選型，而非單純在兩種極端方案中掙扎。