GCP 資料該放哪？從存取方式選儲存服務

一個購物網站就有好幾種「資料」：商品照片、訂單、使用者設定，還有每次點擊產生的事件。把它們全塞進同一套資料庫，剛開始或許能跑，日後卻容易在費用、查詢或備份上卡住。

選服務時，我會先問「應用平常怎麼讀寫這份資料」，再問容量有多大。要存檔案、查一筆訂單、同步手機畫面，和掃過一年交易做報表，是不同工作；就算都叫儲存，也不該只比每 GB 價格。

先把工作分開，再挑服務

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

這張表只是起點，不是「看到關鍵字就選服務」的答案卡。例如照片的二進位內容可放 Cloud Storage，但照片屬於哪個商品、誰能看，可能仍要由應用資料庫管理。BigQuery 也能用 SQL，卻不等於拿它直接取代每秒更新訂單狀態的資料庫。Compute Engine 磁碟選型同樣提醒：Local SSD 是暫存型儲存，不適合當唯一資料副本。

Cloud Storage：冷資料便宜，讀回來也要算錢

先拿「每筆訂單產生一份 PDF，近期會下載，之後只偶爾稽核」當例子。它是檔案，不需要用資料庫一欄一欄更新，放 Cloud Storage 比較順手。接著才要決定儲存類別。

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

Archive 不是「叫客服等幾小時才拿得到」的離線磁帶；物件仍可線上讀取，但取回、操作與提前刪除的費用要算進去。若檔案常被覆寫，或半年內就可能刪除，單看 Archive 的儲存單價會算錯。官方類別說明另列有 Rapid，供 Rapid Bucket 的特定工作負載使用；它不是上表四類的通用替代品。

假設訂單 PDF 在前三個月常被下載，一年後幾乎只為稽核保留，可以先查實際存取紀錄，再用生命週期規則讓物件依條件轉到較冷的類別。別先寫死「30 天轉 Nearline、90 天轉 Coldline」就宣布省了多少：操作次數、取回量、最短儲存期和保留政策都會改變結果。規則若還會刪除物件，務必先確認法規與業務保留期限。

如果你不想自己猜轉換時間，也能評估 Autoclass，讓服務按存取模式調整類別。它有自己的計費和限制，而且不能在同一個 bucket 同時使用 SetStorageClass 生命週期規則；不是把兩個「自動省錢」選項一起勾就會更省。

Cloud SQL：HA、讀取副本和備份是三件事

訂單和付款狀態需要關聯查詢與交易。如果現有應用用 MySQL、PostgreSQL 或 SQL Server，Cloud SQL通常是先評估的代管方案。它省下部分資料庫維運工作，但還是要規劃查詢、容量、連線與復原。

遇到「資料庫不能停」的需求，先問清楚對方是怕哪一種事：

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

以 Cloud SQL for MySQL 的 HA 文件為例，主要與待命執行個體位於同一區域的不同 Zone，已提交的寫入會同步複製到兩邊磁碟。故障切換時，應用仍可能短暫斷線，需要重連及安全地重試交易。這是「區域內某個 Zone 出事」的保護，不應直接推論成跨區災難也一定零資料遺失。

跨區讀取副本可以幫忙做災難復原，但複寫有延遲，提升副本時可能少了最後幾筆交易。這也是為什麼復原計畫要寫明 RPO（最多能容忍遺失多少資料）與 RTO（最多能停多久），並在演練中量測，而不是把「有副本」當成已完成備援。備份與還原也要定期試：能建立備份，和真的能把應用救回來，不是同一件事。

Firestore、Bigtable、Spanner：不要用「NoSQL」一個詞打包

假設要做手機 App 的購物清單，使用者希望另一台裝置立刻看到更新，離線時也能讀到先前資料。這時可以評估 Firestore 的文件模型與用戶端能力。但它不是「沒有交易或一致性」的代名詞：Firestore 支援強一致查詢和跨文件交易；離線能力也有平台與操作限制。設計時仍要看索引、讀寫次數和資料權限。

如果每天有大量感測器事件，應用通常依「哪台設備、哪段時間」讀取，Bigtable的 row key 模型值得評估。設計 row key 時要兼顧查詢範圍和寫入分布；只把時間戳排在最前面，可能讓新資料集中寫到相鄰的 key。Bigtable 不提供關聯式 JOIN，交易範圍也和一般 SQL 資料庫不同，不能因為資料量大就把原本的訂單表直接搬過去。

若需要在很大規模下維持關聯式交易，可以看 Spanner。它不只用於「全球金融系統」，也有區域配置；是否值得採用，取決於交易、擴展、可用性需求和改造成本。想做大量跨資料集的報表時，則另外評估 BigQuery 這條分析路徑，不要讓線上交易資料庫一肩扛完所有分析查詢。

三者放在一起看，差別會清楚一點：

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

Bigtable 加上複寫能提高可用性，但寫進一個叢集的資料要等複寫完成，才能從另一個叢集讀到。題目要的是「跨區仍強一致的交易」時，別把它和 Spanner 當成同一種能力。

算成本時，先拿自己的工作負載做小測試

原始儲存量只是帳單的一欄。Cloud Storage 還有操作、取回、網路與保留期限；Cloud SQL 有執行個體、儲存、HA、備份與副本；Firestore 看讀寫和儲存；Bigtable 看叢集與複寫；Spanner 則要把版本、處理容量和配置一起估。Cloud Storage 定價頁就能看出為什麼「便宜的冷儲存」不一定讓整體費用較低。

我會挑一份有代表性的資料，先記錄一週的讀寫量與延遲，再試一項改動。例如只把一批舊 PDF 移到 Nearline，觀察下個月的儲存、取回與操作費；或先修一條慢查詢，再決定 Cloud SQL 是否真的需要升規格。這樣比套用別人寫的「省 70%」更可靠。

上線前，再找產品和維運團隊一起確認三件事：資料要保留多久、哪種故障必須扛住、要在多久內還原。若答案還不清楚，就先不要自動刪資料或承諾某個 RPO／RTO。

ACE 題目怎麼判斷

• 大量感測器時序資料，要低延遲讀寫？ 先看 Bigtable，再用 row key 設計確認；BigQuery 是分析路徑，不接這條線上讀寫。
• 跨區的關聯式交易，要強一致又要 SQL？ 先看 Spanner。Cloud SQL 的跨區讀取副本複寫有延遲，不是同一種能力。
• 現有 MySQL 想搬上雲、改動越少越好？ 先看 Cloud SQL for MySQL，再盤點版本與相容性。
• 物件過一段時間就很少讀，想省儲存費？ 用生命週期規則轉到較冷的類別，並把取回費與最短儲存期限算進去。

準備 ACE 時，先能解釋資料怎麼被讀寫，再說出為何選這個服務。想往下讀，GCP-107：Cloud Storage 入門、Google Cloud 資料庫怎麼選和 ACE-213：Cloud Spanner各有細節；下一篇 ACE-202：高可用架構會接著談服務不中斷的設計。