存儲與數據庫選擇策略

存儲連續體：為您的數據選擇正確的家

在 GCP PCA 考試中，存儲與數據庫的選擇是風險最高的領域之一。選擇錯誤的存儲類型可能導致性能瓶頸、數據損壞（由於一致性問題）或巨大的成本超支。

• 物件存儲 (Object Storage)： Cloud Storage。適用於非結構化數據（影像、備份、日誌）。
• 關聯式 (SQL)： Cloud SQL（區域性）和 Cloud Spanner（全域 / 可擴展）。
• NoSQL： Bigtable（高吞吐量時間序列）和 Firestore（基於文件的行動 / 網頁應用）。
• 區塊存儲 (Block Storage)： 永久磁碟 (Persistent Disk，適用於 VM)。
• 文件存儲 (File Storage)： Filestore (NFS)。

「最優」選擇取決於數據的 容量 (Volume)、速度 (Velocity)、多樣性 (Variety) 和 一致性 (Consistency) 要求。

白話文解釋 存儲與數據庫選擇

選擇存儲服務就像在生活中選擇如何存放物品。

類比 1 — 無限的紙箱 (Cloud Storage)

Cloud Storage 就像是巨大倉庫中供應無限的紙箱。您可以把任何東西扔進去——一張照片、一份長文件、硬碟備份。您不需要為了讓倉庫存放它而組織紙箱 內部 的東西。它便宜、巨大，非常適合那些您不需要經常搜尋的東西。

類比 2 — 銀行的帳本 (Cloud SQL & Spanner)

關聯式數據庫就像是銀行的帳本。每條條目必須遵循嚴格的格式（Schema），且數學計算必須始終正確（ACID 合規）。

• Cloud SQL 就像是當地的銀行分行。它對您的城鎮運作良好，但如果全世界數百萬人同時嘗試進入該分行，它就會變得擁擠且緩慢。
• Cloud Spanner 就像是神奇的全域銀行帳本，它會在世界各地同時更新。雖然運行成本較高，但它是安全處理全球交易的唯一方式。

類比 3 — 高速電報帶 (Bigtable)

Bigtable 就像是華爾街的電報帶。它旨在每一秒鐘記錄數百萬條微小的資訊（如股價或感應器讀數）。它不在乎複雜的關係，它只在乎速度與容量。當您需要像消防水龍頭噴水一樣快地寫入數據時，您會使用它。

深度解析：Cloud Storage (物件)

• Standard (標準)： 頻繁存取的數據。
• Nearline： 每月存取少於 1 次（如月度報告）。
• Coldline： 每季存取少於 1 次（如法律檔案）。
• Archive (封存)： 每年存取少於 1 次（如保存 10 年的數據）。
• 生命週期管理： 根據時間自動將數據移至更便宜的層級或刪除。

Cloud Storage 級別決策樹

選錯 Cloud Storage 級別是 PCA 考試最常見、也最容易讓帳單暴衝的錯誤之一。四個級別（STANDARD、NEARLINE、COLDLINE、ARCHIVE）在「儲存成本」與「取回成本、最短儲存期、提前刪除費用」之間做取捨。價格大致呈反向曲線：Archive 的儲存成本約是 Standard 的 1/17，但每 GB 取回費用較高；若在最短期限內刪除物件，會以滿期計費。

依存取頻率決策

• 每月多次、低延遲（網頁、CDN 原點、熱資料分析）： STANDARD。無最短儲存期、取回最便宜，可搭配 Cloud CDN 或 Media CDN 降低出口流量費用。
• 約每月存取一次（月報、近 30 天備份）： NEARLINE。最短儲存期 30 天。
• 每季存取一次（DR 副本、合規讀取）： COLDLINE。最短儲存期 90 天。
• 罕用、受規範約束的長尾資料（10 年稽核日誌、原始實驗資料）： ARCHIVE。最短儲存期 365 天。首位元組延遲仍是毫秒等級，並 不是 磁帶。

位置類型（與級別正交）

• Region（區域，例如 asia-east1）： 最便宜、單一區域耐用性（11 個 9），與同區運算資源延遲最低。
• Dual-region（雙區域，例如 asia1 或自訂預設配對）： 同步地理冗餘，可選擇 Turbo replication 達到 ≤15 分鐘 RPO。
• Multi-region（多區域，例如 US、EU、ASIA）： 跨整個洲的地理冗餘，最適合全域讀取分流。

自動化層級搬移

使用 Object Lifecycle Management 規則（JSON）每日評估一次：

{ "lifecycle": { "rule": [
  { "action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
    "condition": {"age": 30, "matchesStorageClass": ["STANDARD"]} },
  { "action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
    "condition": {"age": 90} },
  { "action": {"type": "SetStorageClass", "storageClass": "ARCHIVE"},
    "condition": {"age": 365} },
  { "action": {"type": "Delete"}, "condition": {"age": 2555} }
]}}

當存取模式難以預測時，請改用 Autoclass——它會根據實際觀察到的存取行為自動在各級別之間搬移物件，免去手動建模規則的負擔。參考：https://cloud.google.com/storage/docs/lifecycle

深度解析：關聯式數據庫 (SQL)

• Cloud SQL： 代管的 MySQL、PostgreSQL 和 SQL Server。最適合標準網頁應用和區域性工作負載。支持具備故障轉移副本的高可用性 (HA)。
• Cloud Spanner： 全球首個「NewSQL」數據庫。它結合了 NoSQL 的擴展性與 SQL 的 ACID 合規性。它是全域庫存或財務系統的「最優」選擇。

深度解析：NoSQL 數據庫

• Bigtable： 寬管柱存儲 (Wide-column store)。用於高吞吐量的 IoT、廣告技術 (AdTech) 或金融遙測。它是 Google 搜尋和 Gmail 的骨幹。
• Firestore： 文件數據庫。最適合行動 / 網頁應用後端、用戶資料和即時同步。它能自動擴展至數百萬用戶。

區塊與文件存儲

• 永久磁碟 (PD)： 掛載到 Compute Engine 或 GKE。
  • Balanced (均衡)： 最適合一般用途。
  • SSD： 最適合高性能數據庫。
  • Extreme： 適用於要求最嚴苛的 I/O。
• Filestore： 為需要共享文件系統的應用程式（如舊有媒體編輯工具）提供代管的 NFS。

Persistent Disk 與 Hyperdisk：挑選正確的區塊存儲

GCP 的區塊存儲產品線已遠遠超出傳統 Persistent Disk。Hyperdisk 將容量與 IOPS、吞吐量解耦，可獨立調整——這是相對 PD（效能隨容量線性成長）的重大架構轉變。

經典 Persistent Disk (PD)

• pd-standard（HDD）： 最便宜，順序吞吐量為主，適合冷啟動碟與日誌封存。
• pd-balanced（SSD）： 預設選擇——SSD 等級延遲，價格低於 pd-ssd。適用大多數應用伺服器與中階資料庫。
• pd-ssd： 延遲更低、IOPS-per-GB 上限高於 pd-balanced。約 30 TB 以下的 OLTP 資料庫（自管 Postgres、MySQL）甜蜜點。
• pd-extreme： 可自訂 IOPS 上限至每碟 120,000。適合單碟最大型工作負載（SAP HANA、大型 MS SQL、需要持久化的記憶體快取）。

Hyperdisk 家族（次世代）

• Hyperdisk Balanced： pd-balanced 的後繼者。可獨立調整 IOPS / 吞吐量。在 C3、N4、H3 機器系列上是新的預設。
• Hyperdisk Extreme： 單碟最高 350,000 IOPS、5,000 MB/s。在支援的機器系列上取代 pd-extreme。適合 tier-0 OLTP 與 SAP HANA。
• Hyperdisk Throughput： 針對順序掃描最佳化（具成本效益地處理日誌攝取、Hadoop scratch、Kafka 分層儲存）。單碟最高 600 MB/s，價格落在 HDD 等級。
• Hyperdisk ML： 唯讀為主、可被多達 2,500 顆 GPU / TPU VM 同時掛載。為 ML 訓練資料集與服務模型權重設計，提供巨大的聚合讀取吞吐量。

快速選擇

參考：https://cloud.google.com/compute/docs/disks

Filestore 級別：挑選代管 NFS

Filestore 是 GCP 的代管 NFSv3 服務。級別選擇同時決定效能上限與最小容量：

• Basic HDD： 1 TiB – 63.9 TiB。低成本，適合開發 / 測試的家目錄、內容管理、小型 CMS 部署。
• Basic SSD： 2.5 TiB – 63.9 TiB。SSD 等級延遲，適合需要共享檔案存取的一般用途工作負載（透過 Filestore CSI driver 提供 GKE 共享 Volume、舊有 NFS 應用）。
• Zonal（前身為 High Scale）： 10 TiB – 100 TiB。更高的 IOPS 與吞吐量擴展，支援備份。適合 HPC scratch 空間與渲染農場。
• Enterprise： 1 TiB – 10 TiB。區域級（跨可用區）高可用，採同步複寫——是唯一具備區域級 SLA 的層級。需要在可用區故障時仍存活的共享檔案系統（如 SAP 共享 Volume、EDA）必選此層。

若工作負載需要 PB 級的 POSIX 語意（HPC、生命科學流程），請改用 Parallelstore（相容 Lustre），而非 Filestore。

關聯式與 NoSQL 選擇：Cloud SQL vs Spanner vs Firestore vs Bigtable

四個旗艦資料庫解決不同問題。先把工作負載形狀對到正確的服務，再考慮其他細節。

Cloud SQL

• 代管 MySQL、PostgreSQL、SQL Server。
• 區域級，垂直擴展（單實例最大約 128 vCPU / 864 GB），HA 透過另一個可用區的同步備援節點實現。
• 讀取擴展：最多 10 個讀取副本（允許跨區域）。
• 適用：傳統網頁應用後端、WordPress、GitLab、數 TB 以內的區域 OLTP。

Cloud Spanner

• 水平擴展、全球分散式、外部一致性（TrueTime）。
• 跨區域強一致性、ACID 交易、SQL 介面（GoogleSQL 或 PostgreSQL 方言）。
• 細粒度計費：Processing Units（100 PU = 1/10 個節點）讓小規模也能落地（入門約每月 65 美元）。
• 適用：全域庫存、財務帳本、讀寫遍佈全球的多區域 SaaS。

Firestore（Native Mode）

• 無伺服器文件資料庫，自動多區域複寫。
• 單一文件強一致，預設跨查詢最終一致；ACID 交易最多可涵蓋 500 個文件。
• 即時監聽（onSnapshot）將變更主動推播給 Client——對行動 / 網頁同步是殺手級功能。
• 適用：行動 / 網頁應用後端、用戶資料、聊天、協同編輯狀態。

Bigtable

• 寬管柱 NoSQL（相容 HBase API），可在數百萬 QPS 下達到個位毫秒讀取。
• 無 SQL、無次要索引（除了 row key 之外）——schema 設計就是 row key 設計。
• 適用：時間序列（IoT、金融 tick 資料）、AdTech 用戶 Profile、餵給 Looker 或 Data Studio 的大型維運分析服務層。

快速選擇表

參考：https://cloud.google.com/architecture/database-design-guidelines

AlloyDB for PostgreSQL 工作負載

AlloyDB for PostgreSQL 是 GCP 為超出 Cloud SQL 規模、但又不需要 Spanner 全球寫入的企業級 Postgres 工作負載量身打造的代管資料庫。它是 Google 對 Amazon Aurora 以及 SQL Server 級別 Postgres 工作負載的回應。

架構亮點

• 運算與儲存解耦： 採用 log-structured 儲存層，在區域內三重冗餘寫入日誌。新增讀取副本不會複製整份資料集——相對 Cloud SQL 讀取副本是巨大的成本優勢。
• 欄式加速器： 內建欄式記憶體引擎與列式儲存並存，會自動選擇要常駐記憶體的熱欄位，在同一個正式資料庫上加速分析查詢（HTAP）。Cloud SQL 並沒有對應功能。
• Read Pool Nodes： 最多 20 個讀取副本，亞秒級延遲。
• pgvector 與 AlloyDB AI： 內建向量搜尋、透過 google_ml 管理模型端點以產生 embedding。可在不另起向量資料庫的情況下，於維運資料上進行 RAG。

何時選 AlloyDB 而非 Cloud SQL

• 單一主節點上 Postgres 工作負載 > 10 TB 或 > 64 vCPU。
• 同一份資料集上混合 OLTP 與分析查詢（HTAP）——否則就得另外建 Postgres + BigQuery 管線。
• 需要快速擴展讀取、且複寫成本低。
• 需要把向量搜尋與交易資料放在一起。

何時不要選 AlloyDB

• MySQL 或 SQL Server 工作負載（AlloyDB 只支援 Postgres——請改用 Cloud SQL）。
• 需要多區域 Active-Active 寫入（請用 Spanner，可選 PostgreSQL 方言）。
• 小型工作負載，Cloud SQL Postgres 每月 < 50 美元就夠用。

參考：https://cloud.google.com/alloydb/docs/overview

Memorystore for Redis 與 Valkey

Memorystore 是 GCP 的代管記憶體快取服務。到了 2026 年，它支援三種引擎，而在 Redis 重新授權後，引擎選擇比以往任何時候都更重要。

引擎

• Memorystore for Redis： 原始產品，完全代管的 Redis（最新支援版本依 Release Notes 為準）。提供 Redis Cluster 模式與單機 HA 層級。適用：相容現有 Redis 生態系。
• Memorystore for Valkey： Redis 7.2 的開源分支，由 Linux Foundation 維護。Wire 層與 Redis Client 相容。GCP 新增 Valkey 是為了在 Redis Inc. 變更授權後，給客戶一個長期可用、OSI 授權的選項。適用：希望採 BSD 授權引擎的新建系統、每實例成本更低。
• Memorystore for Memcached： 純多層快取，無持久化、無複寫。適用：Session Store、讀取密集網頁應用的 cache-aside。

層級選擇（Redis / Valkey）

• Basic Tier： 單節點、無副本。便宜、無 HA，僅供開發 / 測試。
• Standard Tier： 主節點 + 副本，自動故障轉移、區域級。最多可選 5 個讀取副本。
• Cluster mode： 跨多個分片切分（最多 250 個 shard），容量 > 300 GB 或 > 100,000 ops/sec 時必選。

常見 PCA 模式

• 無狀態 Cloud Run / GKE 服務的 Session 快取 → Memorystore for Redis（Standard）。
• 排行榜 / 速率限制 → 透過 Memorystore 的 Redis sorted sets。
• Cloud SQL 熱列的 sidecar 快取 → Memorystore for Redis，於應用層採 read-through 模式。

非同步佇列（相對於快取）請優先使用 Pub/Sub 或 Cloud Tasks，不要把 Message Queue 語意硬塞進 Redis。

參考：https://cloud.google.com/memorystore/docs

BigQuery vs Cloud Storage 資料湖模式

PCA 情境常把「以 BigQuery 為中心的資料倉儲」與「基於 Cloud Storage 的資料湖」放在一起比較。最優解取決於存取模式、Schema 穩定度、以及下游工具鏈。

模式 1 — BigQuery 為主存儲

• 資料透過 Storage Write API、Datastream（CDC）或 Dataflow 進入 BigQuery。
• 資料表依（攝取時間或 DATE 欄位）分區，並對高基數過濾欄位做 Clustering。
• 儲存由 BigQuery 自管（欄式 Capacitor 格式），儲存與運算（slots）分開計費。
• 適用：以 SQL 為主的分析團隊、BI 儀表板、Schema 穩定的場景。

模式 2 — Cloud Storage 資料湖 + BigQuery External Tables

• 原始資料以 Parquet、ORC、Avro、JSONL 落入 gs:// Bucket，並依日期前綴分區。
• BigQuery 透過 BigLake tables 查詢——這是一種外部表，支援細粒度 IAM、列 / 欄級安全控制、以及 metadata 快取。
• 同一份檔案可被 Dataproc（Spark）、Dataflow、Vertex AI 訓練任務直接讀取，免去複製。
• 適用：多引擎存取、ML 訓練資料集、Schema-on-read 工作流、需要把極冷資料以低成本留在 Cloud Storage。

模式 3 — 以 Iceberg 構建的開放 Lakehouse

• Cloud Storage 存放 Apache Iceberg 資料表；BigQuery 透過 BigLake managed tables for Apache Iceberg 讀寫。
• 在 Cloud Storage 資料湖上獲得 ACID 交易、Time Travel、Schema 演進，並由 BigQuery 的 SQL 引擎在上層查詢。
• 適用：希望標準化採用開放表格式、同時保留 BigQuery 作為查詢引擎的組織。

決策捷思

• Schema 穩定、查詢純 SQL → BigQuery 自管儲存。
• 需要便宜的原始保留 + ML 訓練 + SQL → Cloud Storage + BigLake。
• 想要開放表格式、多引擎、且在資料湖上保有 ACID → BigLake Iceberg。

參考：https://cloud.google.com/bigquery/docs/biglake-intro

存儲資源最優解 (Optimal) vs. 可行解 (Viable) 決策摘要

FAQ — 存儲選擇策略

Q1. 什麼時候應該選擇 BigQuery 而非 Bigtable？

將 Bigtable 用於即時、低延遲的 維運 數據（服務於 App）。將 BigQuery 用於 分析 數據（對數 PB 的歷史記錄執行長時間報告和 SQL 查詢）。

Q2. Cloud Spanner 的成本值得嗎？

如果您的業務依賴於全域數據完整性（不重疊銷售、不出現錯誤餘額），那麼是的。Spanner 實例的成本遠低於發生重大數據損壞事件的商業成本。

Q3. Cloud SQL 可以全域擴展嗎？

Cloud SQL 可以擁有 跨區域讀取副本，但寫入必須進入主區域。這使其具備「全域可讀性」，但不像 Spanner 那樣具備「全域可寫性」。

Q4. 什麼是「多區域 (Multi-regional)」Cloud Storage？

它將您的數據存儲在至少兩個相距至少 100 英里的地理位置。這確保了即使整個區域（如 us-east1）被摧毀，您的數據在另一個區域仍然安全。

Q5. Firestore 的限制是什麼？

Firestore 對於文件大小的數據具有驚人的擴展性。然而，對於海量、高速的時間序列數據，Bigtable 由於其寬管柱結構和更低的單次寫入成本而更為「最優」。

最終架構師提示

「架構 vs. 速度」。如果您的數據具有嚴格的架構且需要事務支持，請選 SQL (Cloud SQL/Spanner)。如果您的數據雜亂、海量且需要快速寫入，請選 NoSQL (Bigtable/Firestore)。如果您需要存儲 10GB 的文件，請選 物件 (Cloud Storage)。記住這個決策樹，PCA 考試將變得輕而易舉。