教學路線：Document shape 與 schema governance

MongoDB 服務頁的教學目標是把 document model、schema flexibility、index、aggregation pipeline 與 sharding 放回資料形狀治理。讀者讀完後要能判斷資料是否適合 aggregate root，並知道 schema governance 如何影響長期維護成本。

定位：JSON document + 跨雲彈性

MongoDB 是以 document model 為主體的 DB。PostgreSQL JSONB 適合「SQL 為主、少量半結構化欄位」；MongoDB 則把 BSON document、aggregation pipeline、database sharding 與 schema governance 放在核心設計裡。近年版本加入 time series、change streams、queryable encryption、CSFLE 等能力。

選 MongoDB 的核心訴求：document model 是主要 use case、需要跨雲 managed（Atlas）、想避免 vendor lock-in（也可自管）。

容量特性

單一 instance 吞吐：

• 一般 m5.4xlarge：5K-15K WPS（依 doc size、index）
• 高階 instance + tuning：30K-50K WPS
• 超過此級別 → sharding

Sharding：

• MongoDB 原生支援 sharded cluster
• mongos router + config servers + shard
• MongoDB sharding 要主動設計 shard key，並和 Hot Partition 風險一起看

Replication：

• Replica set（primary + secondary、async）
• 跨 region 通常 async
• 自動 failover < 30 秒（mongod 內建）

Storage：

• 單一 collection 沒有官方上限、但 shard key resharding 過去版本是大手術（4.4+ 支援 reshardCollection）

適用場景

1. Document model 主要 workload：

• schema 變化頻繁的早期產品
• nested document 自然表達領域模型（訂單含多個 item、用戶含多個 preference）
• 對應案例：9.C30 Microsoft 365 — 從 MongoDB 遷移到 Cosmos DB MongoDB API、保留 document model

2. Aggregation pipeline 重 workload：

• 複雜的 $group / $match / $project chain
• 報表、analytics、ETL prep
• 比 RDBMS 寫複雜 query 更直觀（對某些 team）

3. 跨雲 managed（Atlas）：

• MongoDB Atlas 跨 AWS / GCP / Azure
• 跟 DynamoDB（AWS only）、Cosmos DB（Azure only）、Spanner（GCP only）相反
• 適合多雲策略、避免單一 vendor lock-in

4. Time series workload（6.0+）：

• time series collection 專屬優化
• 不過 InfluxDB / TimescaleDB 仍是更專業選擇

5. 已有 MongoDB 生態 + 想轉移操作責任：

• Atlas 提供 backup、failover、monitoring、auto-scale
• 想把 MongoDB DBA / SRE 操作責任交給 Atlas

不適用場景

1. 強 ACID multi-document transaction：

• MongoDB Transaction 支援多 document、但跨 shard 有性能影響
• 高頻金融交易仍建議 SQL 系統
• 替代：PostgreSQL、Aurora、Spanner

2. 複雜 JOIN：

• MongoDB $lookup 適合少量相鄰資料，JOIN-heavy workload 應回 SQL 系統
• schema design 階段要把常用讀取路徑 denormalize 成 document shape
• 替代：SQL 系統做 JOIN-heavy workload

3. 純 KV + sub-ms latency：

• MongoDB document model 比 KV 多一層 BSON parsing
• 替代：Redis、DynamoDB、Bigtable

4. 大規模 OLAP：

• aggregation 對中等資料量還行、TB 級不適合
• 替代：ClickHouse、BigQuery、Spark on Delta Lake

5. 嚴格資料模型 + schema enforcement：

• MongoDB schema flexibility 可能導致 production data inconsistency
• 替代：SQL DB（schema 強制）+ JSONB column 處理半結構化

跟其他 vendor 的取捨

vs Cosmos DB MongoDB API：

• MongoDB Atlas：跨雲、原生 MongoDB 行為
• Cosmos DB MongoDB API：Azure-only、global distribution + 5 consistency levels
• 選 MongoDB Atlas：跨雲、需要原生 MongoDB features
• 選 Cosmos DB：Azure 生態、需要更好 global distribution
• 對應案例：9.C30 Microsoft 365 — 從 MongoDB 遷到 Cosmos DB MongoDB API，主要保留 document model

vs DynamoDB：

• MongoDB：document model、aggregation 強、跨雲
• DynamoDB：KV / single-table design、AWS 整合、5 個 9 SLA
• 選 MongoDB：document 為主、跨雲
• 選 DynamoDB：KV 為主、AWS 生態
• 詳見 DynamoDB vendor page 對比段

vs PostgreSQL JSONB：

• MongoDB：document 為主、schema-less
• PostgreSQL：SQL 為主、JSONB 補充
• 選 MongoDB：document 占主要 schema
• 選 PostgreSQL JSONB：主要結構化、少量半結構化欄位

vs Couchbase / Couchdb / Firestore：

• Couchbase：MongoDB 替代、有 N1QL（SQL-like）
• CouchDB：偏小規模、master-master replication
• Firestore：GCP-only、realtime updates
• MongoDB 在這群裡是生態最廣的

vs Elasticsearch 作為 search 替代：

• 兩者分屬不同類別：MongoDB 是 OLTP / document、Elasticsearch 是 search + analytics
• 通常搭配用：MongoDB 主、Elasticsearch 處理 full-text search

容量規劃要點

1. Shard key 設計是命脈：

• 跟 DynamoDB partition key 同樣關鍵
• 不均勻 → hot shard、實際容量達不到名義
• 4.4+ 可以 reshard、但仍是大手術

2. Replica set 是 HA 基礎：

• 至少 3 個 member（1 primary + 2 secondary）
• secondary 可 read（read preference）但要注意 lag
• failover 通常 < 30 秒

3. Atlas managed 服務：

• 提供 auto-scaling、auto-backup、跨雲部署
• Tier 從 M0（free）到 M700（高階）
• Atlas Online Archive 自動把舊資料移到便宜 storage

4. Index 限制：

• 單 collection 最多 64 個 index
• compound index 有順序敏感（{a:1, b:1} 跟 {b:1, a:1} 不同）
• TTL index 自動 expire 過期 document

5. Change streams（CDC）：

• 4.0+ 提供原生 change streams
• 對接 Kafka / event bus 做 event sourcing

Anti-recommendation 與升級路由

MongoDB 的 schema flexibility 會降低早期建模成本，也會把 schema governance 延後到 production。這一段先說何時維持 document model，再說何時升級 Atlas、sharding、Cosmos DB、DynamoDB 或 SQL。

MongoDB 的簡單路徑是先把 document boundary 寫清楚。資料可以彈性演進，但 application 仍要知道哪些欄位是正式契約、哪些欄位只是相容期，並用 validation、migration 與 data quality check 管住版本漂移。

Sharding 的升級路徑要等 shard key 與 query shape 足夠穩定。過早切 shard 會把 aggregation、transaction 與 index 成本提前放大；過晚切 shard 則會讓 resharding、chunk migration 與 balancer 壓力進入 production 高峰期。

Deep article（已完成）

本批 6 篇 deep article 已完成、覆蓋 MongoDB 從 schema 設計到 production 跨層架構的核心 production 議題：

跨 vendor entry：先看 DB3 vendor selection（MongoDB / DynamoDB / Cosmos DB 三方選型 + workload shape 前置判讀），再進本 vendor 的 deep article。

後續擴充（仍待補）

• Index 設計跟覆蓋
• 從自管 MongoDB 遷到 Atlas
• 從 MongoDB 遷到 Cosmos DB MongoDB API（保留 document model）
• 從 MongoDB 遷到 DynamoDB（access pattern 需要重設計）
• Queryable encryption（CSFLE）

案例對照

MongoDB case 的讀法分三組：

• 作為 production 主角持續演進（Coinbase、Toyota Connected）：document model 撐住核心 OLTP / IoT、配 connection proxy / cache / event-driven 處理擴展周邊。
• 自管 → managed 遷移（Forbes）：同 document model、換託管模式、ROI 集中在 DBA 責任轉移跟跨雲彈性、不是性能改善。
• 遷出 MongoDB 保留 API（Microsoft 365）：document model 保留、底層換到 Cosmos DB MongoDB API、換取 Azure global distribution。

讀 case 時要區分 MongoDB 在「主角 / 遷入 / 遷出」三種位置的差異，三種位置揭露的工程議題完全不同。

常見陷阱

• schema 長期 schema-less：production 出現 data inconsistency、難 query
• shard key 用 _id（自增）：寫入全集中在最後一個 shard
• $lookup 過度使用：跨 collection JOIN-heavy workload 應在 schema design 時 denormalize 或回 SQL
• index 太多：寫吞吐被拖垮、定期 review 未用 index
• secondary read 不檢查 lag：用戶讀到 stale data
• 不規劃 Atlas tier upgrade 路徑：流量上來才發現 tier 跟不上、緊急升級費用高

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：Cosmos DB vendor（MongoDB API replacement）、DynamoDB vendor（KV alternative）
• 上游：1.2 schema design、1.10 KV / Document DB 容量規劃
• 下游：1.12 大規模 DB 遷移實戰（MongoDB 遷出範例）
• 跨模組：9.6 容量規劃模型、9.4 Saturation Discovery（shard key 跟 hot shard）
• 官方：MongoDB Manual、MongoDB Atlas

官方文件路由：Firestore documentation、Firestore data model、Firestore pricing；本頁時間敏感的計費與限制 claim 以官方為準、最後檢查日 2026-06-16。

教學路線：client 直連的 document 正式狀態

Firestore 服務頁的教學目標是把「前端直接讀寫資料庫」這個存取模型的責任說清楚。讀者讀完後要能判斷 Firestore 何時是合適的正式狀態，何時因為查詢形狀、成本曲線或授權複雜度該轉向自建後端配 PostgreSQL 或留在 document model 換 MongoDB。

定位：serverless document store + BaaS 資料層

Firestore 跟 MongoDB、DynamoDB 同屬 NoSQL document / KV 家族，但承擔的責任層級不同：

• 資料組織成 collection 下的 document，document 可巢狀 subcollection，單 document 上限 1 MiB
• 沒有 server 端 JOIN，跨 collection 的關聯要靠 application 多次查詢自己組、或在寫入時反正規化
• 存取模型以 client SDK 直連為主，授權寫在 Security Rules（一套規則 DSL），而不是後端 API 的權限中介層
• 兩種營運模式：Firestore Native mode（行動 / web、含 realtime 與 offline）與 Datastore mode（server 端、相容舊 Datastore）

傳統定位：Firebase 行動 app 與 SPA 的後端資料層、MVP 快速驗證期、多裝置即時同步的產品。

資料層視角的定位：一塊 managed serverless document store，把 capacity、replication、failover、scaling 全部交給平台，代價是查詢能力與資料模型沿平台特性生長。

資料形狀與查詢邊界

Firestore 為「已知路徑的 document 讀寫」付成本，不為「任意欄位的 ad-hoc 查詢」付成本。這個取向決定了它的甜蜜區與牆：

• 單 document 與單 collection 內的 key-based / 條件查詢高效，且每筆查詢都要有對應 index（單欄 index 自動建立、複合查詢要建 composite index）
• 查詢結果集的計費與大小跟「讀了幾筆 document」成正比，不是跟「掃了多少」— 一次回 10,000 筆就計 10,000 次 read
• 缺少 server 端 aggregation pipeline 與 JOIN；跨集合報表（例如「本月各地區訂單金額」）在 Firestore 上要嘛預先把彙總寫成一份 document、要嘛把資料複製到分析系統
• 沒有原生全文搜尋，全文需求要接專門的 search index（Algolia、Elasticsearch / OpenSearch）

這條查詢邊界是 Firestore 最容易被低估的設計約束。它不是「功能還沒做」，而是 client 直連 + serverless 計費模型的必然結果：把任意 ad-hoc 查詢開放給前端，等於把不可預測的成本與掃描壓力暴露在公網。建模時要先窮舉 access pattern、再決定 document 結構，跟 DynamoDB single-table design 的 access-pattern-first 思路同源。

一致性、realtime 與容量特性

一致性：

• 單 document 讀寫與「查詢結果在同一 region 內」提供 strong consistency
• 多 region 部署靠平台複製、跨 region 讀取可能有延遲；一致性語意由平台決定、不可調到自管資料庫那種 isolation level 顆粒

Realtime 與 offline：

• snapshot listener 讓 client 訂閱 query 結果、資料變更即時推送，是多裝置同步的核心能力
• 行動 / web SDK 內建 offline persistence，斷線時讀寫本地快取、回線後同步，這是自建 REST API 要額外工程才有的能力

容量與寫入熱點：

• serverless 自動擴縮，無 connection 概念，前端裝置數不直接轉成資料庫連線壓力
• 單一 document 的高頻寫入會撞到 contention（官方建議單 document 的持續寫入維持在每秒個位數量級、高頻計數器要用 distributed counter 分片）
• 寫入吞吐與索引維護成本綁在一起：每多一個 index、寫入就多一份維護成本

容量特性的時間敏感數字（每秒寫入軟上限、單 document contention 門檻）以 官方 best practices 為準，設計高頻寫入前先查當前限制。

適用場景

1. 行動 app / SPA 的 MVP 後端：

• 認證接 Firebase Auth、資料存 Firestore、推播接 Cloud Messaging，整個 MVP 沒有自己的後端服務
• 對應 0.21 BaaS 段的「把後端工程師這個角色延後」

2. 多裝置即時同步：

• 協作筆記、聊天、即時看板這類「一處改、多處即時更新」的產品
• snapshot listener + offline persistence 是這類需求的天然形狀

3. access pattern 穩定的 document 工作負載：

• user profile、設定、feed item、活動紀錄這類讀多寫少、查詢路徑固定的資料
• 跟 source of truth 對齊：Firestore 可以是這些資料的正式狀態

不適用場景

1. 跨實體報表與分析查詢：

• 跨 collection JOIN、ad-hoc 篩選、彙總統計在 Firestore 上要靠資料複製工程
• 替代：自建 relational（PostgreSQL）或把資料同步進分析系統

2. 成本對流量敏感的高讀取場景：

• 計費隨 document read / write / delete 線性成長，高流量下可能超過自建
• 替代：自管資料庫 + 應用層 cache，把熱讀取的單位成本壓下來

3. 複雜授權需要可測試的控制面：

• client 直連模型把授權全塞進 Security Rules，規則長到難以 review / 測試時，控制面風險升高
• 替代：把授權拉回後端 API 中介層（自建後端 + 任意資料庫）

4. 強一致的多實體交易：

• Firestore 有 transaction 與 batch write，但跨大量 document 的複雜交易不是它的主場
• 替代：relational database 的多表交易

跟其他 vendor 的取捨

vs MongoDB（document 對 document）：

• Firestore：serverless、client 直連、realtime listener、GCP / Firebase 綁定、查詢能力受限
• MongoDB：查詢與 aggregation 彈性高、跨雲、要自管或用 Atlas managed、走後端中介存取
• 選 Firestore：行動 / 即時同步 / 想省整層後端
• 選 MongoDB：document model 但要彈性查詢、aggregation、跨雲可攜，見 db3 vendor selection

vs DynamoDB（serverless NoSQL 對 serverless NoSQL）：

• Firestore：GCP / Firebase 生態、內建 realtime 與 offline、client 直連為主
• DynamoDB：AWS 生態、access-pattern-first KV、通常走後端整合、streams 接事件驅動
• 兩者的 access-pattern-first 建模思路相近，差別在生態與 client 直連的有無

vs SQLite（行動端的反向選擇）：

• Firestore：雲端 store、自動多裝置 sync、realtime
• SQLite：embedded、offline-first、無 sync（見 SQLite vendor）
• 選 Firestore：需要跨裝置同步與即時更新
• 選 SQLite：純單機 / offline、不需要雲端同步

vs Supabase（BaaS bundle 的另一條路）：

• Firestore：document model、Google 的 BaaS bundle 資料層
• Supabase：底層是 PostgreSQL（relational）、開源 BaaS bundle，遷出時資料是標準 SQL
• 兩者都是 client 直連 + 規則授權的 BaaS 形狀，差別在資料模型（document vs relational）與遷出時的資料可攜性；Supabase 的資料層判讀見 Managed PostgreSQL 比較，選型層錨點見 0.22

容量規劃要點

1. access pattern 先於 document 結構：

• 列出 application 對資料的所有讀寫路徑、再設計 collection / document 形狀
• access pattern 沒想清楚就建模，後面報表查不出來要重做

2. 反正規化換查詢效率：

• 為了避免跨 collection 多次查詢，常把關聯資料冗餘寫進同一 document
• 代價是寫入時要維護多份副本的一致性，對應 1.9 Reconciliation

3. index 與寫入成本綁定：

• 複合查詢要先建 composite index、否則查詢直接失敗
• 每個 index 增加寫入維護成本，移除用不到的 index 是容量優化的一環

4. 高頻寫入用 distributed counter：

• 單一 document 撞到 contention 上限時，把計數拆成多個 shard document 再彙總

5. 成本以 document 數計，不以掃描量計：

• 容量估算要算「每個畫面 / API 觸發幾次 read」、乘上日活與頻率
• 把熱讀取移到 應用層快取 是壓低 read 計費的主要手段

常見陷阱

• 把 Firestore 當關聯式用：規劃了一堆需要 JOIN 的 collection、上線後跨集合查詢全靠 client 自己組、latency 與 read 成本爆炸
• 報表需求到了才發現查不出來：老闆要月報、Firestore 沒有 aggregation pipeline、被迫臨時搭資料複製管線
• Security Rules 長到沒人敢改：授權全寫在規則 DSL、沒有版本控制與測試、變更時靠人工推敲
• 單 document 當高頻計數器：直播按讚 / 即時計數寫爆單一 document 的 contention 上限
• 忽略 read 計費規模：list 畫面一次回上千筆、每次重整都計上千次 read、帳單月底才浮現

Deep article 章節群

Firestore overview 負責第一輪服務判斷；vendor 特有機制的設定、踩坑與容量規劃拆成 deep article。下表是目前已建立的實作層教材，讀法是先讀 overview 判斷服務適配，再按撞到的壓力選 deep article。

讀法路由：撞到資料外洩 / 越權，讀 Security Rules；撞到熱門事件寫爆計數，讀 distributed counter；改一筆要連動改一千筆，讀反正規化；即時功能帳單失控，讀 realtime listener。撞到報表 / 成本 / 授權整體性的牆，走 遷往自建 relational。

Hands-on 操作演練

deep article 講機制判讀，Hands-on 操作路線 把機制轉成可在本地 Firebase Emulator 跑的演練——零雲端成本、可重跑、產出可驗證 artifact。三個 lab：emulator quickstart（建立共用環境）、Security Rules test lab（規則自動化測試 + 接 release gate）、distributed counter lab（分片計數機制驗證）。lab 全程標明 emulator 驗得了什麼（功能行為、規則求值）、驗不了什麼（計費、寫入軟上限要回雲端）。

已知 limitation 與後續路由

Firestore overview 完成服務判斷、資料形狀、查詢邊界與替代路由；deep article 章節群覆蓋授權、高頻寫入、反正規化與即時同步四個機制；hands-on 章節群提供 emulator 演練。後續可補的方向：offline persistence 的衝突解決深入、realtime listener 在雲端的成本量測 lab（emulator 不計費、要在雲端 staging 跑）。

下一步路由

• 完整 T1 對照：01-database vendors index
• 同類對比：MongoDB vendor（彈性查詢 document）/ DynamoDB vendor（access-pattern-first KV）/ db3 vendor selection（document / KV / multi-model 三方選型）
• 遷出方向：Firestore → 自建 relational（撞到報表 / 成本 / 授權牆後的 Type E 重建模 playbook）
• 操作演練：Firestore Hands-on（emulator quickstart、Security Rules 測試、distributed counter lab）
• 容量背景：1.10 KV / Document DB 容量規劃
• 選型上層：0.21 交付形態選型 / 0.22 能力級買 vs 建 / BaaS 知識卡
• 從託管平台遷出的資產線盤點：10.3 託管形態遷出
• 官方：Firestore documentation、Firestore best practices、Firestore pricing