GoogleCloud为Spanner数据库引入HDD层，将冷存储成本降低80%

谷歌最近为其在 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 使用情况。