GCP 資料庫選型完全指南：Cloud SQL、AlloyDB、Spanner、Firestore、Bigtable 一次搞懂
前言
在 GCP 上架構一個系統，你會面對的第一個大題目就是：要用哪個資料庫？
Google Cloud 提供了超過 10 種資料庫相關服務，光是「關聯式」就有 Cloud SQL、AlloyDB、Spanner 三種。選錯資料庫的代價很高：效能不如預期、成本爆炸，或是架構被綁死，到頭來只能打掉重做。
這篇文章會帶你一次搞懂 GCP 六大核心資料庫服務的定位、適用場景、限制跟定價，最後給你一張決策樹，5 分鐘內就能選對。
如果你只需要學習單一服務，可以直接跳到對應段落，或參考各服務的專門課程文章。
六大資料庫總覽比較表
先看全貌，再深入每一個服務：
| 特性 | Cloud SQL | AlloyDB | Spanner | Firestore | Bigtable | BigQuery |
|---|---|---|---|---|---|---|
| 類型 | 關聯式（RDBMS） | 關聯式（RDBMS） | 關聯式（分散式） | 文件型 NoSQL | 寬列型 NoSQL | 分析型倉儲（OLAP） |
| 引擎 | MySQL / PG / SQL Server | PostgreSQL 相容 | Google 自研 | Google 自研 | Google 自研 | Google 自研 |
| 擴展方式 | 垂直擴展（Scale Up） | 垂直 + 讀取水平擴展 | 水平擴展（Scale Out） | 自動（Serverless） | 水平擴展（加 Node） | 自動（Serverless） |
| 最大儲存 | 64 TB | 64 TB + 自動擴充 | 無限制 | 無限制 | 無限制 | 無限制 |
| 延遲 | 毫秒級 | 亞毫秒級 | 毫秒級 | 毫秒級 | 個位數毫秒 | 秒～分鐘級 |
| SLA | 99.95%（HA） | 99.99% | 99.999%（多區域） | 99.999%（多區域） | 99.999%（多區域） | 99.99% |
| ACID 交易 | ✅ 完整 | ✅ 完整 | ✅ 全球分散式 | ✅（有限制） | ❌ 單列原子性 | ❌ 非即時 |
| SQL 支援 | 完整（原生） | 完整（PG 語法） | Google SQL / PG 介面 | ❌ | ❌ | 完整（標準 SQL） |
| 適合工作負載 | OLTP | OLTP（高效能） | OLTP（全球級） | 行動/Web 應用 | IoT / 時序資料 | OLAP / 報表 |
| 最低月費 | ~$7（db-f1-micro） | ~$200（2 vCPU） | ~$65（100 PU） | 免費層 | ~$470（1 Node SSD） | 免費層（1 TB 查詢/月） |
💡 考試小提示：ACE 考試經常考「給一個場景，選最合適的資料庫」。先判斷 OLTP vs OLAP，再判斷關聯式 vs NoSQL，最後看擴展需求。
Cloud SQL：入門首選的托管關聯式資料庫
定位
Cloud SQL 是 GCP 上最容易上手的關聯式資料庫服務。說穿了就是 Google 幫你管理的 MySQL、PostgreSQL 或 SQL Server，你不用碰作業系統、不用排程備份、也不用手動打安全修補。
核心特性
- 三種引擎：MySQL 8.0/8.4、PostgreSQL 14～17、SQL Server 2019/2022
- 垂直擴展：最大 128 vCPU、864 GB RAM
- 高可用（HA）：跨可用區自動容錯移轉，SLA 99.95%
- 讀取副本：最多 10 個 Read Replicas，支援跨區域
- Private IP：透過 VPC Peering 提供內網連線
- 自動儲存擴充：最大 64 TB（此為專用核心（dedicated-core）機型上限；共用核心（shared-core，如 db-f1-micro）儲存上限較低，約 3 TB）
適用場景
- 中小型 Web 應用的後端資料庫
- 既有 MySQL / PostgreSQL 應用的雲端遷移（lift-and-shift）
- 需要標準 SQL 語法的 OLTP 工作負載
- 開發 / 測試環境
限制
- 不能水平寫入擴展——寫入效能受限於單一主執行個體
- 無法跨區域高可用——HA 只在同一 Region 內的兩個 Zone
- 單一寫入點——讀取副本是唯讀的
gcloud CLI 快速建立
# 建立 PostgreSQL 執行個體
gcloud sql instances create my-pg-instance \
--database-version=POSTGRES_17 \
--tier=db-custom-2-8192 \
--region=asia-east1 \
--availability-type=REGIONAL \
--storage-auto-increase
# 建立資料庫
gcloud sql databases create myapp --instance=my-pg-instance
# 設定使用者密碼
gcloud sql users set-password postgres \
--instance=my-pg-instance \
--password=YOUR_SECURE_PASSWORD深入學習：Cloud SQL 完全指南
AlloyDB：PostgreSQL 相容的高效能選擇
定位
AlloyDB 是 Google 自研的 PostgreSQL 相容資料庫，用上了 Google 的運算與儲存分離架構。官方宣稱交易處理效能是標準 PostgreSQL 的 4 倍，分析查詢更是快到 100 倍。
核心特性
- 完全 PostgreSQL 相容：用同樣的驅動程式、ORM、工具
- 運算與儲存分離：運算層可獨立擴展
- 欄位引擎（Columnar Engine）：自動將常查詢的欄位載入記憶體，加速分析
- ML 整合：內建
google_ml_integration擴充，可直接在 SQL 內呼叫 Vertex AI 模型 - 智慧快取：跨層級智慧快取，減少 I/O
- SLA：99.99%
適用場景
- 高效能 OLTP + 即時分析的混合工作負載（HTAP）
- 從標準 PostgreSQL 遷移但需要更好效能的系統
- 需要在資料庫層做 AI/ML 推論的應用
- 需要比 Cloud SQL 更高 SLA 但不到 Spanner 規模的系統
限制
- 只支援 PostgreSQL——如果你用 MySQL 或 SQL Server，不適用
- 價格較高——起步約 $200/月，比 Cloud SQL 入門方案貴不少
- 區域性——目前支援的區域比 Cloud SQL 少
- 不支援水平寫入擴展——寫入仍為單一主要執行個體
gcloud CLI 快速建立
# 建立 AlloyDB 叢集
gcloud alloydb clusters create my-alloydb-cluster \
--region=asia-east1 \
--password=YOUR_SECURE_PASSWORD
# 建立主要執行個體
gcloud alloydb instances create my-primary \
--cluster=my-alloydb-cluster \
--region=asia-east1 \
--instance-type=PRIMARY \
--cpu-count=2
# 建立讀取集區
gcloud alloydb instances create my-read-pool \
--cluster=my-alloydb-cluster \
--region=asia-east1 \
--instance-type=READ_POOL \
--read-pool-node-count=2 \
--cpu-count=2💡 考試小提示：當題目描述「PostgreSQL 應用需要更好的交易效能和即時分析能力」，答案通常是 AlloyDB，不是 Cloud SQL。
Cloud Spanner：全球分散式的終極選擇
定位
Cloud Spanner 是 Google 唯一能同時做到全球水平擴展 + 強一致性 + 完整 ACID 交易的關聯式資料庫。它靠 TrueTime（原子鐘 + GPS 時間同步）解決了分散式系統一致性的老問題。
核心特性
- 無限水平擴展：從 100 PU（Processing Units）起跳，線性擴展
- 99.999% SLA（多區域配置）：一年停機不超過 5.26 分鐘
- 全球分散式 ACID：跨洲交易也能保證一致性
- 雙 SQL 介面：Google SQL + PostgreSQL 介面（PGAdapter）
- Change Streams：即時捕捉資料變更事件
- Editions：Standard / Enterprise / Enterprise Plus 三種等級
適用場景
- 全球部署的金融交易系統（跨國轉帳、支付）
- 遊戲排行榜（全球一致性排名）
- 供應鏈管理系統（跨區域庫存同步）
- 需要水平擴展又不能犧牲 SQL 和 ACID 的系統
限制
- 成本高：最低 ~$65/月（100 PU），生產環境通常 $600+ 起跳
- 主鍵設計要求嚴格：不能用自動遞增整數，否則會產生熱點（Hotspot）
- 不支援原生 DDL 鎖：Schema 變更是非同步的
- 學習曲線較陡：需要理解 Interleaved Tables、PU 規劃
gcloud CLI 快速建立
# 建立單區域 Spanner 執行個體
gcloud spanner instances create my-spanner \
--config=regional-asia-east1 \
--processing-units=100 \
--description="My Spanner Instance"
# 建立資料庫（Google SQL）
gcloud spanner databases create mydb \
--instance=my-spanner
# 建立資料庫（PostgreSQL 介面）
gcloud spanner databases create mydb-pg \
--instance=my-spanner \
--database-dialect=POSTGRESQL💡 考試小提示：看到「全球一致性」、「99.999%」、「水平擴展的關聯式資料庫」，答案就是 Spanner。
深入學習：Cloud Spanner 深度解析
Firestore：行動與 Web 應用的首選 NoSQL
定位
Firestore 是 GCP 的全托管 NoSQL 文件資料庫（Document Database），主打行動應用和 Web 應用。資料以類 JSON 的文件格式存放，支援即時同步跟離線快取。
核心特性
- 兩種模式：
- Native mode：即時監聽、離線支援、安全規則——適合行動 / Web 前端
- Datastore mode：向後相容舊 Datastore API，適合純後端——無即時監聽
- Serverless：完全免管理，自動擴展
- 即時監聽：資料變更時主動推播給客戶端
- 離線支援：行動端可在無網路時繼續讀寫，上線後自動同步
- 強一致性：所有查詢都是強一致的（自 Firestore 起，不同於舊 Datastore 的最終一致）
- 慷慨的免費層：每天 50,000 次讀、20,000 次寫、20,000 次刪除
適用場景
- 行動應用 / PWA 的後端資料儲存
- 即時聊天、即時協作工具
- 使用者個人資料、設定、偏好
- 遊戲玩家狀態管理
- 小到中型的 Web 應用後端
限制
- 單一文件大小：最大 1 MiB
- 寫入限制：每個文件每秒最多 1 次寫入
- 查詢限制：不支援 JOIN、不支援不等式條件跨多個欄位（複合查詢需建立複合索引）
- 匯出/匯入：大量資料操作需透過 GCS
- 不適合分析：沒有聚合查詢（count / sum 等需要自行維護）
gcloud CLI 快速建立
# 建立 Firestore 資料庫（Native mode）
gcloud firestore databases create \
--location=asia-east1 \
--type=firestore-native
# 匯出資料到 GCS
gcloud firestore export gs://my-backup-bucket/firestore-export
# 匯入資料
gcloud firestore import gs://my-backup-bucket/firestore-export💡 考試小提示：
- 題目提到「行動應用」+「離線支援」+「即時同步」→ Firestore Native mode
- 題目提到「後端伺服器」+「Key-Value 查找」+「不需要即時監聽」→ Firestore Datastore mode
- 每個 GCP 專案中，Native mode 和 Datastore mode 只能選一個（不可混用）
深入學習：Firestore 完全指南
Bigtable：超大規模低延遲的 NoSQL 引擎
定位
Cloud Bigtable 跟 Google 內部驅動搜尋引擎、Google Maps、Gmail 的是同一套技術，一個 PB 級的寬列型（Wide-Column）NoSQL 資料庫，專門為超大資料量加上穩定低延遲而生。
核心特性
- PB 級儲存：無上限，自動分片
- 個位數毫秒延遲：SSD 節點 p99 約 6ms
- 線性擴展：增加 Node 就增加吞吐量
- HBase API 相容：HBase 生態系工具直接使用
- 自動擴縮：根據 CPU 使用率自動調整 Node 數量
- Change Streams：即時擷取資料變更
- 複製叢集：支援跨區域複製，SLA 可達 99.999%
適用場景
- IoT 感測器資料（數十億筆時間序列）
- 金融市場資料（行情、逐筆交易）
- 使用者行為分析（推薦引擎的特徵儲存）
- 大規模時序資料庫（監控指標、日誌索引）
- AdTech（廣告技術的即時出價資料）
限制
- 最低 1 Node：即使閒置也要約 $470/月（SSD），沒有免費層
- 無 SQL 支援：只有 Row Key 查找和掃描
- Row Key 設計關鍵：設計不當會導致熱點，效能暴跌
- 無二級索引：只能透過 Row Key 查詢
- 不適合小資料量：低於 1 TB 的資料用 Bigtable 是大材小用
gcloud CLI 快速建立
# 建立 Bigtable 執行個體
gcloud bigtable instances create my-bigtable \
--display-name="My Bigtable" \
--cluster-config=id=my-cluster,zone=asia-east1-a,nodes=1,storage-type=SSD
# 建立資料表
cbt -instance=my-bigtable createtable my-table
# 建立 Column Family
cbt -instance=my-bigtable createfamily my-table metrics
# 啟用自動擴縮
gcloud bigtable clusters update my-cluster \
--instance=my-bigtable \
--autoscaling-min-nodes=1 \
--autoscaling-max-nodes=5 \
--autoscaling-cpu-target=60💡 考試小提示：看到「TB / PB 級」+「低延遲」+「時序資料」或「IoT」，答案是 Bigtable。看到「GB 級小資料」+「需要 SQL」，千萬不要選 Bigtable。
深入學習：Bigtable 完全指南
BigQuery：分析型資料倉儲，不是交易資料庫
定位
BigQuery 是 GCP 的無伺服器資料倉儲（Data Warehouse），讓你用標準 SQL 在幾秒內查完 PB 級的資料。它是拿來做 OLAP（線上分析處理） 的，不是 OLTP（線上交易處理）。
核心特性
- 無伺服器：不需要管理叢集、節點或索引
- 欄位式儲存（Columnar）：天生適合分析查詢（只讀取需要的欄位）
- 儲存與運算分離：Dremel 引擎 + Colossus 儲存
- 定價彈性：On-demand（按查詢量計費）或 Editions（預留 Slot 容量）
- BigQuery ML：直接用 SQL 建立和訓練 ML 模型
- 免費層：每月 1 TB 查詢 + 10 GB 儲存（免費！）
- 跨雲查詢：BigQuery Omni 可查詢 AWS S3 和 Azure Blob 的資料
適用場景
- 商業智慧（BI）報表和儀表板
- 大規模日誌分析（應用日誌、稽核日誌）
- 資料湖（Data Lake）上的 SQL 分析
- ML 特徵工程和模型訓練
- 行銷分析、使用者漏斗分析
限制
- 不適合 OLTP：延遲在秒級到分鐘級，不適合即時交易
- DML 限制：每天每個資料表有 DML 配額（INSERT / UPDATE / DELETE）
- 串流寫入限制：Streaming Insert 有每秒行數限制
- 不支援交易：沒有 BEGIN / COMMIT，多表操作無法保證原子性
- 查詢成本難預測：On-demand 模式下大查詢可能很貴（每月前 1 TB 免費，超出後約 $6.25/TiB）
gcloud CLI 快速範例
# 建立 Dataset
bq mk --dataset \
--location=asia-east1 \
--description="Sales Analytics" \
my-project:sales_analytics
# 從 GCS 載入資料
bq load \
--source_format=CSV \
--autodetect \
sales_analytics.transactions \
gs://my-bucket/sales/*.csv
# 執行查詢
bq query --use_legacy_sql=false \
'SELECT region, SUM(revenue) as total
FROM `my-project.sales_analytics.transactions`
WHERE DATE(order_date) >= "2026-01-01"
GROUP BY region
ORDER BY total DESC'
# 查看花費預估
bq query --dry_run --use_legacy_sql=false \
'SELECT * FROM `my-project.sales_analytics.transactions`'💡 考試小提示：BigQuery 是 OLAP，不是 OLTP。如果題目需要「即時讀寫」、「低延遲交易」，BigQuery 永遠不是答案。如果題目需要「分析大量歷史資料」、「商業報表」，BigQuery 幾乎一定是答案。
深入學習：BigQuery 實戰指南
選型決策樹
面對選型問題，按照以下流程走：
你的工作負載是什麼類型？
│
├── 📊 分析 / 報表 / BI（OLAP）
│ └── ✅ BigQuery
│
├── 💾 交易處理（OLTP）
│ │
│ ├── 需要 SQL / 關聯式嗎？
│ │ │
│ │ ├── ✅ 是
│ │ │ │
│ │ │ ├── 需要全球分散式 + 水平擴展？
│ │ │ │ ├── ✅ 是 → Cloud Spanner
│ │ │ │ └── ❌ 否
│ │ │ │ │
│ │ │ │ ├── 需要 PostgreSQL 高效能 + 分析？
│ │ │ │ │ ├── ✅ 是 → AlloyDB
│ │ │ │ │ └── ❌ 否 → Cloud SQL
│ │ │ │ │
│ │ │ │ └── 需要 MySQL / SQL Server？
│ │ │ │ └── ✅ 是 → Cloud SQL
│ │ │ │
│ │ │
│ │ └── ❌ 否（NoSQL）
│ │ │
│ │ ├── 資料量 TB 級以上 + 低延遲？
│ │ │ ├── ✅ 是 → Bigtable
│ │ │ └── ❌ 否
│ │ │ │
│ │ │ ├── 行動 / Web + 即時同步？
│ │ │ │ └── ✅ 是 → Firestore（Native mode）
│ │ │ │
│ │ │ └── 後端 Key-Value 查找？
│ │ │ └── ✅ 是 → Firestore（Datastore mode）
│ │ │💡 考試小提示：ACE 考試中最常見的陷阱是把 BigQuery 當 OLTP 資料庫用，或是在小資料量場景選 Bigtable。記住這棵決策樹，考場上就不會踩坑。
定價比較
以下為 asia-east1（台灣彰化）區域的概略定價（2026 年 3 月），實際價格請以 Google Cloud Pricing 為準：
入門級月費比較
| 服務 | 最低可用配置 | 概略月費 | 適合什麼 |
|---|---|---|---|
| Cloud SQL | db-f1-micro（共用 vCPU, 614MB RAM） | ~$7 | 開發 / 測試 |
| Cloud SQL | db-custom-2-8192（2 vCPU, 8GB）+ HA | ~$160 | 小型生產環境 |
| AlloyDB | 2 vCPU 主執行個體 | ~$200 | 需要高效能 PG |
| Spanner | 100 PU（單區域） | ~$65 | 最小 Spanner 體驗 |
| Spanner | 1000 PU（多區域） | ~$2,300 | 生產級全球部署 |
| Firestore | 免費層 | $0 | 原型開發 / 小應用 |
| Bigtable | 1 Node SSD | ~$470 | 最小 Bigtable 體驗 |
| BigQuery | 免費層（1 TB 查詢/月） | $0 | 分析入門 |
儲存成本比較（每 GB / 月）
| 服務 | 儲存單價 | 備註 |
|---|---|---|
| Cloud SQL | $0.17 | SSD 儲存 |
| AlloyDB | $0.0004/IO + 儲存 | 按 I/O 計費模型 |
| Spanner | $0.30 | 含複製成本 |
| Firestore | $0.108 | 按文件儲存量 |
| Bigtable | $0.17（SSD）/ $0.026（HDD） | 按壓縮後大小 |
| BigQuery | $0.02（Active）/ $0.01（Long-term） | 90 天未異動自動轉 Long-term |
💡 考試小提示：考試不會考確切價格，但會考「哪個最便宜」。對小專案來說，Firestore（免費層）和 BigQuery（免費層）的入門成本最低。Bigtable 是最昂貴的入門選擇（~$470/月無免費層）。
ACE / PCA 考試常見選型題
題目 1
你的電商平台使用 MySQL 資料庫，目前部署在地端機房。團隊希望盡快遷移到 GCP，但不想修改應用程式碼。最適合的服務是？
A. Cloud Spanner B. Cloud SQL for MySQL C. AlloyDB D. Firestore
查看答案
答案：B
Cloud SQL for MySQL 是 MySQL 相容的托管服務，「不想修改應用程式碼」= lift-and-shift 遷移，Cloud SQL 是最直接的選擇。AlloyDB 只支援 PostgreSQL。Spanner 需要改寫 Schema 和查詢。
題目 2
你的全球金融交易系統需要跨三個洲的資料中心保持強一致性，每秒處理 10,000 筆交易，且 SLA 要求 99.999%。你應該使用哪個資料庫？
A. Cloud SQL with Cross-Region Replicas B. AlloyDB C. Cloud Spanner（多區域配置） D. Bigtable
查看答案
答案：C
「跨三個洲」+「強一致性」+「99.999%」= Cloud Spanner 多區域配置。Cloud SQL 的跨區域副本是非同步的（最終一致），不滿足「強一致性」要求。AlloyDB 是區域性服務。
題目 3
你正在開發一個行動 App，需要在使用者離線時也能讀寫資料，並在上線後自動同步。資料結構是使用者設定和偏好（文件大小 < 10 KB）。你應該使用？
A. Cloud SQL B. Firestore（Native mode） C. Firestore（Datastore mode） D. Bigtable
查看答案
答案：B
「行動 App」+「離線讀寫」+「自動同步」= Firestore Native mode。Datastore mode 不支援即時同步和離線功能。Cloud SQL 和 Bigtable 都沒有內建離線支援。
題目 4
你的 IoT 平台每秒從 100 萬個感測器接收資料，需要儲存 3 年的時序資料（總量 > 50 TB），查詢延遲要在 10ms 以內。最佳選擇是？
A. Cloud SQL B. BigQuery C. Bigtable D. Firestore
查看答案
答案：C
「100 萬感測器」+「50 TB」+「時序資料」+「10ms 延遲」= Bigtable。BigQuery 延遲太高（秒級），Cloud SQL 無法處理這種資料量，Firestore 不適合高頻寫入的時序資料。
題目 5
你需要分析過去一年的銷售資料（約 500 GB），產生月報和季報。資料已經在 GCS 上以 Parquet 格式存放。團隊熟悉 SQL。你應該使用？
A. Cloud SQL B. Cloud Spanner C. Bigtable D. BigQuery
查看答案
答案：D
「分析歷史資料」+「報表」+「SQL」+「GCS 上的 Parquet」= BigQuery。可以直接建立 External Table 讀取 GCS 上的 Parquet，或載入 BigQuery 原生表格。其他選項都是 OLTP 或 NoSQL，不適合報表分析。
題目 6
你的 PostgreSQL 應用程式需要同時處理大量交易和即時分析查詢。目前 Cloud SQL 的效能已經不夠，但你不想把應用拆成兩個系統（OLTP + OLAP）。最佳方案是？
A. 升級 Cloud SQL 機器規格 B. 遷移到 AlloyDB C. 遷移到 Cloud Spanner D. 加入 BigQuery 做分析
查看答案
答案：B
「PostgreSQL」+「交易 + 即時分析」+「不想拆系統」= AlloyDB。AlloyDB 的欄位引擎可以同時處理 OLTP 和分析，且完全 PostgreSQL 相容。Spanner 需要改寫程式。「升級規格」只能延緩問題，無法解決根本需求。
題目 7
你的遊戲需要一個全球排行榜，所有玩家看到的排名必須一致。每天有 500 萬活躍玩家，排行榜每秒更新數千次。你的選擇是？
A. Firestore B. Cloud SQL C. Cloud Spanner D. Memorystore for Redis
查看答案
答案：C
「全球一致」+「每秒數千次更新」+「500 萬玩家」= Cloud Spanner。Firestore 的單文件 1 write/sec 限制無法承受。Cloud SQL 無法做全球一致。Redis 是快取而非持久化儲存（雖然實務上常配合使用）。
題目 8
你要選一個資料庫存放機器學習模型的特徵向量（Feature Store），每次查詢需要讀取單一使用者的上千個特徵，延遲要求 < 5ms，資料量約 10 TB。最佳選擇是？
A. BigQuery B. Cloud SQL C. Bigtable D. Firestore
查看答案
答案：C
「Feature Store」+「寬列查詢（上千個特徵）」+「< 5ms」+「10 TB」= Bigtable。Bigtable 的寬列模型天然適合特徵儲存，Row Key = user_id，Column Family = 各類特徵。BigQuery 延遲太高，Cloud SQL 容量不夠。
常見錯誤選型案例
❌ 錯誤 1：用 BigQuery 做即時 API 後端
場景：新創團隊把所有資料都放 BigQuery，連使用者登入驗證也用 BigQuery 查詢。
問題：BigQuery 查詢最快也要 1-2 秒，使用者每點一下都得等。而且 On-demand 模式下，頻繁的小查詢反而比 Cloud SQL 還貴。
正確方案：OLTP 操作用 Cloud SQL 或 Firestore，歷史資料定期匯入 BigQuery 做分析。
❌ 錯誤 2：50 GB 資料用 Bigtable
場景：團隊看到「Bigtable 很快」就選了，結果每月帳單 $470+，而且資料量太小，Bigtable 的效能優勢根本發揮不出來。
問題：Bigtable 最少 1 Node，適合 TB 級以上資料。50 GB 用 Cloud SQL 或 Firestore 就綽綽有餘。
正確方案：如果需要低延遲 Key-Value 查找，用 Memorystore for Redis；如果需要持久化，用 Cloud SQL。
❌ 錯誤 3：用 Cloud SQL 做全球部署
場景：跨國電商用 Cloud SQL + Cross-Region Read Replicas 部署，結果美國使用者的寫入得跨太平洋繞回台灣的主執行個體，延遲 200ms+。再加上讀取副本有複寫延遲，庫存顯示對不上。
問題：Cloud SQL 的架構是「單一寫入點」，跨區域讀取副本是非同步複寫（最終一致）。
正確方案：需要全球強一致性 → Cloud Spanner。
❌ 錯誤 4：用 Firestore 存 IoT 時序資料
場景：IoT 平台把感測器資料寫進 Firestore，一開始很順。但感測器增加到 10,000 個、每秒寫入 50,000 筆之後，就開始一直撞到 RESOURCE_EXHAUSTED 錯誤。
問題：Firestore 的單一文件每秒只能寫入一次，且每個集合的寫入吞吐量有上限。高頻寫入的時序資料不是 Firestore 的適用場景。
正確方案：高頻時序資料 → Bigtable。
❌ 錯誤 5：直接選 Spanner 而不考慮成本
場景：小型 SaaS 公司覺得「Spanner 最強」就選了，結果每月帳單 $2,000+，但其實他們的流量用 Cloud SQL HA 就能扛。
問題：Spanner 的最低生產配置（1000 PU + 多區域）每月 $2,300+。如果你的應用不需要全球一致性或水平擴展，這筆錢完全浪費。
正確方案：先從 Cloud SQL（或 AlloyDB）開始，等真的需要水平擴展再遷移到 Spanner。
各場景推薦速查表
| 場景 | 推薦服務 | 備選方案 |
|---|---|---|
| 中小型 Web App 後端 | Cloud SQL | AlloyDB（如需更高效能） |
| MySQL/PG 遷移（lift-and-shift） | Cloud SQL | — |
| 高效能 PostgreSQL + 即時分析 | AlloyDB | — |
| 全球分散式交易系統 | Cloud Spanner | — |
| 行動 App + 離線 + 即時同步 | Firestore（Native） | — |
| 後端 Key-Value 儲存 | Firestore（Datastore） | Memorystore |
| IoT / 時序資料（TB+） | Bigtable | — |
| ML Feature Store | Bigtable | AlloyDB（PG 生態） |
| BI 報表 / 資料分析 | BigQuery | — |
| 日誌分析 | BigQuery | — |
| 快取層 | Memorystore | — |
進階：混合架構模式
實務上很少只用一個資料庫，下面是幾種常見的混合架構：
電商平台
使用者請求 → Cloud SQL（訂單 / 商品 OLTP）
├── Memorystore Redis（商品快取 / Session）
├── Firestore（使用者偏好 / 購物車）
└── BigQuery（銷售分析 / 報表）
↑ 每日 ETL（Dataflow）全球遊戲
玩家請求 → Cloud Spanner（排行榜 / 全球一致資料）
├── Bigtable（遊戲事件 / 行為日誌）
├── Memorystore（Session / 即時狀態）
└── BigQuery（玩家分析 / A/B 測試結果）IoT 平台
感測器 → Pub/Sub → Dataflow → Bigtable（即時查詢）
└→ BigQuery（歷史分析）
└→ Cloud SQL（裝置管理 / 設定）總結
GCP 資料庫選型的核心邏輯：
- 先分 OLTP vs OLAP：分析用 BigQuery，交易用其他
- 再分 SQL vs NoSQL：需要 JOIN / 交易 → 關聯式；Key-Value / 文件 → NoSQL
- 最後看規模和特殊需求：
- 全球一致 → Spanner
- PostgreSQL 高效能 → AlloyDB
- 標準遷移 → Cloud SQL
- 行動端 + 離線 → Firestore
- TB+ 低延遲 → Bigtable
別被「最強」的服務吸引，要選「最適合」的那個。$7/月的 Cloud SQL 能搞定的事，就別動用 $2,300/月的 Spanner。
延伸閱讀
- Cloud SQL 入門指南 — 托管關聯式資料庫完全指南
- Firestore 入門指南 — NoSQL 文件資料庫完全指南
- Bigtable 入門指南 — PB 級寬列 NoSQL 完全指南
- Cloud Spanner 深度解析 — 全球分散式關聯資料庫
- BigQuery 實戰指南 — PB 級分析完全指南
- Memorystore 入門 — 托管快取服務
- 儲存策略 — GCP 儲存服務全方位比較
- ACE 認證準備 — 考試準備攻略