PCA 架構之旅 08 — GCP 儲存服務選擇
PCA
到了第 8 步，你已經清楚「資料要存多久、存多大、讀寫比例、延遲需求」這些特性。現在要做的事只有一件：把特性對應到具體的 GCP 服務。
這一步看起來簡單，其實是 PCA 考題最愛埋地雷的地方。七個儲存服務，每一個都有「最像但不對」的替身，選錯一個，整題就跟著翻車。
為什麼這一步重要
在 PCA case study 裡，題目很少直接告訴你「請用 Spanner」。它會給你一段描述：
- 「全球用戶、強一致、金流交易、每秒數千筆寫入」
- 「百 PB 時序資料、單鍵查詢 < 10ms」
- 「分析師要用 SQL 查半年內的訂單」
你要從這些文字裡聽出關鍵詞，再對應到正確的服務。考生最常踩的三個雷是：
- 把 Cloud SQL 當萬用選項：看到「資料庫」就選 Cloud SQL，忽略規模或全球一致性要求
- 把 Firestore 跟 Bigtable 搞混：兩個都是 NoSQL，但設計哲學差很多
- 忘記 BigQuery 不是 OLTP：BigQuery 能做的事很多，就是不能拿來接前端交易
這一步選對了，後面的網路、安全、成本題才接得下去。
核心概念
GCP 的七大儲存服務與最適場景對照：
| 服務 | 類型 | 最適場景 | 一致性 | 規模上限 |
|---|---|---|---|---|
| Persistent Disk (PD) | Block | VM 掛載磁碟、資料庫底層 | 強 | 單盤 64 TB |
| Cloud Storage (GCS) | Object | 圖片、備份、資料湖、靜態網站 | 強（物件層級） | 無限 |
| Cloud SQL | 關聯式（區域） | 中小型 OLTP、單區域交易 | 強 | 單實例 64 TB |
| Spanner | 關聯式（全球） | 全球交易、金融、多區強一致 | 全球外部一致 | PB 級 |
| Firestore | 文件 NoSQL | 行動 App、即時同步、低寫入量 | 強（文件層級） | PB 級 |
| Bigtable | 寬列 NoSQL | 時序、IoT、廣告、推薦系統 | 單叢集強一致；跨叢集複寫為最終 | PB 級，高吞吐 |
| BigQuery | 資料倉儲 | 分析型查詢、報表、ML 訓練資料 | 強 | EB 級 |
幾個分水嶺概念要記清楚：
- OLTP vs OLAP：交易型用 Cloud SQL / Spanner / Firestore；分析型用 BigQuery
- 區域 vs 全球：只在一個 region 跑用 Cloud SQL；跨 region 強一致用 Spanner
- 結構化 vs 非結構化：有 schema 走資料庫；檔案、影像、日誌走 Cloud Storage
- 低延遲讀寫 vs 高吞吐：Firestore 偏低延遲小量；Bigtable 偏高吞吐大量
思考框架
給任何一個儲存需求，依序問這五個問題：
- 這是檔案還是結構化資料？ 檔案 → Cloud Storage；結構化繼續往下
- 是交易型還是分析型？ 分析型（讀多、聚合、報表）→ BigQuery
- 需要跨 region 強一致嗎？ 需要 → Spanner；不需要繼續往下
- 是關聯式還是 NoSQL？ 關聯式 → Cloud SQL；NoSQL 繼續往下
- 寫入量大且是時序/IoT 嗎？ 是 → Bigtable；否 → Firestore
額外兩個子問題幫你排除錯誤選項：
- 資料要存超過一年但很少讀嗎？ Cloud Storage Nearline / Coldline / Archive
- 需要掛到 VM 當本地磁碟嗎？ Persistent Disk（或 Hyperdisk）
走一遍範例 — 登雲書店
登雲書店是電商平台，會員、訂單、商品、圖片、瀏覽紀錄、報表都要存。我們一個一個對照：
| 資料 | 選擇 | 為什麼 |
|---|---|---|
| 商品圖片、封面圖 | Cloud Storage Standard | 非結構化檔案、需 CDN 分發 |
| 舊版封面、檔案歸檔 | Cloud Storage Coldline | 30 天後幾乎不讀、成本最低 |
| 會員資料、訂單主檔 | Cloud SQL for PostgreSQL | 台灣單 region、讀寫比 7:3、關聯式 JOIN |
| 購物車、即時推播 token | Firestore | 低延遲、前端 SDK 直連、文件結構彈性 |
| 瀏覽紀錄、點擊串流 | Bigtable | 每秒數萬筆寫入、時序查詢 |
| 每日營收、用戶行為分析 | BigQuery | 分析師寫 SQL、跨月聚合 |
| Cloud SQL 底層磁碟 | Persistent Disk SSD | 由 Cloud SQL 自動管理 |
有兩個容易被試題誘導選錯的點：
- 會員資料不選 Firestore：訂單要 JOIN 商品、用戶、物流，用關聯式來查比較直觀，而 Firestore 本來就不擅長跨文件查詢。
- 瀏覽紀錄不選 BigQuery 當前端寫入：BigQuery 有串流 insert quota，而且延遲不適合接使用者操作。正確做法是 Bigtable 收資料，每日 batch 到 BigQuery 做分析。
如果登雲書店未來要做跨國電商（台日韓同一個帳號、同一個訂單表），這時候才會升級到 Spanner。在單一 region 階段，Cloud SQL 的成本效益遠優於 Spanner。
常見陷阱
- 覺得用 Spanner 取代 Cloud SQL「比較專業」：題目沒提到跨 region 強一致，選 Spanner 就是過度設計。Spanner 的授權成本比 Cloud SQL 高很多，考試常常拿成本來當排除條件。
- 用 BigQuery 當即時交易後端：BigQuery 的強項是 scan PB 級資料做聚合，不是接每秒上千筆的 UPDATE。看到「即時訂單狀態更新」就排除 BigQuery。
- 忘記 Persistent Disk 跟 Cloud Storage 不是替代關係：PD 是給 VM 當磁碟用；GCS 是 HTTP 存取的物件儲存。把使用者上傳的檔案塞進 PD，等於浪費 CDN 跟生命週期管理能力。
延伸閱讀
系列導航
- 系列首頁：PCA 架構之旅
- 上一篇：PCA 架構之旅 07 — 儲存特性分析
- 下一篇：PCA 架構之旅 09 — 網路與 Load Balancing
🎯 換你練習
理論讀完，換自己來。到 架構師設計工作坊 · 步驟 8 填入你的 case study，邊寫邊內化。
pca-architect-journey — 8/13 完成
查看系列全覽 →