Google PCD: 應用程式資料、狀態與儲存模式 — 學習指南

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

屬於 Google Professional Cloud Developer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

在 Google Cloud 上的現代應用程式，通常會結合多種資料儲存庫，以便在延遲、一致性、擴充性、成本和維運複雜度之間取得平衡。選擇符合用途的服務和模式，並了解其故障模式，是彈性設計的核心。本節摘要了 Cloud SQL、Cloud Spanner、Firestore、Bigtable、Memorystore 和 Cloud Storage 的實務指南，並探討了遷移、分區和資料保護等議題。

Cloud SQL 上的關聯式資料

Cloud SQL 提供託管的 MySQL、PostgreSQL 和 SQL Server，具備大家所熟悉的 RDBMS 語意。

私人連線
- 使用私人 IP 將資料庫流量保留在您的 VPC 內。這能免除公開傳入規則和 IP 允許清單，並避免 NAT 出口的複雜性。
- 確保路由和防火牆規則允許 VPC 到執行個體的流量。啟用私人 IP 後，系統會自動處理私人 IP 的名稱解析。
- 對於無伺服器環境 (Cloud Run、App Engine、Cloud Functions)，建議優先使用 Cloud SQL 連接器，即使是使用私人 IP，它也能處理 IAM 驗證和 TLS。
高可用性與複本
- 區域級 HA 會將主要和備用執行個體放置在不同可用區，並進行同步磁碟複製。預期在容錯移轉時會發生短暫的連線中斷；應用程式應重試暫時性錯誤並重新連線。
- 讀取複本是非同步的，可用於分流讀取流量。使用跨區域複本進行災難復原 (DR) 和提升讀取鄰近性，但需了解複本是最終一致性的。
- 可提升讀取複本以進行復原或計劃中的角色交換。請定期測試提升程序。
備份與時間點復原
- 啟用自動備份和交易/PITR 日誌。將備份安排在離峰時段，以減少 IO 爭用。
- 保留多份副本，並定期驗證還原到獨立執行個體的作業。一個無法還原的備份，在維運上等同於沒有備份。
連線集區與限制
- Cloud SQL 會強制執行最大連線數；過多的短期連線會導致 CPU 資源浪費和延遲。請使用應用程式端的連線集區 (例如 HikariCP、PgBouncer、ProxySQL)。
- 根據 CPU 核心數和工作負載的並行性來決定集區大小，而非僅根據執行個體記憶體。從較小的規模開始，再根據實證數據進行擴展。
- 對於臨時/無伺服器運算，特定語言的 Cloud SQL 連接器會為每個修訂版本維護一個集區；但仍需限制並行數量，以避免冷啟動後發生連線風暴。
資料分區與效能
- 依客戶或地區對大型多租戶結構進行分片，以減少爭用。盡可能將熱點租戶隔離。
- 謹慎建立覆蓋索引；過多的索引會減慢寫入速度並增加儲存空間。請驗證基數和述詞選擇性。
- 對熱點資料列使用樂觀鎖定或 SELECT FOR UPDATE；針對持續的寫入工作負載，調整 autovacuum (PostgreSQL) 或 InnoDB 設定 (MySQL)。

常見的故障模式與緩解措施：

VM/節點重啟後的驚群效應：限制集區大小並使用指數退避。
讀取己寫 (read-your-writes) 的複本延遲：當需要工作階段一致性時，將讀取釘選到主要執行個體。
因吵雜鄰居或維護造成的 HA 容錯移轉抖動：實作具備冪等性的連線和交易重試機制。

Cloud Spanner 上的全球規模關聯式資料庫

Cloud Spanner 提供水平擴充性以及全球一致性選項。

一致性與交易
- 強式讀取和讀寫交易使用 TrueTime 提供嚴格的外部一致性；提交時會短暫等待以確保線性一致性。
- 當資料新鮮度的要求可以稍微放寬時，過時讀取和有界過時讀取可以降低延遲，並改善讀取密集型工作負載的可用性。
- 唯讀交易可在特定時間戳記下進行多次讀取而無需鎖定；可用於建立一致的分析快照。
區域性、可用性和延遲
- 區域級執行個體在單一區域內提供高可用性。多區域設定 (例如 nam-asia-eur1) 則能跨洲提供極高的可用性和低延遲的本機讀取，同時具備全球一致的寫入。
- 選擇與您使用者地理位置相符的執行個體設定；寫入延遲會隨著跨洲仲裁的大小而增加。
擴充性與結構設計
- Spanner 根據主鍵範圍將資料分片成多個分割區 (splits)，並分散到各個節點。當鍵值單調遞增時會發生熱點問題。應避免在主鍵的前導位置使用自動遞增 ID 或持續增加的時間戳記等鍵值。
- 使用可分散寫入的複合主鍵 (例如，customer_hash、customer_id、reverse_timestamp)。
- 交錯資料表會將子資料列與父資料列並置以提升局部性及 join 效率。當子項的基數和存取模式與父項高度相關時可使用此設計。可搭配次要索引；考慮使用 STORING 子句以減少資料表查詢。
- 監控 CPU、儲存空間以及高優先級與盡力而為的操作；擴展節點以在 P95 延遲下保持足夠的裕度。
維運模式
- 用戶端使用工作階段集區；調整最小/最大工作階段數以避免建立風暴。重試次數應受限且具備冪等性；在發生 ABORTED 狀態時，應使用指數退避重試讀寫交易。
- 備份是輕量且一致的；請驗證還原到獨立執行個體的作業。變更串流和 CDC 整合可為下游系統提供動力。

權衡取捨：

強式全球寫入會增加提交等待時間；對於使用者體驗至關重要、以讀取為主的路徑，可使用過時讀取。
交錯設計能改善局部性，但也可能集中寫入壓力；請使用類似生產環境的流量進行測試。

NoSQL 維運型儲存區：Firestore 與 Bigtable

選擇符合查詢模式與吞吐量特性的 NoSQL 模型。

Firestore (文件)
- 資料模型：集合 (collections) 包含文件 (documents)；文件可擁有子集合 (subcollections)。圍繞查詢模式進行模型設計；避免對單一「熱點」文件進行深度扇出寫入 (fan-out writes)。
- 存取與交易：在 Native 模式下，文件讀取與查詢具有強一致性。使用批次寫入 (batched writes) 以達成跨多個文件的「至多一次」不可分割性 (at-most-once atomicity)，並使用交易來進行帶有競爭檢查的「讀取-修改-寫入」操作。
- 索引：單一欄位索引會自動建立。當使用多個範圍/不等式篩選器或排序順序時，必須定義多欄位複合索引。非正規化 (Denormalization) 是常見做法，能讓查詢變為僅索引 (index-only) 查詢。
- 用戶端同步：即時監聽器 (real-time listeners) 以串流方式傳送變更；離線快取則以「最後寫入者為準」(last-write-wins) 的語意進行協調。應防止無限制的監聽器扇出 (listener fan-out)；建議優先使用查詢游標與篩選器。
- 限制與故障模式：對單一文件的寫入速率是序列化的；對單一文件持續的高 QPS 更新會產生競爭 (contention)。可使用分片計數器 (sharded counters)，將計數分散到 N 個子文件中，並在讀取時進行彙總。
Cloud Bigtable (寬欄式)
- 資料列鍵 (Row-key) 的設計至關重要。Bigtable 會按字典順序對資料列進行分區；前導鍵區段會決定熱點問題 (hotspotting)。應避免使用循序鍵，例如時間戳記優先或未分片的使用者 ID。
- 模式：
  - 在鍵中使用反轉時間戳記，以利時間序列讀取：key = device#hash(device_id)#reverse_ts。
  - 對第一個元件進行雜湊或分桶以分散寫入：bucket = crc32(user_id) % 128。
- 儲存小而多欄的儲存格；避免使用跨越多個 tablet 的大型資料列。利用多個欄族 (column families) 來區分存取控制與 GC 政策。
- 吞吐量與服務提供：
  - 使用多個叢集進行複寫與達成區域性讀取鄰近性；跨叢集的寫入會變為最終一致性。
  - 調整應用程式設定檔 (app profiles) 與路由；維持充足的用戶端執行緒池與通道池。
- GC 與 TTL：基於版本與時間的 GC 會非同步地移除舊儲存格；資料會持續存在直到壓縮 (compaction) 完成，因此不可依賴即時刪除來滿足法規期限。

快取與物件儲存模式

Memorystore (Redis/Memcached)
- 快取策略：
  - 讀取穿透 (Read-through)：應用程式從快取擷取資料；若未命中，則從來源載入並填入快取。
  - 寫入穿透 (Write-through)：同步地將寫入操作同時應用於快取與來源。
  - 回寫 (Write-behind)：在快取中緩衝寫入，並非同步地刷寫；因有資料遺失風險，需謹慎使用。
- 過期與失效：
  - 應用與資料過時容忍度一致的 TTL。當真實來源 (source-of-truth) 變更時，讓相關的鍵失效；對於彙總快取，可使用版本化鍵以避免踩踏事件 (stampedes)。
  - 使用互斥鎖 (mutex) 或單飛模式 (single-flight) 來防止熱門鍵上的快取踩踏。
- 會話 (Sessions)：儲存帶有 TTL 的暫時性會話資料；若資料敏感，則對其值進行加密或僅儲存不透明權杖 (opaque tokens)。
- 使用 Redis 進行速率限制：
  - 固定視窗 (Fixed-window)：對每個身分的鍵使用 INCR 搭配 EXPIRE。
  - 滑動視窗 (Sliding-window) 或權杖桶 (token-bucket) 可達到更平滑的限制；可考慮使用 Lua 指令碼以確保不可分割性。
- 可用性：基本層 (Basic tier) 沒有容錯移轉；標準層 (Standard tier) 提供區域性高可用性 (HA)。應將快取視為易失性 (volatile)；絕不可當作權威性儲存。
範例：簡易的固定視窗速率限制
- 指令：
  - INCR rate:login:USER123:20260903T1000
  - EXPIRE rate:login:USER123:20260903T1000 60
Cloud Storage
- 物件與一致性：對於讀取、寫入、覆寫、刪除與列舉操作，具有全域強一致性。物件是不可變的 (immutable)；更新會建立新的世代 (generations)。
- 簽署的 URL (Signed URLs)：將大型檔案的上傳/下載直接在用戶端與值區 (bucket) 之間進行，以卸載應用程式的代理負擔。設定短暫的過期時間；並限制方法、路徑與內容標頭。
- 可續傳上傳 (Resumable uploads)：用於大於 5 MB 的檔案與不可靠的網路環境；使用截斷式指數輪詢 (truncated exponential backoff) 與續傳權杖 (resume tokens) 來處理 5xx/429 錯誤。
- 生命週期 (Lifecycle)：定義規則以轉換儲存空間級別、刪除舊版本及強制執行保留政策。可與物件版本控制結合，以確保推出 (rollouts) 期間的安全性。
- 通知 (Notifications)：整合 Pub/Sub 通知，在物件完成 (finalize) 或刪除時觸發下游處理，並包含前置條件 (例如 ifGenerationMatch) 以防止競爭條件 (races)。
範例：上傳本地檔案
- gsutil cp ./data/*.parquet gs://my-bucket/ingest/

遷移、一致性、分區與資料保護

資料庫遷移
- 選擇線上 vs. 離線：使用 Database Migration Service 進行線上遷移可將停機時間降至最低；當可接受維護視窗時，可選擇離線遷移以求簡便。
- Schema 優先：協調型別與約束條件；對於 Spanner，可考慮使用工具來對應 MySQL/PostgreSQL 的 schema 與資料，然後調整鍵值與索引以利分散。
- 雙軌運行與切換：在線上遷移期間，進行雙重寫入或複製變更日誌。在最終切換前，驗證資料列計數、校驗和以及關鍵查詢的行為。
Schema 遷移與回滾
- 使用版本化、自動化的遷移（例如，透過遷移工具）作為 CI/CD 的一部分。設計可新增、向後相容的變更：新增欄位與索引、回填資料、部署可同時讀寫新舊格式的程式碼，然後再移除已棄用的部分。
- 規劃帶有資料轉換的回滾：若程式碼部署失敗，需準備好停用新的寫入並依賴功能旗標；避免會阻礙回滾的破壞性遷移。
交易式 vs. 最終一致性工作流程
- 當不變性必須同步成立時（如資金轉帳、庫存扣減），使用 ACID 交易。
- 對於以讀取為主、延遲為主要考量的使用者導向功能（如動態消息、搜尋、計數器），優先選擇最終一致性。實作冪等性鍵、outbox/Saga 模式，以及帶有 backoff 的重試機制。
- 結合兩者：在交易式儲存中提交權威狀態；發布事件以供最終一致性的投影使用。
資料分區與連線管理
- 依租戶、地理位置或工作負載類型進行分區，以隔離熱點。對於 Bigtable 和 Spanner，將分區鍵編碼至主鍵中；對於 Cloud SQL，使用 schema-per-tenant 或搭配路由器的 table sharding。
- 管理連線：
  - Cloud SQL：使用連線池並重複使用；限制並行數量；錯開冷啟動時間。
  - Spanner：重複使用 session；啟動時預熱連線池；限制重試次數。
  - Memorystore：重複使用 TCP 連線；避免為每個請求建立連線。
資料保護、封存、還原驗證與刪除行為
- 備份與封存：
  - Cloud SQL：自動備份 + PITR；測試還原。
  - Spanner：託管式備份；測試還原至非生產環境。
  - Firestore：排程匯出至 Cloud Storage；驗證匯入。
  - Bigtable：備份與快照；測試複製並還原。
  - Cloud Storage：透過生命週期將物件封存至較冷的儲存類別；使用保留政策、物件鎖定與值區層級的統一存取權限進行治理。
- 還原驗證：定期還原至隔離環境，並執行驗證查詢與應用程式的 smoke tests。根據政策追蹤 RTO/RPO。
- 刪除行為：
  - Bigtable GC 與生命週期是非同步的——不要承諾立即清除。
  - Cloud Storage 版本控制會保留各代版本，直到生命週期將其移除。
  - Firestore TTL 與基於匯出的刪除是非同步的。
  - 對於有硬性刪除 SLA 的要求，設計標記刪除、排入佇列並驗證移除的流程，並附帶稽核日誌。

實務問題情境

Aurora Outfitters 正在將一個單體式電商平台遷移至 Google Cloud。他們必須：1) 將 MySQL 直接遷移 (lift-and-shift) 以降低風險，2) 處理 500 MB 的產品媒體上傳而不過載應用程式，3) 擴展產品目錄的讀取吞吐量，以及 4) 在銷售高峰期間強制執行每個使用者的速率限制。

解決方法：

將 MySQL 遷移至 Cloud SQL，使用私有 IP 與區域級 HA
- 理由：私有 IP 消除了公網暴露與 IP 允許清單，簡化了從 GKE 和 Compute Engine 進行安全連線的複雜性。區域級 HA 可防止區域性故障；預期在故障轉移時會有短暫的連線中斷，因此應用程式將實作可重試的交易與重新連線邏輯。
啟用自動備份與 PITR，並驗證還原
- 理由：自動備份與交易日誌可用於從使用者或應用程式錯誤中進行時間點還原 (point-in-time recovery)。每週排程還原至非生產實例，以驗證備份的可用性並衡量 RTO。
為目錄讀取新增唯讀複本
- 理由：將目錄查詢移至唯讀複本可減少主實例上的競爭。當需要寫後讀時（購物車/結帳），應用程式從主實例讀取；而在瀏覽目錄時，則從複本讀取，並理解複本延遲的權衡。
在應用程式端引入連線池並限制並行數量
- 理由：PgBouncer/HikariCP 限制並重複使用連線，避免在自動擴展和 HA 故障轉移期間發生連線風暴。連線池的大小根據 CPU 核心數設定，而非最大 pod 數量，以防止過載。
將媒體上傳卸載至 Cloud Storage，使用簽署的 URL 與可續傳的上傳
- 理由：應用程式發放短期的簽署 URL，供客戶端直接上傳。可續傳的上傳可適應不穩定的網路；媒體服務監聽 Pub/Sub 的完成通知以觸發處理。使用 Precondition 標頭 (ifGenerationMatch) 可防止覆寫的競爭條件。
實作 Memorystore for Redis 用於頁面快取、session 與速率限制
- 理由：Read-through 快取可減少產品頁面的資料庫負載，其 TTL 與更新頻率保持一致。Session 資料以短 TTL 暫存在 Redis 中；應用程式狀態仍保留在 Cloud SQL。使用固定視窗的 token 策略，透過 INCR/EXPIRE 實現每個使用者的請求上限。快取被視為非權威性；應用程式能容忍快取遺失並在未命中時重新填入。
為高吞吐量的目錄瀏覽功能準備一個分階段遷移至 Cloud Bigtable 的路徑
- 理由：隨著流量增長，將非正規化、為讀取優化的目錄視圖移至 Bigtable。Row key 設計為 bucket#category#reverse_ts，以分散寫入並支援時間排序的列表，而不會產生熱點。
建立 schema 遷移與回滾程序
- 理由：遷移是可新增的：新增欄位/索引，透過冪等性作業回填資料，部署可同時讀寫新舊格式的程式碼，然後再移除舊欄位。功能旗標保護新的路徑；回滾時會停用對新欄位的寫入，而無需破壞性的 DDL。
設定資料生命週期與保護政策
- 理由：Cloud Storage 值區使用生命週期規則將縮圖轉移至較冷的儲存空間，並刪除過期的暫存上傳。定期還原 Cloud SQL 備份以及 Spanner/Bigtable 備份（在採用後）進行驗證。稽核日誌記錄刪除工作流程；在合規文件中承認 Bigtable GC 是非同步的。
在客戶端與伺服器端實作帶有 truncated exponential backoff 的重試機制
- 理由：在流量高峰期間，Cloud Storage 可能會回傳 429/5xx；backoff 可平滑負載並降低錯誤率。資料庫與快取操作使用冪等性鍵以確保重試的安全性，尤其是在故障轉移與網路不穩時。