PCA 雲端架構師之旅 08 — GCP 儲存服務選擇

上一篇整理了資料大小、讀寫方式、一致性和延遲需求。這一篇拿那份需求表，對照 Cloud Storage、Cloud SQL、Spanner、Firestore、Bigtable 和 BigQuery。

有些服務看起來很像，差別卻在關鍵限制上。Cloud SQL 和 Spanner 都能做關聯式交易，Firestore 和 Bigtable 也都不是傳統關聯式資料庫；但它們的查詢方式、規模與維運成本並不一樣。

這是 PCA 雲端架構師之旅 的第八步。照著需求分支走，比先憑熟悉度選產品更可靠。

從需求縮小候選範圍

上一章整理了資料特性，現在才把它們拿來比較服務。先看幾個常見的需求組合：

• 全球交易若需要跨區一致性與擴展能力，Spanner 值得納入比較；還要確認資料模型和交易範圍。
• 大量時序資料若主要按 key 或 key range 查詢，可以評估 Bigtable；row key 設計會直接影響效果。
• 分析師要用 SQL 掃描半年訂單並做彙總，BigQuery 比線上交易資料庫更適合這類查詢。

要把這些需求翻成服務選擇，可以先排除三種常見誤判：

第一種是只因資料有關聯，就先選 Cloud SQL。若還要求跨區寫入或持續增加的吞吐，得先核對 Cloud SQL 能否滿足具體目標，而不是只看資料模型。

第二種是把 Firestore 和 Bigtable 都當成可互換的 NoSQL。Firestore 適合文件資料與應用程式查詢；Bigtable 更看重以 row key 組織的大規模低延遲讀寫。先列出查詢路徑，再比產品名稱有用。

第三種是把分析系統放進線上交易路徑。BigQuery 適合掃描、彙總與分析，不該只因為它能查 SQL，就讓使用者每次下單都等它回應。

例如把大型分析查詢直接打在處理交易的 Cloud SQL 上，就可能和線上請求搶資源。選資料庫時，先分清楚線上交易與分析查詢各需要什麼。

📝 考場提點

讀儲存題時，先記下資料形狀、查詢方式、吞吐量、一致性和保留期限。這些條件能幫你排除不合適的選項，但單一詞彙通常不足以決定服務；最後還要比較成本、區域與維運限制。

flowchart LR
  K[整理資料需求] --> F[檔案、圖片、備份]
  K --> A[分析、聚合、報表]
  K --> G[全球、強一致、關聯交易]
  K --> T[時序、超高寫入、key range]
  K --> M[行動 App、文件、即時同步]
  F --> O[物件儲存方向]
  A --> W[分析倉儲方向]
  G --> S[全球關聯資料庫方向]
  T --> B[寬欄 NoSQL 方向]
  M --> D[文件資料庫方向]

七種常見選項

下面這張表是比較起點，不是依名稱配對的答案表。先看每個服務通常處理什麼資料，再確認實際工作負載的限制。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

表格只能幫忙縮小範圍，接著還要逐項確認：

交易型還是分析型？ 下單、改個資、更新庫存需要線上讀寫；跨大量紀錄做聚合、報表和訓練資料準備，則偏向分析工作負載。同一份資料可能同時需要交易來源與分析讀模型，不必硬選一個系統兼做所有事。

哪些操作要跨區？ 使用者分布全球，不代表每筆交易都得跨區寫入。先確認讀取延遲、寫入位置、故障復原目標與一致性要求，再比較區域型資料庫和分散式資料庫。

資料是紀錄還是檔案？ 需要按欄位查詢的紀錄和圖片、影片、備份等物件，存取方式不同；先分開評估，再決定是否要建立關聯。

查詢長什麼樣？ Firestore 的文件查詢與 Bigtable 的 row-key 範圍讀取不是同一套模型。先列出主要查詢和尖峰寫入量，再確認索引或 key 設計能否支援。

一個需求進來，怎麼逐步縮小範圍？

可以先用下面幾個問題抓方向，但別停在第一個符合的產品；每一步都要回頭檢查題目的硬性要求。

先看它是檔案還是需要查詢的紀錄。圖片、影片、備份通常先評估物件儲存；要依欄位查詢或更新狀態的紀錄則繼續往下看。

接著問它主要用於交易還是分析。大量掃描、聚合與報表可以評估 BigQuery；若同一份資料還要支援線上交易，則保留合適的交易來源，再規劃同步方式。

確定是交易型之後，問是否真的需要跨區寫入和一致性。若需要，再比較 Spanner 等方案與成本；若只要求跨區備援，候選不必因此直接縮成一個。

再看資料關係與查詢模式。需要 JOIN、外鍵或複雜交易，可以從關聯式資料庫比較起；若主要按文件或 key 讀取，再看相應的 NoSQL 模型。

若主要做大量時序寫入或 key-range 查詢，可以評估 Bigtable；若需要文件查詢與應用程式同步，則比較 Firestore。兩者都還要核算索引、叢集與讀寫成本。

另外別漏了舊資料和VM 磁碟。匯出的檔案與備份可以按保存時間和讀取頻率比較 Cloud Storage 儲存級別；VM 要掛載的區塊儲存則另看 Persistent Disk 或 Hyperdisk。這些不是同一種選型問題。

📝 考場提點

先問資料是檔案還是要查詢的結構化紀錄，通常就能縮小選項。例如使用者上傳的影片，先考慮物件儲存，不必一開始就在各種資料庫之間比較。確認大方向後，再看規模、延遲與一致性。

flowchart TB
  D[資料需求] --> F{是檔案或物件？}
  F -- 是 --> G[Cloud Storage]
  F -- 否 --> A{主要做分析聚合？}
  A -- 是 --> Q[BigQuery]
  A -- 否 --> X{跨 region 關聯交易<br/>且要求強一致？}
  X -- 是 --> S[Spanner]
  X -- 否 --> R{需要關聯、JOIN 與交易？}
  R -- 是 --> C[Cloud SQL]
  R -- 否 --> T{超高寫入的時序<br/>或 key-range 存取？}
  T -- 是 --> B[Bigtable]
  T -- 否 --> E[Firestore]

走一遍範例 — 登雲書店

以登雲書店為例，會員、訂單、圖片、瀏覽紀錄和報表各有不同的查詢需求。先提出一組候選，再看哪些地方還需要驗證：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Coldline 有 90 天最短儲存時間，提前移除仍可能產生費用；舊圖是否轉入這一級，應按實際留存與讀取情況試算。（參考：Cloud Storage 儲存級別）

表格裡有兩個容易混淆的選擇。

第一個，會員與訂單資料為什麼選關聯式資料庫。登雲書店需要一起查詢訂單、商品、用戶與物流資料。這類跨表關聯和交易，用關聯式模型比較直觀；Firestore 適合文件資料，但 Standard edition 不能直接用跨文件 JOIN 處理相同查詢，要用 Enterprise edition 的 Pipeline operations 才能以子查詢做 JOIN。選型要從資料關係與查詢方式出發，而不是從「SQL」或「NoSQL」的標籤出發。

第二個，瀏覽紀錄為什麼分開處理寫入與分析。若線上服務需要按使用者或時間範圍快速讀取大量事件，可以評估用 Bigtable 承接寫入與查詢，再把資料匯入 BigQuery 做跨月彙整。若只是把事件送去分析，則不必為了「串流」兩個字就加一層 Bigtable；應按實際讀取需求、延遲與費用選擇管線。

這個案例暫時沒有選 Spanner，因為登雲書店目前只在台灣營運，資料量和交易需求仍可先用 Cloud SQL 承接。如果日後需要跨區域寫入、更高的水平擴展能力，或現有資料庫已碰到容量與可用性限制，再重新比較 Spanner 的價值與成本。後面的成本章節會再用數字檢查這個選擇。

flowchart TB
  C[目前使用 Cloud SQL] --> S{單一 region 的容量<br/>與可用性仍能達標？}
  S -- 是 --> K[保留 Cloud SQL<br/>持續監控與擴展]
  S -- 否 --> G{需要跨 region 寫入<br/>與全球強一致？}
  G -- 否 --> O[先做索引、<br/>讀副本、分片<br/>或垂直擴展]
  G -- 是 --> M{業務價值能承擔<br/>遷移與持續成本？}
  M -- 否 --> R[重新協商需求<br/>或資料邊界]
  M -- 是 --> P[規劃 Spanner schema<br/>容量與遷移驗證]

幾個容易選錯的地方

下面幾個選擇在架構圖上看起來可行，但套回資料存取方式和成本後，就會發現不太合適。

在需求還不明確時就選 Spanner。 如果案例沒有跨區域寫入、水平擴展或相關一致性需求，先比較 Cloud SQL 是否已經足夠。Spanner 的能力有價值，但也帶來不同的成本與設計工作；不要把未提到的需求自行加進架構裡。

拿 BigQuery 當即時交易後端。 BigQuery 的強項是掃描與聚合大量資料，不適合讓每筆下單或庫存扣減都等它完成交易更新。這類操作要先確認交易語意與延遲目標，再選線上資料庫。

以為 Persistent Disk 跟 Cloud Storage 可以互換。 Persistent Disk 是掛在 VM 上的區塊磁碟；Cloud Storage 是透過 API 存取的物件儲存，可搭配生命週期規則與 CDN。若上傳檔案全放在單台 VM 的磁碟上，之後要讓多台機器共用或向外分發，就得另外處理同步與擴充問題。

flowchart TB
  S[候選儲存方案] --> Q1{BigQuery 被拿來接<br/>線上交易更新？}
  Q1 -- 是 --> X[淘汰：OLAP<br/>不是 OLTP]
  Q1 -- 否 --> Q2{沒有全球一致需求<br/>卻直接上 Spanner？}
  Q2 -- 是 --> X2[淘汰：成本過度設計]
  Q2 -- 否 --> Q3{使用者檔案放在<br/>VM 掛載磁碟？}
  Q3 -- 是 --> X3[改用 Cloud<br/>Storage]
  Q3 -- 否 --> Q4{多種工作負載<br/>全塞同一資料庫？}
  Q4 -- 是 --> X4[拆出交易、<br/>分析與物件路徑]
  Q4 -- 否 --> V[進入容量<br/>與成本驗證]

延伸閱讀

• Google Cloud 儲存服務總覽
• Cloud Storage 儲存類別
• 選擇 GCP 資料庫服務
• Spanner 產品頁

下一步：資料各就各位之後，下一篇要處理怎麼把流量穩穩送進來——網路與 Load Balancing。

系列導航

• 系列首頁：PCA 雲端架構師之旅
• 上一篇：PCA 雲端架構師之旅 07 — 儲存特性分析
• 下一篇：PCA 雲端架構師之旅 09 — 網路與 Load Balancing

🎯 換你練習

理論讀完，換自己來。到 架構師設計工作坊 · 步驟 8 填入你的 case study，邊寫邊內化。