條件 1
主要是線上交易，還是分析掃描？
先區分每次請求的點查詢／異動，和跨大量資料的 JOIN、彙總與報表。兩者常需要不同的資料路徑。
還要確認： 延遲與併發目標、交易範圍、分析資料的更新頻率，以及 CDC／批次管線。
服務選型速查
GCP 資料庫怎麼選？
先描述資料怎麼寫、怎麼查，再比較交易與復原條件。
查看比較範圍與版本條件
比較六個常見資料服務家族，不是完整產品清單；PostgreSQL 工作負載也可另評估 AlloyDB。Firestore 以 Standard edition 的 Native mode 為基準；Memorystore 表格以 Redis Basic／Standard 為基準，Valkey、Redis Cluster 與已棄用的 Memcached 另核對。容量、SLA、延遲與費用都要連同引擎、配置和工作負載閱讀。
官方資料查核：
選型前先問這 6 件事
這些條件可能同時成立。先找候選，再驗證限制；不能只靠一個關鍵字決定架構。
條件 2
需要既有 SQL 引擎相容性或分散式交易？
Cloud SQL 可沿用支援的引擎；Spanner 提供分散式資料庫能力，但不是直接替換所有 PostgreSQL／MySQL 功能。
還要確認： 驅動程式、SQL 方言、主鍵、遷移成本；PostgreSQL 也另比較 AlloyDB。
條件 3
以文件讀寫、監聽與離線快取為主？
Firestore Native mode 的 SDK 與文件模型可支援這些需求；離線快取和離線交易是不同能力。
還要確認： edition／模式、索引、Security Rules、熱門文件與重連同步行為。
條件 4
以 row key／範圍查詢承接高吞吐量？
Bigtable 適合這類存取模式；有 SQL 查詢能力，不代表可以用跨列交易來維持訂單一致性。
還要確認： row key 分布、單列原子性、app profile 路由、跨叢集一致性與容量餘裕。
條件 5
需要快取，且已說清楚資料損失條件？
Memorystore 各產品的引擎、分片與持久化能力不同。快取可以減少主資料庫負載，但還需處理失效與重建。
還要確認： Redis／Redis Cluster／Valkey、RPO／RTO、失效策略與快取擊穿保護。
條件 6
跨區域到底要解決什麼？
就近讀取、強一致交易、災難復原、資料落地與 SLA 是不同需求；不能把所有 multi-region 標籤當成相同保證。
還要確認： 寫入路徑、複寫延遲、故障轉移、資料位置與符合配置條件的 SLA。
依條件比較
這些服務可以搭配使用。比較的是指定範圍內的能力與條件，不是效能或成本排名；各欄的產品範圍見下方說明。
表格可左右捲動；鍵盤可按 Tab 聚焦表格，再用左右方向鍵查看欄位。
| 比較條件 | Cloud SQL | Spanner | Firestore | Bigtable | Memorystore | BigQuery |
|---|---|---|---|---|---|---|
| 資料模型 | 關聯式；沿用支援的資料庫引擎與 SQL 生態 | 關聯式與 SQL；方言、功能及配置依 edition 核對 | 文件與集合；查詢模型不同於關聯式 JOIN | 寬欄／key-value；提供 HBase 相容性與 SQL 查詢能力，並非關聯式引擎 | Redis 的 key-value／資料結構；Valkey、Redis Cluster 為其他產品選項 | 分析型 SQL；大量掃描、彙總與 JOIN，不以逐筆 OLTP 為主要用途 |
| 擴展方式 | 調整主要執行個體規格；讀取副本分擔讀取，不會分攤主要寫入 | 以 processing units／節點水平擴展；schema、主鍵分布與熱點仍影響效能 | 服務管理擴展；仍需設計索引、避免熱門文件與突增流量 | 增加叢集節點與資料分片；row key、熱點和存取模式影響效益 | 本表的 Redis 調整執行個體容量；分片擴展需另看 Redis Cluster／Valkey | Google 管理執行資源；容量型可設定 reservation、baseline 與 autoscaling slots |
| 容量邊界 | 依引擎、edition 與機型核對；不能將單一數字套用所有配置 | 依運算容量、edition 與配額限制；不是無上限 | Standard 單文件上限 1 MiB（1,048,576 bytes）；另有索引與請求等限制 | 節點、儲存類型與配額限制；必須保留容量與效能餘裕 | 依產品與節點型號核對可用記憶體；須保留系統與持久化作業所需空間 | 大型資料倉儲；仍受工作、資料表、載入等配額與限制約束 |
| 位置複寫 | 主要寫入在一個區域；HA 跨 zone，跨區域副本用於讀取／災難復原 | 可選 regional、dual-region 或 multi-region；跨區域配置依 edition 支援 | 選定 regional 或 multi-region 位置；不是任意全球複寫配置 | 可配置跨位置叢集複寫；路由選擇影響一致性及故障轉移 | 本表 Redis 不提供跨區域複寫；Valkey 有不同的跨區域能力 | Dataset 有位置；選 US／EU multi-region 不會自動提供跨區域複寫或區域備援 |
| 交易範圍 | 支援引擎的 ACID 交易；隔離等級及行為依 MySQL／PostgreSQL／SQL Server | 支援跨資料列／資料表的 ACID 交易與強一致讀取 | 支援跨文件原子交易；有時間／請求限制，離線時交易會失敗 | 資料列層級原子性；不支援跨列原子交易，單列交易的路由另有條件 | 依產品支援的 Redis／Valkey 命令核對；不能視為跨資料庫的關聯式 ACID 交易 | 支援多語句 ACID 交易與 snapshot isolation；不是不支援交易 |
| 一致性 | 以主要資料庫交易為準；非同步讀取副本可能落後，不能假設立即讀到最新寫入 | 強一致性不代表每個區域寫入延遲相同；leader、quorum 與地理距離要一起評估 | 資料庫提供強一致讀取；離線快取可能是舊資料，重連同步不等於離線交易 | 單叢集提供強一致；多叢集路由通常為最終一致，需依 app profile 核對 | 本表 Standard 使用非同步複寫；HA 或 RDB 快照都不保證完全不丟資料 | 原生資料表的交易讀取使用一致快照；外部資料來源在變動時沒有相同保證 |
| 自動擴展 | 可啟用儲存自動增加；不代表 CPU、記憶體或寫入能力同步自動擴展 | 手動配置或使用支援 edition 的 managed autoscaler；須設上下限與目標 | 不需配置節點；資料分布、索引與競爭仍可能形成瓶頸 | 可啟用節點 autoscaling，設定 CPU／儲存目標與非零上下限；再平衡需要時間 | 本表 Redis 容量需主動調整；其他產品的擴展方式分別核對 | On-demand 使用共用資源；capacity-based 依 edition、reservation 與配額管理擴縮 |
| 容量責任 | 配置執行個體，管理容量、連線、維護與復原設定 | 全代管，但仍需規劃運算容量；不等於無請求就免費 | 管理服務容量；你仍負責資料模型、Security Rules／IAM、索引與預算 | 配置叢集與節點；不因沒有請求就自動縮至零節點 | 配置容量與可用性等級；閒置仍可能計費 | 不需管理伺服器；仍需設計容量、查詢、資料生命週期與存取權限 |
| 計費項目 | 執行個體資源、HA／副本、儲存、備份與網路等項目 | 運算容量、資料／備份儲存、跨區域複寫與網路；依 edition／配置計費 | Standard 的文件操作、部分查詢的索引項目讀取、儲存與網路等 | 每個叢集的節點、儲存、備份與複寫／網路等項目 | 依產品、配置記憶體／節點、replica 及區域等計費 | On-demand 依處理資料量，或 capacity-based 依 slot 時間；儲存等另計 |
服務說明與官方依據
本頁的場景與判斷是教學整理；產品限制依連結的官方文件核對，實際部署仍需確認區域、配額及當期支援。
關聯式線上交易
Cloud SQL
代管 MySQL、PostgreSQL 與 SQL Server
- 適合先評估
- 沿用 MySQL／PostgreSQL／SQL Server 的應用、需要 JOIN 與多表交易的網站或業務系統。
- 需要換個方向時
- 若確實需要分散式寫入擴展與跨區域一致交易，另評估 Spanner；不是資料量增加就必須換產品。
- 交易邊界
- 支援引擎的 ACID 交易；隔離等級及行為依 MySQL／PostgreSQL／SQL Server
- 一致性條件
- 以主要資料庫交易為準；非同步讀取副本可能落後，不能假設立即讀到最新寫入
- 擴展與容量
- 可啟用儲存自動增加；不代表 CPU、記憶體或寫入能力同步自動擴展
- 計費提醒
- 執行個體資源、HA／副本、儲存、備份與網路等項目
複習時分清楚： 分開處理主要寫入、讀取副本、同區域 HA 與跨區域災難復原。增加唯讀副本不會把單一寫入來源變成多區域寫入。
延伸閱讀：Cloud SQL 教學分散式關聯資料庫
Spanner
具強一致交易的分散式資料庫
- 適合先評估
- 需要分散式關聯模型、水平擴展與一致交易，且團隊能接受相容性、schema 與成本取捨的系統。
- 需要換個方向時
- 只需保留既有引擎相容性時先比較 Cloud SQL／AlloyDB；單純因為是多租戶或大型資料集，並不足以決定採用。
- 交易邊界
- 支援跨資料列／資料表的 ACID 交易與強一致讀取
- 一致性條件
- 強一致性不代表每個區域寫入延遲相同；leader、quorum 與地理距離要一起評估
- 擴展與容量
- 手動配置或使用支援 edition 的 managed autoscaler；須設上下限與目標
- 計費提醒
- 運算容量、資料／備份儲存、跨區域複寫與網路；依 edition／配置計費
複習時分清楚： SLA 依配置：dual-region／multi-region 為 99.999%；regional 通常 99.99%，Stockholm regional 為 99.95%。仍須符合 SLA 條件，不是端到端應用可用性保證。
官方依據
無伺服器文件查詢
Firestore
文件資料庫（本表：Standard／Native mode）
- 適合先評估
- 文件導向的行動／Web 應用，需要支援 SDK 的即時監聽與離線快取。
- 需要換個方向時
- 大量關聯 JOIN 或全庫掃描報表應比較其他服務；不要只因為資料是 JSON 就省略查詢與索引設計。
- 交易邊界
- 支援跨文件原子交易；有時間／請求限制，離線時交易會失敗
- 一致性條件
- 資料庫提供強一致讀取；離線快取可能是舊資料，重連同步不等於離線交易
- 擴展與容量
- 不需配置節點；資料分布、索引與競爭仍可能形成瓶頸
- 計費提醒
- Standard 的文件操作、部分查詢的索引項目讀取、儲存與網路等
複習時分清楚： 先辨認 edition 與 Native／Datastore 等模式。Native 的離線快取與排隊寫入，不代表 transaction 能在離線時執行。
延伸閱讀：Firestore 教學高吞吐量 NoSQL
Bigtable
以 row key 組織的寬欄資料庫
- 適合先評估
- 依 row key 或連續範圍讀寫的時序、IoT、廣告等高吞吐量資料。
- 需要換個方向時
- 跨列 ACID 或關聯式 JOIN 不是它的核心模型；資料大小只是成本與容量因素，沒有一律小於 1 TB 不能用的門檻。
- 交易邊界
- 資料列層級原子性；不支援跨列原子交易，單列交易的路由另有條件
- 一致性條件
- 單叢集提供強一致；多叢集路由通常為最終一致，需依 app profile 核對
- 擴展與容量
- 可啟用節點 autoscaling，設定 CPU／儲存目標與非零上下限；再平衡需要時間
- 計費提醒
- 每個叢集的節點、儲存、備份與複寫／網路等項目
複習時分清楚： SQL 語法支援不等於具備關聯式交易。一般列異動具原子性，但 read-modify-write／check-and-mutate 等單列交易須配合單叢集路由設定。
延伸閱讀：Bigtable 教學快取與記憶體資料結構
Memorystore
記憶體資料服務（本表：Redis Basic／Standard）
- 適合先評估
- 應用快取、可接受重建／資料損失條件的 session、計數與排行榜。
- 需要換個方向時
- 若作唯一資料來源，必須先驗證產品的持久化、備份、故障轉移及 RPO／RTO；不能把所有 Memorystore 產品說成完全不持久化。
- 交易邊界
- 依產品支援的 Redis／Valkey 命令核對；不能視為跨資料庫的關聯式 ACID 交易
- 一致性條件
- 本表 Standard 使用非同步複寫；HA 或 RDB 快照都不保證完全不丟資料
- 擴展與容量
- 本表 Redis 容量需主動調整；其他產品的擴展方式分別核對
- 計費提醒
- 依產品、配置記憶體／節點、replica 及區域等計費
複習時分清楚： Memorystore 包含 Valkey、Redis Cluster、Redis；Memcached 已棄用。Redis Standard 的 HA 與持久性要分開；Valkey 的能力不能直接套用到 Redis。
官方依據
分析與資料倉儲
BigQuery
無伺服器分析平台
- 適合先評估
- BI、報表、事件分析、大範圍掃描與分析型資料處理。
- 需要換個方向時
- 應用每次請求的低延遲點查詢與高頻逐筆交易，通常先評估 OLTP 服務；實際延遲仍需量測。
- 交易邊界
- 支援多語句 ACID 交易與 snapshot isolation；不是不支援交易
- 一致性條件
- 原生資料表的交易讀取使用一致快照；外部資料來源在變動時沒有相同保證
- 擴展與容量
- On-demand 使用共用資源；capacity-based 依 edition、reservation 與配額管理擴縮
- 計費提醒
- On-demand 依處理資料量，或 capacity-based 依 slot 時間；儲存等另計
複習時分清楚： 有 SQL 和 ACID 不代表適合所有交易工作負載。把線上系統與分析管線分開，並核對資料新鮮度、查詢容量與成本。
官方依據
用情境檢查你的判斷
先寫下候選與排除理由，再展開參考判斷。能說明限制，比只選對服務名稱更有用。
情境一：分析管線要一起提交兩張表
每日匯總作業要同時更新 BigQuery 的兩張原生表格，任一失敗就全部撤銷。另一個需求是購物車每次請求都要低延遲更新。兩者能否因為「都需要交易」就選相同服務？
查看參考判斷與檢核標準
BigQuery 支援多語句 ACID 交易，可先核對支援的 DML、交易衝突與 snapshot isolation 來處理匯總；這不表示它適合購物車的高頻點查詢。購物車需依模型、交易與延遲目標另比較 Cloud SQL／Firestore 等 OLTP 選項。外部資料來源的快照保證還有不同限制。
自行檢核
- 能說出 BigQuery 支援交易，並區分交易能力與工作負載適配性。
- 列出兩個需求各自的延遲、併發與失敗恢復條件。
- 知道永久物件的 DDL 不在 BigQuery 多語句交易支援範圍內。
情境二：Spanner 品牌名稱能保證五個 9 嗎？
團隊用 regional Spanner 部署，提案寫「採用 Spanner，所以整個應用達到 99.999% SLA」。你要修改哪兩個假設？
查看參考判斷與檢核標準
先改配置假設：dual-region／multi-region 的 SLA 為 99.999%，regional 通常為 99.99%，Stockholm regional 為 99.95%，還需符合正式 SLA 的條件。再改應用假設：資料庫服務的 SLA 不能直接當成包含網路、應用與其他依賴的端到端可用性；應定義應用 SLO，驗證依賴與故障恢復。
自行檢核
- 查到正確的 instance configuration 與適用 SLA。
- 區分產品 SLA、應用 SLO 與實測可用性。
- 說明跨區域配置的延遲、成本及資料落地取捨。
情境三：感測資料與帳戶轉帳共用 Bigtable？
系統以裝置 ID／時間範圍查詢大量感測資料，另一部分需要從 A 帳戶扣款並對 B 帳戶入帳，兩筆位於不同資料列。Bigtable 的單列原子性是否能涵蓋兩種需求？
查看參考判斷與檢核標準
感測資料可先評估 Bigtable，但要設計避免熱點的 row key、容量與路由一致性。單列原子性不能保證兩列轉帳一起提交；需跨列 ACID 的交易資料另比較 Cloud SQL 或 Spanner，並規劃事件／分析管線。Bigtable 的 SQL 查詢支援也不改變這個交易邊界。
自行檢核
- 能指出單列原子性與跨列交易的差別。
- 說明感測資料的 row key、查詢範圍與路由條件。
- 讓交易需求決定候選，再驗證引擎相容性、規模與復原。
複習時帶走的重點
- 先看存取模式、交易範圍、一致性與延遲，再看資料量；同一系統可以搭配 OLTP、快取與分析服務。
- Cloud SQL：主要寫入、唯讀副本、HA 與跨區域災難復原是不同配置；儲存自動增加不等於所有資源自動擴展。
- Spanner：強一致交易與水平擴展；SLA、容量、autoscaler 與費用都依 edition／配置核對。
- Firestore：Native 的文件模型、索引、即時監聽與離線快取；Standard 單文件上限 1 MiB，離線交易會失敗。
- Bigtable：row key 與單列原子性；跨叢集路由、一致性和故障轉移要一起設計。
- Memorystore：先指定產品與引擎，再談快取、持久化、複寫與資料損失；Memcached 已棄用。
- BigQuery：支援 SQL 與多語句 ACID，主要適合分析；Dataset 的 multi-region 位置不自動等同跨區域備援。
- 不把延遲寫成全服務通用的毫秒保證，也不把某區域最低規格月費當成普遍價格。