GCP 資料庫選型完全指南：Cloud SQL、AlloyDB、Spanner、Firestore、Bigtable 一次搞懂

前言

在 GCP 上架構一個系統，你會面對的第一個大題目就是：要用哪個資料庫？

Google Cloud 提供了超過 10 種資料庫相關服務，光是「關聯式」就有 Cloud SQL、AlloyDB、Spanner 三種。選錯資料庫的代價很高：效能不如預期、成本爆炸，或是架構被綁死，到頭來只能打掉重做。

我自己就踩過這個坑——當初圖方便把一個高頻寫入的功能塞進不對的資料庫，量一上來整個打掉重做，那種痛現在想起來還是會皺眉。所以底下我把 GCP 六大核心資料庫的定位、適用場景、限制跟定價攤開來講，順手附一張決策樹，下次你在白板前選型時，至少不會像我當年那樣憑感覺賭一把。

如果你只需要學習單一服務，可以直接跳到對應段落，或參考各服務的專門課程文章。

六大資料庫總覽比較表

先看全貌，再深入每一個服務：

💡 考試小提示：ACE 考試經常考「給一個場景，選最合適的資料庫」。先判斷 OLTP vs OLAP，再判斷關聯式 vs NoSQL，最後看擴展需求。

Cloud SQL：入門首選的托管關聯式資料庫

定位

Cloud SQL 是 GCP 上最容易上手的關聯式資料庫服務。說穿了就是 Google 幫你管理的 MySQL、PostgreSQL 或 SQL Server，你不用碰作業系統、不用排程備份、也不用手動打安全修補。我大部分案子的第一版後端都是從 Cloud SQL 起步——不是因為它最強，而是因為它最不容易讓你在初期就把架構選死，真的扛不住了再談遷移也不遲。

核心特性

• 三種引擎：MySQL 8.0/8.4、PostgreSQL 14～18、SQL Server 2019/2022
• 垂直擴展：最大 128 vCPU、864 GB RAM
• 高可用（HA）：跨可用區自動容錯移轉，SLA 99.95%
• 讀取副本：最多 10 個 Read Replicas，支援跨區域
• Private networking：可用 Private Services Access、Private Service Connect，或讓兩條私網路徑並存
• 自動儲存擴充：最大 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_18 \
  --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，不適用
• 固定資源成本較高——Primary、HA 節點、Read Pool 與儲存都要納入估算，通常高於入門 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 的系統

限制

• 成本模型不同：可從 100 PU 細粒度配置起步，但多區域、吞吐、儲存與備份會共同放大正式環境成本
• 主鍵設計要求嚴格：高寫入表若把單調遞增的時間或整數放在主鍵最前方，會產生熱點；可改用 UUIDv4、Hash 前綴或 Spanner 的 bit-reversed sequence
• 不支援原生 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，適合純後端——無即時監聽
• 同專案可建立多個資料庫：不同資料庫可依需求選 Native 或 Datastore mode；Client 未指定時會連到 (default) 資料庫
• Serverless：完全免管理，自動擴展
• 即時監聽：資料變更時主動推播給客戶端
• 離線支援：行動端可在無網路時繼續讀寫，上線後自動同步
• 強一致性：所有查詢都是強一致的（自 Firestore 起，不同於舊 Datastore 的最終一致）
• 免費層：Standard edition 每天 50,000 次讀、20,000 次寫、20,000 次刪除；每個專案只有一個資料庫套用免費額度

適用場景

• 行動應用 / PWA 的後端資料儲存
• 即時聊天、即時協作工具
• 使用者個人資料、設定、偏好
• 遊戲玩家狀態管理
• 小到中型的 Web 應用後端

限制

• 單一文件大小：最大 1 MiB
• 熱點與競爭：單一文件能承受的更新速率取決於工作負載、索引數與競爭程度；高頻更新會造成延遲或錯誤，並非固定「每秒 1 次」
• 查詢限制：不支援 JOIN；多欄位範圍／不等式與複合排序可用，但要建立對應索引並遵守查詢限制
• 匯出/匯入：大量資料操作需透過 GCS
• 不適合複雜分析：原生支援 count / sum / avg 聚合查詢，但這些是 read-time 計算（需建索引、不支援即時更新與快取），複雜分析仍建議匯入 BigQuery

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
• 同一個資料庫只能選一種模式；同一專案可以建立多個資料庫，分別採用 Native 或 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%
• GoogleSQL 查詢：可從 Bigtable Studio 或支援的 Client Library 執行 SQL，但仍遵循 Row Key、無 JOIN 與單列交易的資料模型

適用場景

• IoT 感測器資料（數十億筆時間序列）
• 金融市場資料（行情、逐筆交易）
• 使用者行為分析（推薦引擎的特徵儲存）
• 大規模時序資料庫（監控指標、日誌索引）
• AdTech（廣告技術的即時出價資料）

限制

• 正式環境最低 1 Node：即使閒置仍有節點與儲存成本；官方有期間限定的試用 Instance，但不是永久免費層
• 不是關聯式 SQL：GoogleSQL 能查詢 Bigtable，但不提供 JOIN、外鍵或跨列 ACID 交易
• Row Key 設計關鍵：設計不當會導致熱點，效能暴跌
• 次級索引需另行設計：可用 Continuous Materialized View 建立非同步次級索引，讀取仍應以 Row Key Prefix 與 Range 為核心
• 不適合小資料量：低於 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 很快」騙過——快歸快，資料量沒到那個級距，你付的是 PB 級的錢、用的是 GB 級的量，划不來。

深入學習：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 併行與速率限制：每個資料表的 INSERT 與 mutating DML 有併行、排隊與速率配額，適合批次／分析資料異動，不是高頻逐筆交易
• 串流寫入限制：Streaming Insert 有每秒行數限制
• 交易範圍不同：支援具 ACID 與 Snapshot Isolation 的多語句交易，也能 BEGIN TRANSACTION／COMMIT，但交易需遵守表數、分割區與併行限制，不能把它當 OLTP 後端
• 查詢成本難預測：On-demand 模式依掃描量計費；每月前 1 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 實戰指南

選型決策樹

面對選型問題，從上往下一題一題答，遇到符合的就停：

第 1 步：是分析還是交易？

• 主要拿來做分析 / 報表 / BI（OLAP）→ BigQuery，選型結束。
• 主要是交易讀寫（OLTP）→ 繼續第 2 步。

第 2 步：需要 SQL / 關聯式嗎？

• 需要 → 走「關聯式」分支（第 3 步）。
• 不需要，是 Key-Value 或文件型 → 走「NoSQL」分支（第 4 步）。

第 3 步（關聯式）：規模與引擎需求？

• 要全球分散式 + 水平擴展 → Cloud Spanner
• 不用全球級，但要 PostgreSQL 高效能 + 即時分析 → AlloyDB
• 一般 OLTP，或要 MySQL / SQL Server → Cloud SQL

第 4 步（NoSQL）：資料量與存取型態？

• 資料量 TB 級以上 + 要低延遲 → Bigtable
• 行動 / Web + 要即時同步、離線 → Firestore（Native mode）
• 純後端 Key-Value 查找、不用即時監聽 → Firestore（Datastore mode）

最容易出錯的兩個地方：一是把 BigQuery 拿去當 OLTP 即時後端用，二是資料量還在 GB 級就跳去選 Bigtable。把上面這四步在腦中跑過一遍，這兩個坑就繞開了。

定價比較

固定月費很容易因區域、Edition、承諾折扣與產品更新而過時。架構評估時先比較「成本形狀」，再把實際區域、 HA、複本、儲存、備份與網路流量輸入 Google Cloud Pricing Calculator：

ACE / PCA 考試常見選型題

題目 1

你的電商平台使用 MySQL 資料庫，目前部署在地端機房。團隊希望盡快遷移到 GCP，但不想修改應用程式碼。最適合的服務是？

A. Cloud Spanner B. Cloud SQL for MySQL C. AlloyDB D. Firestore

題目 2

你的全球金融交易系統需要跨三個洲的資料中心保持強一致性，每秒處理 10,000 筆交易，且 SLA 要求 99.999%。你應該使用哪個資料庫？

A. Cloud SQL with Cross-Region Replicas B. AlloyDB C. Cloud Spanner（多區域配置） D. Bigtable

題目 3

你正在開發一個行動 App，需要在使用者離線時也能讀寫資料，並在上線後自動同步。資料結構是使用者設定和偏好（文件大小 < 10 KB）。你應該使用？

A. Cloud SQL B. Firestore（Native mode） C. Firestore（Datastore mode） D. Bigtable

題目 4

你的 IoT 平台每秒從 100 萬個感測器接收資料，需要儲存 3 年的時序資料（總量 > 50 TB），查詢延遲要在 10ms 以內。最佳選擇是？

A. Cloud SQL B. BigQuery C. Bigtable D. Firestore

題目 5

你需要分析過去一年的銷售資料（約 500 GB），產生月報和季報。資料已經在 GCS 上以 Parquet 格式存放。團隊熟悉 SQL。你應該使用？

A. Cloud SQL B. Cloud Spanner C. Bigtable D. BigQuery

題目 6

你的 PostgreSQL 應用程式需要同時處理大量交易和即時分析查詢。目前 Cloud SQL 的效能已經不夠，但你不想把應用拆成兩個系統（OLTP + OLAP）。最佳方案是？

A. 升級 Cloud SQL 機器規格 B. 遷移到 AlloyDB C. 遷移到 Cloud Spanner D. 加入 BigQuery 做分析

題目 7

你的遊戲需要一個全球排行榜，所有玩家看到的排名必須一致。每天有 500 萬活躍玩家，排行榜每秒更新數千次。你的選擇是？

A. Firestore B. Cloud SQL C. Cloud Spanner D. Memorystore for Redis

題目 8

你要選一個資料庫存放機器學習模型的特徵向量（Feature Store），每次查詢需要讀取單一使用者的上千個特徵，延遲要求 < 5ms，資料量約 10 TB。最佳選擇是？

A. BigQuery B. Cloud SQL C. Bigtable D. Firestore

常見錯誤選型案例

❌ 錯誤 1：用 BigQuery 做即時 API 後端

場景：新創團隊把所有資料都放 BigQuery，連使用者登入驗證也用 BigQuery 查詢。

問題：BigQuery 的排程、欄式掃描與計費模型是為分析設計，不保證請求型資料庫所需的逐筆低延遲。頻繁小查詢還會增加掃描成本與配額壓力。

正確方案：OLTP 操作用 Cloud SQL 或 Firestore，歷史資料定期匯入 BigQuery 做分析。

❌ 錯誤 2：50 GB 資料用 Bigtable

場景：團隊看到「Bigtable 很快」就選了，結果長期支付至少一個 Cluster Node 與儲存費用，而且資料量太小，Bigtable 的效能優勢根本發揮不出來。

問題：Bigtable 最少 1 Node，適合 TB 級以上資料。50 GB 用 Cloud SQL 或 Firestore 就綽綽有餘。

正確方案：若需要可重建的低延遲快取，可用 Memorystore；若需要持久真實來源，依資料模型選 Cloud SQL 或 Firestore。

❌ 錯誤 3：用 Cloud SQL 做全球部署

場景：跨國電商用 Cloud SQL + Cross-Region Read Replicas 部署，結果美國使用者的寫入得跨太平洋繞回台灣的主執行個體，延遲 200ms+。再加上讀取副本有複寫延遲，庫存顯示對不上。

問題：Cloud SQL 的架構是「單一寫入點」，跨區域讀取副本是非同步複寫（最終一致）。

正確方案：需要全球強一致性 → Cloud Spanner。

❌ 錯誤 4：用 Firestore 存 IoT 時序資料

場景：IoT 平台把感測器資料用循序文件 ID 與被索引的單調時間欄位寫進 Firestore。一開始很順，流量提高後卻開始出現延遲與 RESOURCE_EXHAUSTED。

問題：Firestore 並沒有固定「每個文件每秒 1 次」的通用上限；真正問題是寫入集中在相同文件、Key Range 或循序索引而形成競爭與熱點。高頻時序查詢若已到 TB 級，資料模型通常也更適合 Bigtable。

正確方案：高頻時序資料 → Bigtable。

❌ 錯誤 5：直接選 Spanner 而不考慮成本

場景：小型 SaaS 公司覺得「Spanner 最強」就選了，結果長期配置多區域運算與複寫資源，但流量與一致性範圍其實用 Cloud SQL HA 就能承擔。

問題：Spanner 可從細粒度 PU 起步，但成本與架構複雜度會隨多區域、容量與吞吐需求增加。若不需要全球一致性或水平寫入擴展，額外投入沒有帶來對應價值。

正確方案：先從 Cloud SQL（或 AlloyDB）開始，等真的需要水平擴展再遷移到 Spanner。

各場景推薦速查表

進階：混合架構模式

實務上很少只用一個資料庫，下面是幾種常見的混合架構：

電商平台

全球遊戲

IoT 平台

總結

真正要記的其實沒幾條。第一個分岔是 OLTP 還是 OLAP——拿來分析、跑報表的就交給 BigQuery，剩下的才進交易資料庫的世界。接著問自己要不要 SQL：需要 JOIN、需要交易，那是關聯式的地盤；只是存 Key-Value 或文件，就往 NoSQL 走。

剩下就是看規模和特殊需求對號入座：

• 全球一致 → Spanner
• PostgreSQL 高效能 → AlloyDB
• 標準遷移、一般 OLTP → Cloud SQL
• 行動端 + 離線 → Firestore
• TB+ 低延遲 → Bigtable

最後提醒一句，真正會讓你後悔的，往往不是選了不夠強的服務，而是被「最強」兩個字牽著走。區域型 Cloud SQL 已能滿足的工作，不需要一開始就承擔 Spanner 多區域與水平擴展的成本與 Schema 複雜度。

延伸閱讀

• Cloud SQL 入門指南 — 托管關聯式資料庫完全指南
• Firestore 入門指南 — NoSQL 文件資料庫完全指南
• Bigtable 入門指南 — PB 級寬列 NoSQL 完全指南
• Cloud Spanner 深度解析 — 全球分散式關聯資料庫
• BigQuery 實戰指南 — PB 級分析完全指南
• Memorystore 入門 — 托管快取服務
• 儲存策略 — GCP 儲存服務全方位比較
• ACE 認證準備 — 考試準備攻略