PCA 架構之旅 07 — 儲存特性分析
PCA
「要用 Cloud SQL 還是 Spanner？要用 Firestore 還是 Bigtable？」這是 PCA 考試最常見的一類題，也是實務上最常被用直覺亂選的項目。
比較好的做法是，先對資料做特性分析（characteristics analysis），讓資料本身告訴你答案。這一步先不選服務，只做分類。
這是 PCA 架構之旅 的第七步。上一篇 06 · REST API 設計。
為什麼這一步重要
在 PCA case study 題目中怎麼出現
PCA case study 幾乎都會給你資料量、成長率、查詢模式的線索。例如「訂單每年 2000 萬筆、保留 7 年、需要跨區強一致」「使用者點擊紀錄每日 5 億筆」。這些數字其實已經幫你刪掉大部分選項了。
題目不會直接告訴你答案是哪個服務，它會塞幾個似是而非的選項，要你自己用資料特性去刪掉錯的那些。
考生常見錯誤
- 看到「關聯式」就選 Cloud SQL，看到「NoSQL」就選 Firestore：這樣分太粗了。
- 忽略讀寫比與延遲要求：同樣是訂單，讀寫比 1:1 跟 100:1，該選的服務就差很多。
- 忘記資料生命週期：保留 7 年的訂單跟保留 7 天的點擊紀錄，成本策略差很大。
核心概念
分析資料的 8 個維度
| 維度 | 問題 |
|---|---|
| 結構（Structure） | 結構化、半結構化、非結構化？ |
| 規模（Size） | 單筆多大？總量多少？成長率？ |
| 讀寫比（R/W Ratio） | 讀多寫少？寫多讀少？ |
| 一致性（Consistency） | 強一致還是最終一致？ |
| 延遲（Latency） | 毫秒級？秒級？分鐘級？ |
| 查詢模式（Access Pattern） | 點查？範圍查？全文檢索？聚合？ |
| 生命週期（Lifecycle） | 熱、溫、冷、歸檔的時程？ |
| 敏感度（Sensitivity） | PII、PCI、PHI 合規要求？ |
GCP 儲存服務快速對照
| 服務 | 定位 | 關鍵字 |
|---|---|---|
| Cloud SQL | 中小型關聯式 | MySQL/PostgreSQL/SQL Server、zonal/regional HA |
| AlloyDB | 高效能 PostgreSQL | 高 OLTP + 分析工作負載 |
| Spanner | 全球強一致關聯式 | multi-region、horizontal scale、SQL |
| Firestore | 文件資料庫 | 行動/Web、即時同步、中小規模 |
| Bigtable | 寬列 NoSQL | 超大量時間序列、IoT、低毫秒延遲 |
| BigQuery | 分析型資料倉儲 | PB 級 OLAP、columnar、SQL |
| Memorystore | 記憶體快取 | Redis/Memcached、毫秒以下 |
| Cloud Storage | 物件儲存 | 大檔案、備份、靜態資產 |
| Filestore | 網路檔案系統 | NFS、legacy lift-and-shift |
OLTP vs OLAP：前者是線上交易處理（Online Transactional Processing），寫多、單筆、低延遲；後者是線上分析處理（Online Analytical Processing），大量讀、聚合、可以等秒級。
思考框架
對每一筆資料問：
- 它是交易資料還是分析資料？ OLTP 跟 OLAP 用的服務不一樣。
- 它需要跨 region 強一致嗎？ 需要的話就只有 Spanner，不需要就別花那個錢。
- 查詢是點查還是範圍掃描？ 決定 key 設計與服務選擇。
- 熱資料多久變冷？ 決定分層儲存策略。
- 有沒有合規限制？ 可能強制 regional storage、CMEK、VPC-SC。
走一遍範例 — 登雲書店
這裡對 8 個服務牽涉到的主要資料做特性分析。下面只列結論表，先不做服務選型，那是下一步的事：
資料特性表
| 資料 | 結構 | 規模/成長 | 讀寫比 | 一致性 | 延遲要求 | 查詢模式 | 生命週期 | 敏感度 |
|---|---|---|---|---|---|---|---|---|
| 商品目錄 | 結構化 | 120 萬 SKU、年增 20% | 1000:1 | 最終一致可接受 | P95 < 50ms | 點查 + 關鍵字 + 分類 | 長期 | 低 |
| 商品全文索引 | 半結構化 | 同上 | 10000:1 | 最終一致 | P95 < 100ms | 全文、fuzzy | 可重建 | 低 |
| 庫存數量 | 結構化 | 120 萬列、少量更新 | 50:1 | 強一致（避免超賣） | P99 < 100ms | 點查 | 長期 | 中 |
| 購物車 | 半結構化 | 同時 5 萬台裝置 | 5:1 | 單裝置強一致即可 | P95 < 50ms | by userId | 30 天自動過期 | 中（PII） |
| 訂單 | 結構化 | 每年 600 萬筆、保留 7 年 | 2:1 | 強一致 + 跨區容錯 | P95 < 200ms | 點查 + 多條件 | 熱 90 天 / 溫 1 年 / 冷 7 年 | 高（PII） |
| 金流明細 | 結構化 | 每筆訂單 1–3 列 | 1:1 | 強一致 + 可稽核 | P95 < 300ms | 點查、範圍 | 永久、WORM | 高（PCI） |
| 閱讀進度 | 半結構化 | 每會員 × 每本書一筆 | 20:1 | 最後寫入優先 | P95 < 100ms | 點查（userId + bookId） | 熱到下次使用 | 中（PII） |
| 點擊與瀏覽紀錄 | 半結構化 | 每日 5 億筆、保留 18 個月 | 寫多（分析讀） | 最終一致 | 寫入 < 10ms、分析秒級 | 時間範圍、聚合 | 自動生命週期過渡 | 中（去識別） |
| 分析型事實表 | 結構化 | 每日 +100 GB、保留 3 年 | 讀多（D+1） | 最終一致 | 查詢秒級 | 大規模聚合 | 分割 + 壓縮 | 中 |
| 商品圖片 | 非結構化 | 單張 500KB、全量 5 TB | 極讀多 | 最終一致 | CDN 命中 < 50ms | by objectKey | 長期 + CDN | 低 |
| 批次匯入檔 | 非結構化 | 單檔最大 200MB | 一次性 | — | 分鐘級 | by jobId | 30 天保留稽核 | 中（商業敏感） |
從特性看出的隱含結論
- 訂單 + 金流明細：強一致 + 跨區容錯 + 高敏感度 → 指向 Spanner 或 Cloud SQL HA（下一篇討論選型）。
- 庫存：強一致且頻繁更新 → 需要 ACID，但資料量小，不一定要 Spanner。
- 點擊紀錄：寫多、時間序列、分析型 → 指向 Bigtable（即時）+ BigQuery（分析）分層。
- 商品目錄：讀極多、可最終一致 → 指向 Firestore + Memorystore 快取 + CDN。
- 商品圖片：非結構化、讀極多 → 大概只有 Cloud Storage + Cloud CDN 這個解了。
- 金流：PCI DSS → 必須獨立 project、加密金鑰走 CMEK、網路走 VPC-SC。
資料生命週期建議
| 階段 | 訂單 | 點擊紀錄 | 圖片 |
|---|---|---|---|
| 熱 | OLTP 主儲存 | 即時儲存 | Standard + CDN |
| 溫 | 同主儲存，降副本 | Nearline | Nearline |
| 冷 | 匯出 BigQuery + Nearline | Coldline | Coldline |
| 歸檔 | Archive Storage | Archive | Archive |
走到這一步，你還不用決定「用 Spanner 還是 Cloud SQL」，但已經很清楚哪些資料得認真對待、哪些可以丟給便宜的最終一致服務就好。
常見陷阱
- 把所有資料都塞同一個資料庫：典型的 monolith 症狀，一個資料庫同時扛 OLTP、OLAP、全文檢索，結果三個都做不好。
- 忽略資料量的複合成長：每日 5 億筆 × 365 天 × 3 年 = 5000 億筆，Cloud SQL 撐不住這個量級。
- 忘記索引與查詢成本：Firestore 預設每個欄位都自動建索引，寫入成本會很高；Bigtable 沒有 secondary index，全靠 row key 設計。
- 合規只想到加密：PCI DSS 還要求網路隔離、稽核紀錄、金鑰管理，光加密不夠。
延伸閱讀
- GCP 資料庫選型決策樹 — 官方決策輔助。
- Spanner vs Cloud SQL vs Firestore 比較 — 官方比較頁面。
- Bigtable schema design guidance — row key、列族設計指南。
- Google Cloud Architecture Framework — Data Strategy — 儲存選擇官方指南。
下一步：有了資料特性表，下一篇就要實際挑資料庫與儲存服務，把每一筆資料對應到具體的 GCP 產品上。這部分交給系列的第 8 篇 儲存與資料庫選型。
🎯 換你練習
理論讀完，換自己來。到 架構師設計工作坊 · 步驟 7 填入你的 case study，邊寫邊內化。
pca-architect-journey — 7/13 完成
查看系列全覽 →