[[["易于理解","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-09-05。"],[],[],null,["# Storage utilization metrics\n\nThis page describes the storage utilization metrics that Spanner\nprovides.\n\nBy default, your data is stored on solid-state drives (SSD) storage. You can\nchoose whether to store your data on SSD or hard disk drives (HDD) by using\ntiered storage. For more information, see [Tiered storage overview](/spanner/docs/tiered-storage).\n\nStorage metrics\n---------------\n\nSpanner provides the following storage metrics:\n\n- **Total database storage** : The amount of data that is stored in the database or the databases in the instance. This is subject to the [storage\n limit](/spanner/quotas#database_limits).\n- **Total backup storage**: The amount of data that is stored by the backups associated with the instance or database. Backup storage is stored and billed separately and there is no limit on the amount you can store.\n\nYou can view charts for these metrics\n[in the Google Cloud console](/spanner/docs/monitoring-console) or [in the\nCloud Monitoring console](/spanner/docs/monitoring-cloud).\n\nAlso, database storage utilization is shown in the **Instances** and\n**Instance details** pages in the Cloud console.\n\n[Go to the instances\npage](https://console.cloud.google.com/spanner/instances)\n\n### Multi-version storage\n\nIf you use the above storage metrics to check the size of your data frequently,\nyou might occasionally encounter results contrary to your expectations. For\nexample, you might see the reported total storage of your database decrease by a\nnoticeable amount, even though you hadn't recently removed any data. Conversely,\nyou might see its size remain relatively unchanged right after performing a\nsignificant deletion.\n\nThese effects stem from Spanner's support for *multi-version storage* .\nMulti-version storage keeps all deleted or overwritten data in-storage and\navailable for a limited time to enable features that let you read previous data\nvalues, such as [stale reads](/spanner/docs/reads#read_types) and [point-in-time recovery](/spanner/docs/pitr).\nPerforming a large data deletion doesn't immediately get reflected in your\ndatabase's storage metrics. Similarly, an apparently unprompted drop in a\ndatabase's total size likely means that Spanner's regular\ndata-compaction process recently cleaned up a large set of data that was deleted\nor overwritten as far back as several days ago.\n\nSpanner guarantees the\ncontinued availability of deleted or overwritten\ndata for the interval defined by the\n[`version_retention_period`](/spanner/docs/reference/rest/v1/projects.instances.databases#Database.FIELDS.version_retention_period) option (one hour, by\ndefault). It automatically runs a background process every several days that\npermanently removes all obsolete data older than this version-retention\ninterval.\n\n### Effects of splitting\n\nDuring periods of high load or hotspots, Spanner uses\nsplitting as one technique to more evenly distribute your CPU utilization across\nyour provisioned compute resources. One side effect of splitting is a temporary increase\nin storage utilization. For data being split, over the course of the weekly\ncompaction cycle, there might be up to two copies of the original split range\nretained at a given time until the cycle has had a chance to shrink down the\nsplits and discard the extra copies of data.\n\n### Storage statistics\n\nAll data ingested into Spanner typically shows up in storage\nstatistics within a matter of minutes. However, in certain cases, even though\nthe data will be both accessible for reading (and durable through techniques\nlike write-ahead logging), it will take longer to show up in storage utilization\nstatistics, up to several days.\n\nThis happens because all ingested data (aside from a copy logged during commit\nfor durability and recovery purposes) resides temporarily in memory before being\nwritten out to physical storage in the background. The amount of data that can\nand will reside in memory and the amount of time it will live in memory before\nbeing written to physical storage depends on the size of your compute and the\nsize and performance of your workload.\n\nCreate storage alerts\n---------------------\n\nYou can [create storage alerts](/spanner/docs/monitoring-cloud#create-alert) in the\nCloud Monitoring console. We also provide a straightforward\nway to create a database storage alert directly from the\n[Google Cloud console](/spanner/docs/monitoring-console). The **Create alerting policy**\nlink in the chart (see screenshot) takes you to the create alert page in\nCloud Monitoring console and automatically prefills the relevant\nfields.\n\nRecommendations for database storage utilization\n------------------------------------------------\n\nWe recommend keeping your total database storage below the [storage\nlimit](/spanner/quotas#database_limits). This ensures that Spanner\nhas enough headroom to operate normally and perform routine maintenance on the\ndata.\n\nIf you are approaching the limit, Spanner may prevent you from\nperforming operations that put you over the limit, such as:\n\n- Restoring a database from a backup.\n- Modifying the database's schema (for example, adding an index).\n- Reducing the [compute capacity](/spanner/docs/compute-capacity) of your instance.\n\nIf you are over the storage limit, Spanner will attempt to operate\nnormally, but you may experience degraded performance or failure due to resource\npressure. If you do approach or exceed the recommended maximum,\nGoogle Cloud console displays a warning reading \"**The instance has reached\nits maximum storage capacity and may experience degraded activity**\" when\ndisplaying the affected instance.\n\nYou can also [create alerts in Cloud Monitoring](/spanner/docs/monitoring-cloud#create-alert) to notify\nyou.\n\nReduce database storage utilization\n-----------------------------------\n\nTo reduce an instance's database storage utilization, you can:\n\n- [Add more compute capacity](/spanner/docs/create-manage-instances#change-compute-capacity).\n- Delete a database.\n- [Delete data](/spanner/docs/dml-tasks) from a database. Note that even though data deletion takes effect immediately from a visibility perspective, it does not affect the storage utilization metric until Spanner compacts the data (typically within 12 hours, but it can take longer in certain cases). Therefore, you might notice a delay from when data is deleted to when the changes appears in the metric.\n\nIn general, we recommend that you add [compute capacity](/spanner/docs/compute-capacity) to your instance\nas a starting point. After you add compute capacity, you can investigate and\naddress the root causes of high storage utilization.\n\nIf you want to automate this process, you can create an application that\nmonitors database storage utilization, then adds and removes compute capacity as\nneeded, using the [`UpdateInstance`](/spanner/docs/reference/rpc/google.spanner.admin.instance.v1#google.spanner.admin.instance.v1.InstanceAdmin.UpdateInstance) method.\n\nWhat's next\n-----------\n\n- Monitor your instance with the [Google Cloud console](/spanner/docs/monitoring-console) or the [Cloud Monitoring console](/spanner/docs/monitoring-cloud).\n- [Create alerts for Spanner](/spanner/docs/monitoring-cloud#create-alert).\n- Find out how to [change the compute capacity](/spanner/docs/create-manage-instances#change-compute-capacity) of a Spanner instance."]]
