Google ACE: 儲存、資料庫與資料服務 — 學習指南

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

總覽

本節為 Google Cloud 的儲存、資料庫與分析資料服務，提供一份實用、著重於營運的參考資料。內容強調設定模式、存取控制、耐用性機制、效能與成本特性，以及安全復原實務。目標是幫助您決定特定工作負載該使用哪種服務、了解營運上的權衡取捨，並預測常見的故障模式。

Cloud Storage 設計、存取、生命週期與保護

Cloud Storage 是耐用、高可用性的物件儲存服務，用於存放非結構化資料與備份。

• 值區與物件：值區 (Bucket) 是位於特定位置 (地區、雙地區或多地區) 的全域命名空間，其中包含不可變的物件版本。選擇值區位置時，應考量如何將輸出流量降到最低並符合資料存放地的要求。
• 儲存空間級別：根據存取頻率使用 Standard (常用)、Nearline (最低約 30 天)、Coldline (最低約 90 天) 和 Archive (最低約 365 天)。對於災難復原 (DR) 備份，Coldline 是常見的預設選項。您可以在同一個值區內，為不同物件混合使用不同的級別。
• 生命週期規則：透過 Age、CreatedBefore、MatchesStorageClass 和 NoncurrentVersion 等條件，自動化執行儲存級別轉換與刪除。例如，在 90 天後轉換、365 天後刪除的設定如下：
  1. lifecycle.json:

undefined

2. 套用規則：

undefined

• 保留政策與訴訟保留：保留政策可防止物件在指定期限到期前被刪除或修改；鎖定政策是不可逆的操作。訴訟保留是針對個別物件設定，必須先清除才能刪除物件。

存取控制與共用：

• 統一與精細：建議優先使用統一值區層級存取 (Uniform bucket-level access, UBLA)，僅透過 IAM 管理權限。精細存取 (物件 ACL) 是舊版功能，會使稽核與權限傳播變得複雜。啟用 UBLA 會停用 ACL，並可能立即影響依賴 ACL 的現有整合。
• 已簽署的網址：若要提供無需 Google 身分即可進行的短期存取，請使用已簽署的網址。建議透過 IAM 簽署以避免使用服務帳戶金鑰檔案：

undefined

請確保該服務帳戶對自身擁有 service account token creator 權限，或透過具備簽署者角色的身分取得權限。

• 加密：預設為伺服器端加密；當您需要控制金鑰與稽核軌跡時，可在值區或個別物件層級啟用 CMEK。請監控 KMS 金鑰的可用性與輪替；CMEK 不可用將會阻擋上傳與解密操作。
• 版本管理：啟用物件版本管理，以便在覆寫或刪除後保留非現行版本。搭配生命週期規則，可讓非現行版本過期並控制儲存空間增長。請注意，當存在大量版本時，可能會影響用戶端的列舉邏輯。

故障模式與緩解措施：

• 意外刪除或覆寫：使用版本管理與保留政策。為符合嚴格的合規性要求，請鎖定保留政策。
• 公開存取設定錯誤：強制執行公開存取權限防護與 UBLA。使用 Cloud Asset Inventory 和政策分析工具定期稽核。
• 超額成本：生命週期規則、物件層級的儲存級別，以及「請求者付費」功能有助於減少意外開銷。使用 Cloud Monitoring 指標與預算進行監控。

實用指令：

• 建立具備 UBLA 與保留政策的值區：

undefined

undefined

用於運算工作負載的區塊與檔案儲存

根據存取模式、效能需求與耐用性要求，為 Compute Engine 和 GKE 選擇合適的儲存方案。

• Persistent Disk (PD)：耐用的區塊儲存，分為可用區級或地區級。類型：Standard (HDD) 適用於循序傳輸量；Balanced (pd-balanced) 和 SSD (pd-ssd) 適用於低延遲與高 IOPS 的場景。地區級 PD 會跨可用區同步複製資料，實現更快的復原。PD 可建立快照、線上調整大小，並以唯讀模式掛載到多個 VM (讀寫模式則為單一寫入者)。
  • 權衡取捨：SSD 的 IOPS 成本較高；HDD 成本效益高，但隨機 IO 的延遲也高。地區級 PD 成本較高，但能降低 RTO (復原時間目標)。
• Local SSD：NVMe 或 SCSI 介面的暫時性儲存，具備極高的 IOPS 與極低的延遲。VM 停止或主機維護時資料會遺失；僅將其用於暫時性快取或已複製的資料。請將資料備份或複製到他處以避免資料遺失。
• Filestore：用於 POSIX 共用檔案語意的託管式 NFS 服務。基本版是可用區級；企業版與更高等級則提供地區級高可用性 (HA)，具備同步複製與更高的 IOPS。非常適合 GCVE、HPC 暫存空間、媒體渲染，以及需要共用檔案鎖定的應用程式。
  • 權衡取捨：NFS 引入了用戶端快取與鎖定語意；不同等級的傳輸量與延遲有所不同；不適合像 local SSD 那樣，用於個位數微秒延遲的小型隨機 IO。

故障考量：

• 主機維護：Local SSD 資料會遺失；可透過應用程式層級的複製來保護。
• 可用區中斷：可用區級 PD 與基本版 Filestore 會中斷服務；可使用地區級 PD 或 Filestore 企業版以達成高可用性。
• 快照一致性：若要建立具備應用程式一致性的 PD 快照，需與檔案系統凍結或資料庫原生靜默 (quiesce) 協同運作，以避免進入崩潰復原的空窗期。

受託管的資料庫與資料服務

Cloud SQL (受託管的 MySQL、PostgreSQL、SQL Server)：

• 設定：選擇機器規格、儲存空間類型、連線方式 (建議使用私有 IP)、若使用公開 IP 則需設定授權網路、維護時段，以及用於效能診斷的 insights。使用連線池 (例如 Cloud SQL Auth Proxy、PGbouncer) 以避免超出連線數與 CPU 的限制。
• 高可用性：區域級 HA 執行個體會在另一個可用區部署一個備用執行個體，並採用同步儲存空間複寫；故障轉移是自動的。預期在故障轉移期間會有短暫的寫入中斷時間。
• 複本：使用讀取複本來擴展讀取能力並分流 BI 工作負載；使用外部複寫來進行遷移。監控複本延遲 (replica lag) 並設計冪等的讀取器。
• 備份與 PITR：啟用自動備份與二進位/WAL 記錄，以實現時間點復原 (point-in-time recovery)。定期測試還原作業。 gcloud sql instances patch my-sql –backup-start-time=03:00 –enable-bin-log
• 故障模式：長時間執行的交易會阻擋 vacuum/checkpointing；連線數突增會導致系統顛簸 (thrash)；如果配額不足，儲存空間自動成長可能會停滯。針對 CPU、記憶體、連線數、複本延遲和磁碟用量設定警示。

Cloud Spanner：

• 規模與區域性：提供區域級或多區域執行個體，具備同步複寫與全球強一致性。擴展節點以增加吞吐量和儲存空間；主導區域 (leader region) 的位置會影響寫入延遲。
• 結構與鍵值：設計主鍵以避免熱點 (hotspots)；對於時間序列資料，使用帶有雜湊或隨機前綴的複合鍵來分散寫入。針對查詢模式使用次要索引，並考慮將經常被篩選的欄位儲存在一起。保持交易簡短且有界限，以最小化鎖定競爭 (lock contention)。
• 交易：透過 TrueTime 實現外部一致性的強一致性分散式交易。寫入延遲受限於法定數量 (quorum)；衝突會導致交易中止——使用退避演算法重試。

Firestore 與 Bigtable：

• Firestore (原生模式)：文件儲存，具備集合 (collections)、即時監聽器、單次交易最多可橫跨 500 個文件的交易功能，以及對文件讀取和大多數查詢的強一致性。最適合用於行動/網頁應用程式資料、階層式 JSON 和事件驅動的應用程式。
• Bigtable：寬欄式資料庫，適用於 PB 等級規模與低於 10 毫秒的延遲。僅支援單行交易；設計列鍵 (row keys) 以避免熱點。非常適合時間序列、物聯網 (IoT)、個人化和大規模計數器。不適用於臨時性的 join 或複雜的彙總。

Memorystore：

• Redis 與 Memcached：提供微秒到毫秒等級延遲的記憶體內快取。基本層 (Basic tier) 沒有 HA；標準層 (Standard tier) 為 Redis 提供具備自動故障轉移的區域級 HA。應將其視為暫時性的 (ephemeral)；不要用作記錄系統 (system of record)。

BigQuery：

• 資料集與資料表：以資料集進行組織；在專案、資料集、資料表、欄和列的層級控制存取權限。使用分區資料表 (partitioned tables) 和叢集資料表 (clustered tables) 來控制掃描的位元組數與成本。
• 載入與查詢工作：從 Cloud Storage、Cloud SQL 匯出資料或透過串流插入來載入。使用空跑 (dry runs) 來預估成本： bq query –use_legacy_sql=false –dry_run=true ‘SELECT …’
• 存取控制：在資料集範圍內授予 BigQuery Data Viewer 權限給唯讀的使用者；使用授權檢視 (authorized views) 或資料列層級/資料欄層級安全性來實現最小權限原則。

資料移動、遷移、驗證與營運的權衡取捨

遷移與傳輸：

• Database Migration Service (DMS)：用於透過複寫（replication）以最少停機時間，將同質資料庫遷移至 Cloud SQL。透過延遲指標（lag metrics）和校驗和（checksum）比較來驗證切換（cutover）。
• Cloud Storage 傳輸：Storage Transfer Service 用於重複性或事件驅動的傳輸；gsutil -m rsync 用於帶有校驗和的一次性同步複製；Transfer Appliance 用於大規模的離線搬遷。
• 匯入/匯出：Cloud SQL 可匯出至 Cloud Storage；重新匯入支援 PITR 啟動（bootstrap）和資料驗證。BigQuery 支援從 Cloud Storage 進行批次載入，並匯出為 Avro/Parquet 格式供下游使用。
• 驗證：使用物件校驗和（CRC32C）、資料列計數、抽樣查詢以及應用程式層級的不變性（invariants）。對於 BigQuery，可比較來源和目標之間的 GROUP BY 計數或雜湊值。

效能、可用性、容量與成本的權衡取捨：

• Cloud Storage：透過將運算資源共置（co-locating）來優化輸出（egress）流量；根據存取頻率選擇儲存空間級別；使用雙區域或多區域以獲得跨可用區的彈性及更高的可用性，但儲存成本也較高。
• PD/Filestore：SSD 用於低延遲 IO；HDD 用於高吞吐量；區域性複寫以達成高可用性（HA）；適當調整 IOPS 大小以避免限流（throttling）。
• Cloud SQL：垂直擴展（Vertical scaling）簡單但有限制；唯讀複本（read replicas）可分擔讀取流量；高可用性（HA）增加了可用性，但未增加讀取容量；儲存空間級別會影響延遲和成本。
• Spanner：具備強一致性的水平擴展能力；高昂的成本可由全球性的 RPO/RTO 和簡化的分片（sharding）所抵銷。寫入操作對主鍵（key）設計和主導區域（leader region）的延遲很敏感。
• Firestore/Bigtable/Memorystore：根據延遲、資料模型和一致性需求來選擇。記憶體內快取可減少資料庫負載，但增加了快取失效（cache-invalidation）的複雜性。
• BigQuery：On-demand 成本與掃描的位元組數成正比；分割（partitioning）/分群（clustering）和述詞下推（predicate pushdown）可減少開銷。固定費率（Flat-rate）預留以承諾換取成本的可預測性。

故障排除與安全復原：

• Cloud Storage：使用物件版本控制和保留政策來復原；檢查 Cloud Logging 的資料存取日誌以稽核讀/寫事件；確保在復原期間已啟用 CMEK 金鑰。
• PD/Filestore：從快照或備份還原；執行 fsck 和資料庫復原模式；在建立快照前，透過應用程式層級的靜止（quiesce）來確保一致性。
• Cloud SQL：為執行 PITR，還原到一個新的執行個體，以避免主要執行個體上的資料遺失；透過唯讀測試進行驗證；維護防火牆和私有 DNS 以實現安全的切換模式。
• Spanner/Bigtable：透過金鑰存取歪斜（key access skew）來調查熱點（hotspotting）問題；使用 Monitoring 來追蹤延遲和限流情況；為被中止的交易或被速率限制的操作實作退避（backoff）和重試機制。
• BigQuery：透過執行詳細資訊來診斷緩慢的查詢；新增分割區和分群；限制使用 SELECT *；在適當時機將中間結果具體化（materialize）。在時間旅行（time travel）視窗內，透過還原快照或從快照時間點複製來復原被刪除的資料表。

實務問題情境

Contoso Retail 正在整合其備份與分析資料，同時強化存取控制，並為其交易系統啟用時間點復原（point-in-time recovery）。他們需要：儲存應用程式備份並自動分層、提供短期的檔案分享給第三方、為一個小型的關聯式工作負載啟用 PITR，以及在執行前估算分析查詢的成本。

方法：

1. 建立一個啟用 UBLA、保留政策和生命週期的區域級 Cloud Storage 值區。
   • 指令：

undefined

undefined

undefined

• 理由：UBLA 將授權集中在 IAM 中管理，並提升了可稽核性。一年的保留政策可防止意外刪除。生命週期會在 90 天後將備份轉移到 Coldline，並在到期時刪除，以控制成本。

2. 透過專用的服務帳戶，為備份工作授予僅寫入的存取權限。
   • 指令：

undefined

• 理由：storage.objectCreator 角色可防止中繼資料被竄改和敏感備份被讀取，遵循了最小權限原則。

3. 使用簽署的 URL (signed URL) 與供應商分享一個敏感備份，有效期限為四小時，無需分發金鑰。
   • 指令：

undefined

• 理由：有時間限制、無身份的存取方式，避免了建立外部身份或長期有效的密鑰。模擬（Impersonation）使用由 KMS 支援的集中式簽署，消除了金鑰外洩的風險。

4. 為訂單資料庫啟用 Cloud SQL 備份和 PITR。
   • 指令：

undefined

• 理由：自動化備份加上二進位檔/WAL 日誌，可在保留視窗內提供精確到秒的還原點，以防止邏輯毀損和操作員失誤。

5. 透過還原到一個新的執行個體並在切換前驗證資料，來測試復原流程。
   • 指令：

undefined

undefined

• 理由：還原到一個獨立的執行個體可以避免影響生產環境，並允許在進行任何 DNS 或應用程式層級的切換前，透過校驗和與抽樣查詢進行驗證。

6. 透過空跑（dry run）來估算 BigQuery 查詢成本，並利用分割區進行優化。
   • 指令：

undefined

• 理由：空跑會顯示將被掃描的位元組數；確保 sale_date 是一個分割區欄位，並搭配有界限的述詞，可以減少掃描的位元組數，從而控制 on-demand 成本。

7. 監控與稽核存取。

   • 步驟：
     • 為 Cloud Storage 和 BigQuery 啟用資料存取日誌。
     • 針對 Cloud SQL 連線、磁碟用量和備份失敗設定 Cloud Monitoring 警報。
   • 理由：資料存取日誌提供物件層級的讀/寫可見性，以符合法規遵循要求。主動式警報可縮短 MTTR（平均修復時間），並確保備份和 PITR 持續有效。

8. 記錄故障模式與執行手冊（runbooks）。

   • 步驟：
     • 記錄物件版本還原、簽署 URL 撤銷、Cloud SQL PITR 以及使用時間旅行功能復原 BigQuery 資料表的程序。
   • 理由：清晰且經過測試的執行手冊可在事件發生時降低營運風險，並將安全復原實踐標準化於各團隊之間。

← VPC 網路、連線能力與流量管理 · 所有領域 · 部署、組態與自動化 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Google →