Google Cloud 資料庫

為什麼資料庫對 Cloud Digital Leader 如此重要？

每一個現代應用程式——從行動銀行 App 到物聯網外送機車車隊——最終都將其狀態儲存在資料庫中。對於 Cloud Digital Leader（CDL） 考試而言，你不需要撰寫 SQL 查詢或設計索引。你的角色是一名業務翻譯者：當專案經理描述一個工作負載時，你必須指向正確的 Google Cloud 資料庫服務並說明原因。

Google Cloud 刻意提供了廣泛的產品組合，因為沒有任何單一資料庫能完美服務所有工作負載。一個全球一致的金融帳本與即時聊天應用程式或物聯網遙測資料流，在需求上有著根本差異。CDL 的產品組合分為關聯式（Cloud SQL、AlloyDB、Cloud Spanner）與 NoSQL（Firestore、Bigtable、Memorystore）兩大家族，另外還有分析世界（BigQuery，詳見 data-warehousing-bigquery）。

本章節將從業務主管的高度逐一解說每項服務：核心使用情境、取捨考量、從地端系統的遷移路徑，以及 CDL 考試反覆出現的決策捷徑。讀完後，你應該能自信地說「這個工作負載屬於 Cloud Spanner」或「這個團隊應該整合到 Firestore」，而不必開啟任何查詢主控台。

決策框架 — 關聯式 vs. NoSQL、區域 vs. 全球

在背誦服務名稱之前，先將決定資料庫適配性的四個維度內化。這四個維度就是 CDL 考試的語言。

維度一 — 資料模型：結構化、文件、寬欄、鍵值

資料的形狀是第一道篩選器。結構化／關聯式資料存在於有外鍵的嚴格表格中（銀行帳本、ERP 系統）。文件資料是半結構化的 JSON 格式記錄（具備彈性欄位的使用者個人資料）。寬欄資料是以列鍵索引的稀疏超大型表格（IoT 感測器讀數）。鍵值資料是簡單的查找結構（工作階段快取）。

維度二 — 規模邊界：區域 vs. 全球

使用者只會從單一區域存取此資料（例如台灣限定電商平台的台北流量），還是同時從世界各地存取（例如全球股票交易平台）？Cloud SQL、AlloyDB、Firestore 與 Bigtable 是區域性或洲際多區域服務。Cloud Spanner 是唯一設計為在跨洲際提供強一致性的 Google Cloud 資料庫——這是其超能力，也是其較高的價格標籤所在。

維度三 — 工作負載模式：OLTP vs. OLAP vs. 快取

OLTP（線上交易處理） 工作負載是短暫、快速的寫入與讀取——顧客付款買咖啡。OLAP（線上分析處理） 工作負載需要掃描數十億筆資料列以產出報表——上一季各區域的銷售成績。快取工作負載需要在毫秒以下的時間讀取頻繁存取的資料——已登入使用者的工作階段令牌。Cloud SQL、AlloyDB、Spanner 與 Firestore 皆屬 OLTP。BigQuery 是 OLAP（請改用資料倉儲，詳見 data-warehousing-bigquery）。Memorystore 則是快取層。

維度四 — 一致性 vs. 可擴展性的取捨

強一致性意味著每次讀取都能看到最新的寫入——這對金融資料而言至關重要。最終一致性意味著讀取結果可能短暫落後——對於社群 App 上的「按讚」計數器而言完全可接受。Spanner 在全球規模下唯一提供強一致性。Firestore 在區域內提供強一致性。Bigtable 提供列級一致性，但其最佳化目標是吞吐量，而非多列交易。

白話文解釋

Google Cloud 的資料庫產品組合，只要停止思考 CPU 和複寫協定，改從日常生活中儲存、整理、查找資訊的場所出發，就容易理解得多。以下三個類比分別點出這個產品組合不同的面向。

類比一 — 大學圖書館系統（資料模型與專業分工）

想像台灣大學總圖書館的館際系統。主館的目錄管理最為嚴格：每本書都在固定的索書號位置，每筆借閱都記錄在嚴謹的帳冊中，館員可以立刻回答「這個 ISBN 目前有幾本在借出中？」這就是 Cloud SQL 與 AlloyDB——嚴謹的關聯式資料庫，負責業務的帳冊管理。

兒童繪本區不在乎索書號。每本書都是圖片、聲音與標籤的彈性組合。新格式每週都在增加——翻翻書、貼紙書、AR 互動書——而不需要重建整個目錄。這就是 Firestore，一個文件儲存庫，每筆記錄可以有不同結構，非常適合使用者個人資料欄位每個版本都在增加的行動 App。

期刊暨報紙剪報庫儲存了數十億筆以日期和出版品索引的剪報。沒人會問「總收入是多少？」——他們問的是「給我這家報紙在這兩個日期之間的所有剪報。」這就是 Bigtable，專為時間序列和物聯網資料打造的寬欄儲存庫，可達 PB 規模。

借閱服務台的暢銷書展示架放著當天最熱門的三本書供即取，不需要查目錄、不需要回架——直接拿走。這就是 Memorystore，一個回傳資料速度低於一毫秒的記憶體快取。

最後，館際互借網路讓台北的讀者可以即時確認紐約分館的庫存，毫無歧義。這種全球強一致性的協調就是 Cloud Spanner。

類比二 — 銀行金庫全國網路（一致性與全球規模）

想像一家在台北、倫敦與紐約都有分行的跨國銀行，例如滙豐銀行（HSBC）。傳統銀行曾在每日下班後才對帳——如果你在台北晚上 11 點提領了一萬元，紐約分行要到隔天早上批次處理後才會看到這筆更新。這就是最終一致性，對金融資料而言無法接受。

現代全球銀行需要每個時區的每個分行，在提款完成的瞬間看到相同的餘額。這就是全球強一致性，而在 Google Cloud 中只有 Cloud Spanner 能提供。Spanner 使用 Google 的 TrueTime API——一個在每個區域都運行的同步原子鐘服務——為每筆交易賦予全球排序的時間戳記。這就是為什麼 Spanner 驅動著 Google Ads（一個數十億美元規模的全球帳本），並被推薦用於金融系統、供應鏈樞紐，以及東京玩家與聖保羅玩家必須看到相同排行榜的遊戲場景。

對於不需要全球覆蓋的工作負載——例如僅限台灣的叫車平台——Cloud SQL 或 AlloyDB 成本低得多，在單一區域內同樣可靠。CDL 考試定期測試這個取捨：別為了本地工作負載「過度設計」而選 Spanner，但也別為了真正的全球交易系統「設計不足」而用 Cloud SQL。

類比三 — 24 小時便利商店後勤網路（工作負載專業分工）

一家全家便利商店連鎖通路至少運行著四套不同的資訊系統，每套都針對不同工作進行最佳化。收銀機 POS 系統在毫秒內記錄每筆交易——結構化的交易型資料庫。這就是 Cloud SQL 或 AlloyDB。

每位消費者手機上的會員 App 儲存彈性的個人資料——最愛飲品、兌換過的優惠券、常去的門市——並且必須在手機從 4G 切換到 Wi-Fi 時即時同步。這就是 Firestore，透過 Firebase SDK 內建行動端與離線同步功能。

門市 IoT 系統每 30 秒追蹤全台 6,000 家門市每台冰箱的溫度。這是每天數十億筆小型寫入，全部以 store_id + timestamp 為鍵。這就是 Bigtable，時間序列資料的寬欄主力。

每位訪客看到的首頁促銷橫幅快取，必須在 1 毫秒內回應「今日熱門優惠」。這就是 Memorystore for Redis，擺在 Cloud SQL 前端以吸收讀取流量。

總部詢問「上季全台 6,000 家門市哪些商品賣最好？」——這不是資料庫的工作，這是資料倉儲的工作，交給 BigQuery，詳見 data-warehousing-bigquery。

Cloud SQL — 熟悉的關聯式資料庫主力

引擎支援與託管責任範圍

Cloud SQL 是 Google Cloud 完全託管的關聯式資料庫服務，支援 MySQL、PostgreSQL 與 SQL Server。對於任何要將現有地端關聯式工作負載——Rails 應用程式、Drupal 網站、舊式 ERP、內部人資系統——遷移上雲的組織而言，這是最自然的第一步。

Google 處理所有「無差異的繁重工作」：作業系統修補、資料庫引擎升級、每日備份、時間點復原、自動容錯移轉到另一個可用區的備援副本。客戶只需專注於結構描述設計與查詢。

區域規模與高可用性

Cloud SQL 是區域性服務：主要執行個體位於一個區域，跨兩個可用區提供高可用性（HA），並且可以在其他區域新增讀取副本以進行讀取擴展和災難復原。實際規模上限為每個執行個體最多約 64 TB 儲存空間與 128 個 vCPU——對絕大多數企業工作負載而言相當充裕，但並非「網際網路規模」。

Cloud SQL 典型使用情境包括：SaaS 應用程式後端、內容管理系統、具有區域範圍的電子商務平台、企業內部應用程式，以及任何已在標準開源關聯式引擎上運行的工作負載。

AlloyDB — 加強版 PostgreSQL

效能特性 vs. 標準 PostgreSQL

AlloyDB for PostgreSQL 是較新的旗艦級服務。它 100% 相容 PostgreSQL，但由 Google 針對 Cloud SQL 無法承載的超大型或混合分析型交易工作負載重新設計。Google 公布的基準測試宣稱比標準 PostgreSQL 交易效能快最多 4 倍、分析查詢快最多 100 倍，這得益於在列式儲存上疊加了一個欄式記憶體引擎。

當客戶說「我們很喜歡 PostgreSQL，但已經快撐不住了」時，AlloyDB 就是正確選擇——例如一家每分鐘處理數十萬筆交易的金融科技公司，全部跑在單一區域資料庫上。它與 Cloud SQL 同樣是區域性服務，但提供近乎零停機維護，以及適用於 AI 賦能應用程式的內建向量搜尋功能。

CDL 的定位：AlloyDB 適合希望擁有 PostgreSQL 語意、超高效能與現代 AI 功能的客戶，但不需要全球多區域強一致性（那是 Spanner 的工作）。

Cloud Spanner — 全球分散、強一致性

Spanner 結合的三大特性

Cloud Spanner 是 Google 的招牌資料庫——驅動著 Google Ads、Google Photos 與 Google Play Store 的技術。它唯一地結合了資料庫業界曾認為不可能同時實現的三個特性：

1. 關聯式 SQL 語意，含結構描述與 JOIN
2. 水平擴展至數千個節點與 PB 級資料
3. 跨多洲強外部一致性

TrueTime 與全球排序

Spanner 使用 Google 的專有 TrueTime API——由每個 Google 資料中心內的原子鐘與 GPS 接收器支撐——為每筆交易賦予全球排序的時間戳記。這使得新加坡的客戶與法蘭克福的客戶能對同一帳戶進行扣款，而不會產生競爭條件。

Spanner 對於本地台灣限定的工作負載而言是殺雞用牛刀——而且費用較高。這類情境請使用 Cloud SQL 或 AlloyDB。Spanner 是以下情境的正確答案：全球遊戲排行榜、全球供應鏈庫存、跨境銀行業務、跨法域的合規系統，以及任何以前需要在 Oracle 或 PostgreSQL 上建立痛苦的自訂分片層的工作負載。

Firestore — 行動與 Web 應用程式的文件資料庫

文件模型與 Firebase 整合

Firestore 是完全託管的無伺服器 NoSQL 文件資料庫。它將資料以 JSON 格式的文件集合儲存，以與 Firebase 緊密整合著稱，為行動與 Web 開發者提供即時同步、離線支援，以及內建的用戶端安全規則。

當行動或 Web 應用程式需要以下功能時，Firestore 是首選：

• 頻繁演變的彈性結構描述
• 推播式更新（「當這份文件變更時，立即更新每支連線手機」）
• 離線優先行為（App 在搭捷運進隧道時仍能繼續運作）
• 在資料庫層強制執行的逐使用者安全規則

一致性邊界 — 區域 vs. 多區域

Firestore 在區域內提供強一致性，並提供區域性與多區域組態。它在 Spanner 的意義上並非全球性——多區域 Firestore 涵蓋一個洲（例如 nam5 涵蓋北美，eur3 涵蓋歐洲），而非具備單列強一致性的整個地球。

Firestore 典型使用情境：聊天 App、協作編輯工具、行動遊戲、社群動態、使用者個人資料服務、IoT 伴侶 App。

Bigtable — 物聯網、時間序列與分析的寬欄資料庫

吞吐量與延遲特性

Cloud Bigtable 是最初驅動 Google 搜尋、Gmail 與 Google Maps 的寬欄 NoSQL 儲存庫。它以單位數毫秒延遲處理百萬次每秒操作的大量吞吐量而設計，儲存規模可達 PB 級。

Bigtable 在以下情況是正確工具：

• 你有數十億至數兆筆小型資料列，以明顯的列鍵索引（裝置 ID + 時間戳記、使用者 ID + 事件 ID）
• 互動式查詢遠少於寫入量
• 不需要跨列交易或 SQL JOIN

CDL 考試的典型使用情境包括：IoT 遙測（10 萬台機車每 10 秒回報一次 GPS）、金融市場逐筆報價資料、廣告技術事件串流，以及運營監控（資料中心每台伺服器的每個指標）。

HBase 相容性與遷移落地點

Bigtable 也與 Apache HBase API 原生整合，使其成為從自管 Hadoop 與 Cassandra 叢集遷移的組織的絕佳落地點。

Memorystore — 毫秒以下讀取的記憶體快取

在資料層中的角色

Memorystore 是 Google Cloud 完全託管的 Redis 與 Memcached 服務。它不是主要資料庫——它是一個快取層，擺在主要資料庫（通常是 Cloud SQL 或 AlloyDB）前端，以吸收讀取流量並將延遲從數十毫秒降至低於一毫秒。

Memorystore 典型使用情境：

• 工作階段快取：儲存已登入使用者的工作階段令牌
• 排行榜與計數器：即時遊戲分數、「熱門中」清單
• API 回應快取：80% 使用者都在查詢的熱門資料
• 速率限制：追蹤某個 IP 在過去一分鐘內發出多少請求
• 聊天或通知的 Pub/Sub 廣播

在 CDL 情境中，觸發關鍵字是「毫秒以下延遲」或「降低主要資料庫負載」——兩者都指向 Memorystore。

託管 vs. 自管 — 營運取捨

TCO 與考試觸發情境

CDL 常見的情境框架是選擇 Google Cloud 託管資料庫（Cloud SQL、AlloyDB、Spanner、Firestore、Bigtable、Memorystore）與自管替代方案之間的差異——即在 Compute Engine 虛擬機上自行運行 PostgreSQL、MongoDB、Cassandra 或 Redis。

自管讓你完全掌控版本、擴充套件與組態。但你也得承擔所有故障的責任：修補、備份、容錯移轉、監控、容量規劃，以及磁碟空間爆滿時的凌晨三點警報。對大多數企業而言，人事成本遠超授權成本，託管服務幾乎總能贏得**總體擁有成本（TCO）**比較——財務框架詳見 cloud-financial-governance。

遷移路徑 — 從地端 MySQL、PostgreSQL 與 Oracle 遷移

來源與目標配對

CDL 題目中有很大一部分圍繞著遷移。建議的遷移路徑如下：

• 地端 MySQL 或 PostgreSQL → Cloud SQL，使用 Database Migration Service（DMS），提供近乎零停機的持續複寫。
• 地端 PostgreSQL 有極高效能需求 → AlloyDB，以相同的 SQL 介面搭配超高效能。
• 地端 Oracle → Cloud Spanner 或 AlloyDB。Spanner 適合需要全球規模的工作負載；AlloyDB 適合區域性但效能需求高的工作負載。Google 合作夥伴通常會先進行 Oracle 轉 PostgreSQL 遷移評估再做決定。
• 地端 MongoDB → Firestore（文件工作負載），或若團隊堅持 MongoDB 相容性，則選用 MongoDB Atlas on Google Cloud。
• 地端 Cassandra 或 HBase → Bigtable，透過 HBase 相容 API。
• 地端 Redis 或 Memcached → Memorystore，幾乎可直接替換。

CDL 考試不會要求命令列操作步驟，但會考你哪個目標資料庫對應哪個來源系統——所以請將上述配對記熟。

整合應用 — 一眼決策速查表

當 CDL 情境落到你面前時，依序走過以下觸發條件：

1. 「分析、報表、儀表板、PB 級掃描」→ BigQuery（詳見 data-warehousing-bigquery）
2. 「毫秒以下快取、工作階段、排行榜」→ Memorystore
3. 「全球、強一致性、金融／供應鏈／多區域」→ Cloud Spanner
4. 「時間序列、IoT、數十億筆小資料列、高吞吐量」→ Cloud Bigtable
5. 「行動 App、即時同步、彈性 JSON、離線」→ Firestore
6. 「遷移現有 MySQL／PostgreSQL／SQL Server」→ Cloud SQL
7. 「PostgreSQL 搭配超高效能與 AI 功能」→ AlloyDB

只要能識別這七個觸發條件，你就能回答 CDL 考試中絕大多數的資料庫題目，而無需開啟任何查詢編輯器。完整的產品組合總覽請見 https://cloud.google.com/products/databases。

CDL 層級的成本與營運考量

CDL 考試不會要求確切的金額，但你應該掌握各服務的相對成本結構：

• Memorystore 依記憶體 GB 小時計費，在小型快取情境下每月絕對成本最低。
• Cloud SQL 依執行個體 vCPU 與儲存空間計費，對穩定工作負載而言可預測。
• AlloyDB 定價為 Cloud SQL 之上的旗艦層，但對正確的工作負載而言，每元效能顯著更高。
• Firestore 是無伺服器服務，依文件讀取、寫入與刪除計費——低流量時極為便宜，流量爆發時成本可預測。
• Bigtable 依節點小時加儲存空間計費；最小生產叢集的成本並不低，因此不適合小型工作負載。
• Cloud Spanner 的每個「處理單元」成本最高，但也是全球強一致性的唯一選項。

跨越所有服務的治理與預算警示，詳見 cloud-financial-governance。

常見問題

Cloud Spanner 與 Cloud SQL 何時選哪個？最簡單的記憶方法是什麼？

答： 問自己一個問題：「這個工作負載是否需要同時在多個洲際間保持強一致性？」 若是，選 Spanner。若否，選 Cloud SQL（若效能要求高則選 AlloyDB）。Spanner 是旗艦層服務；除非工作負載確實需要全球 ACID 交易，否則不必付費選用。

Firestore 與 Firebase Realtime Database 是同一個產品嗎？

答： 不是。Firestore 是較新、可擴展性更佳、查詢能力更強的 Google Cloud 產品。Firebase Realtime Database 是較舊的前代產品，雖仍受支援，但新專案通常不建議使用。在 CDL 考試中，「Firestore」是文件資料庫的標準答案。

我可以直接在 Google Cloud 上運行 Oracle 工作負載嗎？

答： 可以——Google Cloud 透過與 Oracle 的合作提供 Oracle Database@Google Cloud，但對大多數遷移而言，建議重新平台化至 AlloyDB（PostgreSQL 相容工作負載）或 Cloud Spanner（需要全球規模的工作負載）。CDL 考試偏好以重新平台化作為長期降低成本的方案。

為什麼 Bigtable 不是「全球金融帳本」的答案？

答： Bigtable 不支援多列 ACID 交易或 SQL JOIN。金融帳本需要保證資金不會被重複支出，即使請求同時打到多個伺服器也不例外。只有 Cloud Spanner 在全球範圍內提供這樣的保證。Bigtable 適用於以鍵為基礎的高吞吐量工作負載（IoT、時間序列），而非交易型帳本。

使用託管資料庫代表我的團隊沒有任何責任嗎？

答： 不對。根據責任共擔模式，Google 負責修補、硬體、複寫與備份。客戶仍然擁有：結構描述設計、查詢效能、存取控制（IAM）、應用程式層級的資料驗證，以及確保敏感資料以適當方式加密。託管不等於無人管理。

這些資料庫如何連接到我的應用程式？

答： 所有 Google Cloud 資料庫都支援主流語言（Java、Python、Go、Node.js、.NET）的標準用戶端程式庫。若要私有網路連線，可透過 VPC Service Controls 與 Private Service Connect 連接。對於運行在 Cloud Run 或 Cloud Functions 上的無伺服器應用程式，Google 提供直接的 VPC 連接器。在大多數情況下，你不需要手動管理 IP 位址或 DNS。

總結 — 從產品組合到決策

Google Cloud 的資料庫產品組合廣泛是有其目的的。每項服務都是專家：Cloud SQL 是熟悉的關聯式資料庫主力、AlloyDB 是超高效能的 PostgreSQL、Cloud Spanner 提供全球強一致性、Firestore 適合行動與文件工作負載、Bigtable 適合 IoT 與時間序列、Memorystore 是記憶體快取層。

作為 Cloud Digital Leader，你的工作不是設計結構描述——而是傾聽業務情境，識別主要的資料模型、規模邊界、工作負載模式與一致性需求，然後自信地推薦正確的服務。將這份知識與 cloud-value-proposition 的雲端價值框架，以及 cloud-financial-governance 的治理視角結合，你就擁有了一套完整的資料庫論述，足以應對考試與現實世界的雲端策略對話。