[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-27。"],[],[],null,["# Tiered storage overview\n\n| **Note:** This feature is available with the Spanner Enterprise edition and Enterprise Plus edition. For more information, see the [Spanner editions overview](/spanner/docs/editions-overview).\n\n\u003cbr /\u003e\n\nThis page describes and explains how tiered storage works in Spanner.\nThis feature is supported in both GoogleSQL-dialect databases and PostgreSQL-dialect databases.\n\nSpanner tiered storage is a fully-managed storage feature that\nlets you choose whether to store your data on solid-state drives (SSD) or hard\ndisk drives (HDD). By default, when you're not using tiered storage, your data\nis stored on SSD storage. Depending on how often you use or access the data, you\nmight consider using tiered storage and storing data on both SSD and HDD\nstorage.\n\n- **SSD storage** is the most performant (higher queries per second) and cost-effective choice for most use cases. You should use it to store active data with high write and read throughput and data that requires low-latency data access.\n- **HDD storage** is sometimes appropriate for large datasets that aren't latency-sensitive, are infrequently accessed, or if the cost of storage is an important consideration.\n\nUsing tiered storage lets you take advantage of both SSD storage, which supports\nthe high performance of active data, and HDD storage, which supports infrequent\ndata access at a lower cost.\n\nChoose between SSD and HDD storage\n----------------------------------\n\nThe following table lists the differences and similarities between SSD and HDD\nstorage. When in doubt, we recommend that you choose SSD storage.\n\nUse [throughput optimized writes](/spanner/docs/throughput-optimized-writes) to\nincrease write throughput beyond the numbers in the table. For more information,\nsee [Performance overview](/spanner/docs/performance).\n\nBenefits\n--------\n\nTiered storage offers the following benefits by letting you use both SSD and HDD\nstorage:\n\n- **Significant total cost of ownership reduction**: HDD storage provides a lower cost option for large datasets that aren't latency-sensitive or are infrequently accessed.\n- **Ease of management**: Provides a fully-managed tiering service without the complexity of additional pipelines and split logic.\n- **Unified and consistent experience**: Provides unified data access and a single set of metrics across hot and (mutable) cold data\n- **Enhanced performance**: Improves query performance by organizing your data in different locality group, which provides data locality and isolation across columns. Data in the same locality group is stored physically close together.\n\nHow tiered storage works\n------------------------\n\nBy default, when you create a new instance, data is only stored on SSD storage.\nSimilarly, data in existing instances is also only stored on SSD storage.\n\nIf you choose to use tiered storage to store some data in HDD storage, you must\ncreate a [locality group](/spanner/docs/schema-and-data-model#locality-groups),\nwhich is used to define the tiered storage policy for data in your schema. When\nyou create a locality group, you can define the storage type, either `ssd` or\n`hdd`. Optionally, you can also define the amount of time that data is stored on\nSSD storage before it's moved to HDD storage. After the specified time passes,\nSpanner migrates the data to HDD storage during its normal\ncompaction cycle, which typically occurs over the course of seven days from the\nspecified time. This is known as an age-based tiered storage policy. When using\nan age-based tiered storage policy, the minimum amount of time that data must be\nstored on SSD before it's moved to HDD storage is one hour.\n\nWith your locality groups defined, when you create your tables, you can set the\ntiered storage policy at the database, table, column, or secondary index-level.\nThe tiered storage policy determines how and where data is stored. For\ninstructions, see [Create and manage locality groups](/spanner/docs/create-manage-locality-groups).\n\nBack up and restore\n-------------------\n\nYou can back up and restore your data using [Spanner backups](/spanner/docs/backup).\nThe backup contains all storage schema information, including\n[`INFORMATION_SCHEMA.LOCALITY_GROUP_OPTIONS`](#information-schema), which\nspecifies the storage type of each locality group. To restore a backup that\ncontains locality groups to a new instance, the destination instance must be in\nthe Spanner Enterprise edition or Spanner Enterprise Plus edition.\n\nData Boost\n----------\n\nYou can use [Spanner Data Boost](/spanner/docs/databoost/databoost-overview)\nto access data on SSD or HDD storage. Querying data on HDD uses the instance's\n[HDD disk load capacity](/monitoring/api/metrics_gcp_p_z#spanner/instance/disk_load),\nwhich is part of your compute capacity.\n\nSearch indexes\n--------------\n\n[Full-text search](/spanner/docs/full-text-search) and [vector indexes](/spanner/docs/find-approximate-nearest-neighbors#vector-index) inherit the locality group\nthat is set on the [database object](/spanner/docs/create-manage-locality-groups#set_a_database-level_locality_group).\n\nObservability\n-------------\n\nThe following observability features are available for tiered storage.\n\n### Cloud Monitoring metrics\n\nSpanner provides the following metrics to help you monitor your\ntiered storage usage and data using Cloud Monitoring:\n\n- `spanner.googleapis.com/instance/storage/used_bytes` (Total storage): Shows the total bytes of data stored on SSD and HDD storage.\n- `spanner.googleapis.com/instance/storage/combined/limit_bytes`: Shows the combined SSD and HDD storage limit.\n- `spanner.googleapis.com/instance/storage/combined/limit_bytes_per_processing_unit`: Shows the combined SSD and HDD storage limit for each processing unit.\n- `spanner.googleapis.com/instance/storage/combined/utilization`: Shows the combined SSD and HDD storage utilization, compared against the combined storage limit.\n- `spanner.googleapis.com/instance/disk_load`: Shows the HDD usage in percentage. If your instance reaches 100% HDD disk load, you experience significant increased latency.\n\nIf you have existing queries that filter existing metrics by\n`storage_class:ssd`, you must remove the filter to see your HDD usage.\n\nTo learn more about monitoring your Spanner resources, see\n[Monitor instances with system insights](/spanner/docs/monitoring-console) and\n[Monitor instances with Cloud Monitoring](/spanner/docs/monitoring-cloud).\n\n### Information schema\n\n`INFORMATION_SCHEMA.LOCALITY_GROUP_OPTIONS` contains the list of locality groups\nand options in your Spanner database. It includes information\nfor the `default` locality group. For more information, see\n[`locality_group_options` for GoogleSQL-dialect databases](/spanner/docs/information-schema)\nand [`locality_group_options` for PostgreSQL-dialect databases](/spanner/docs/information-schema-pg).\n\n### Built-in statistics tables\n\nThe following built-in statistics tables are available for databases using\ntiered storage:\n\n- `SPANNER_SYS.TABLE_SIZES_STATS_1HOUR`: Shows HDD and SSD storage usage for each table in your database.\n- `SPANNER_SYS.TABLE_SIZES_STATS_PER_LOCALITY_GROUP_1HOUR`: Shows HDD and SSD storage usage for each locality group in your database.\n\nFor more information, see [Table sizes statistics](/spanner/docs/introspection/table-sizes-statistics).\n\nThe query statistics and read statistics tables have the following column that\nis related to tiered storage:\n\n- `AVG_DISK_IO_COST`: The average cost of this query in terms of Spanner [HDD disk load](/monitoring/api/metrics_gcp_p_z#spanner/instance/disk_load). Use this value to make relative HDD I/O cost comparisons between reads that you run in the database. A higher value indicates that you are using more HDD disk load and your query might be slower than if it was running on SSD. Furthermore, if your HDD disk load is at capacity, the performance of your queries might be further impacted.\n\nFor more information, see [Query statistics](/spanner/docs/introspection/query-statistics)\nand [Read statistics](/spanner/docs/introspection/read-statistics).\n\nPricing\n-------\n\nThere is no additional charge for using tiered storage. You are charged the\nstandard Spanner pricing for the amount of compute capacity that\nyour instance uses and the amount of storage that your database uses. Data that\nis stored on SSD and HDD is billed at their respective storage rates. You aren't\ncharged for moving data between SSD and HDD storage. Querying data on HDD uses\nthe instance's [HDD disk load capacity](/monitoring/api/metrics_gcp_p_z#spanner/instance/disk_load),\nwhich is part of your compute capacity pricing. For more information, see\n[Spanner pricing](/spanner/pricing).\n\nWhat's next\n-----------\n\n- Learn more about [locality groups](/spanner/docs/schema-and-data-model#locality-groups).\n- Learn how to [create and manage locality groups](/spanner/docs/create-manage-locality-groups).\n- Learn more about [optimizing queries with timestamp predicate pushdown](/spanner/docs/sql-best-practices#optimize-timestamp-predicate-pushdown)."]]
