谷歌最近為其在 Google Cloud 上的分散式 SQL 資料庫 Spanner 引入 了分層儲存。這種分層儲存架構包含一種新的 HDD 儲存選項，比現有的 SSD 選項便宜 80%，可降低舊資料的儲存成本，同時儘可能減少與傳統資料遷移相關的開銷。
該架構中，預設的 SSD 層是為需要高吞吐量和低延遲的資料而設計的，新的 HDD 層則是為不經常訪問或對延遲不敏感的較大資料集而設計的。儲存分層 架構由策略驅動：作為維護任務的一部分，非同步後臺程序會根據使用者定義的策略自動將資料從 SSD 移動到 HDD。無論資料在哪個儲存層，SQL 查詢都可以訪問 SSD 和 HDD 層上的資料，並且備份策略在所有資料上一致應用。
谷歌團隊強調，對於大多數資料庫記錄而言，資料的運營價值會隨著時間的推移而降低，而其報告和合規性作用則會增強。這種轉變意味著舊的“冷”資料不需要像當前的“熱”事務資料那樣具有高效能訪問能力，從而鼓勵公司尋求更具成本效益的歷史資訊儲存解決方案。
來源：Google Cloud 部落格
谷歌軟體工程師 Matthew Muckloo 和谷歌集團產品經理 Piyush Mathur 寫道： 遷移到其他型別的儲存通常需要複雜的資料管道，並且會影響作業系統的效能。手動在儲存解決方案之間分離資料可能會導致讀取不一致，需要應用程式級的協調。此外，這種分離對應用程式查詢當前和歷史資料（例如響應監管機構）的操作施加了重大限制；它還增加了需要審計的治理接觸點。
現在使用者可以在各種 Spanner 級別（資料庫、表、列或二級索引）實施儲存分層策略，並可以靈活地將特定資料移動到速度較慢但成本較低的 HDD 儲存。例如，很少訪問的資料（如 JSON 產品屬性）可以移動到 HDD，而無需重構表，並且可以將索引保留在更快的 SSD 上，同時將實際資料儲存在 HDD 上。
要啟用分層儲存，必須建立一個定義儲存選項 [SSD（預設）/HDD] 的位置組，並可以選擇定義 ssd_to_hdd_spill_timespan 來指定在壓縮週期將資料移動到 HDD 之前應在 SSD 上保留資料的時間。例如：
CREATE LOCALITY GROUP recent_on_ssd OPTIONS (storage = 'ssd', ssd_to_hdd_spill_timespan = '15d');建立 SSD 到 HDD 溢位策略。在移動資料之前，資料必須在 SSD 中儲存至少 1 小時。
Google Spanner 不是唯一提供分層儲存的分散式雲資料庫。Amazon DynamoDB 隱藏了所使用的儲存技術，提供具有不同儲存和檢索費用的標準和標準 IA 儲存類別。
Spanner 的分層儲存支援 GoogleSQL 和 PostgreSQL 方言，並且在所有提供 Spanner 的 Google Cloud 區域中都可用。可以從 System Insights 監控 HDD 使用情況。
原文連結：
Google Cloud Introduces HDD Tier for Spanner Database, Cutting Cold Storage Costs by 80%(https://www.infoq.com/news/2025/03/google-spanner-tiered-storage/)
宣告：本文為 InfoQ 翻譯，未經許可禁止轉載。