确定 DynamoDB 中未使用的资源
本部分概述如何定期评估未使用资源。随着应用程序需求的演变,您应确保没有未使用的资源,并且不会导致不必要的 Amazon DynamoDB 成本。下面介绍的过程将使用 Amazon CloudWatch 指标来确定未使用的资源,帮助您识别这些资源并对其采取措施以降低成本。
您可以使用 CloudWatch 监控 DynamoDB,此工具可以从 DynamoDB 收集原始数据,处理为可读取的近实时指标。这些统计数据会保留一段时间,这样您便可以访问历史信息,更好地了解使用情况。默认情况下,DynamoDB 指标数据自动发送到 CloudWatch。有关更多信息,请参阅《Amazon CloudWatch 用户指南》中的什么是 Amazon CloudWatch?和指标保留。
如何确定未使用的资源
为了确定未使用的表或索引,我们将查看以下 30 天内的 CloudWatch 指标,以了解是否对表进行了任何有效的读取或写入,或者全局二级索引 (GSI, Global Secondary Index) 上是否有任何读取操作:
已使用读取容量单位
在指定时间段内使用的读取容量单位数,这样便可以跟踪您在已占用容量中使用的容量。可以检索表及其所有全局二级索引或特定全局二级索引占用的总读取容量。
已使用写入容量单位
在指定时间段内使用的写入容量单位数,这样便可以跟踪您在已占用容量中使用的容量。可以检索表及其所有全局二级索引或特定全局二级索引占用的总写入容量。
确定未使用的表资源
Amazon CloudWatch 是一项监控和可观察性服务,提供可用于确定未使用资源的 DynamoDB 表指标。CloudWatch 指标可以通过 AWS Management Console 以及 AWS Command Line Interface 查看。
清理未使用的表资源
如果您已确定未使用的表资源,则可以通过以下方式降低其持续成本。
注意
如果您已确定未使用的表,但仍希望将其保持可用状态,以防将来需要访问该表,请考虑将其切换到按需模式。否则,您可以考虑备份并彻底删除该表。
容量模式
DynamoDB 对 DynamoDB 表收取读取、写入和存储数据费用。
DynamoDB 具有按需和预置这两种容量模式,它们对表上处理的读取和写入采用特定的计费选项。读/写容量模式控制对读写吞吐量收费的方式以及管理容量的方式。
对于按需模式表,您无需指定预期应用程序执行的读写吞吐量。DynamoDB 按照读取请求单位和写入请求单位对应用程序在表上执行的读取和写入操作收费。如果表/索引上没有活动,则您无需为吞吐量付费,但仍会产生存储费用。
表类
DynamoDB 还提供了两个表类,旨在帮助您优化成本。“DynamoDB 标准”表类是原定设置,建议用于大多数工作负载。“DynamoDB 标准-不经常访问 (DynamoDB Standard-IA)”表类别针对存储占据主要成本的表进行优化。
如果您的表或索引上没有活动,则主要成本可能是存储成本,更改表类将节省大量费用。
删除表
如果您发现了一个未使用的表并想将其删除,则可能需要先备份或导出数据。
通过 AWS Backup 执行的备份可以利用冷存储分层,从而进一步降低成本。有关如何启用通过 将 AWS Backup 与 DynamoDB 结合使用 Backup 进行备份的信息,请参阅 AWS 文档;有关如何使用生命周期将备份转移到冷存储的信息,请参阅管理备份计划文档。
或者,您可以选择将表的数据导出到 S3。为此,请参阅导出至 Amazon S3 文档。导出数据后,如果您希望利用 S3 Glacier Instant Retrieval、S3 Glacier Flexile Retrieval 或 S3 Glacier Deep Archive 进一步降低成本,请参阅管理存储生命周期。
备份表后,您可以选择通过 AWS Management Console 或通过 AWS Command Line Interface 将其删除。
确定未使用的 GSI 资源
确定未使用的全局二级索引的步骤与确定未使用的表的步骤类似。在写入基表的项目中包含用作 GSI 分区键的属性时,由于 DynamoDB 会将此类项目复制到 GSI,如果基表在使用,则未使用的 GSI 仍有可能具有大于 0 的 ConsumedWriteCapacityUnits
。因此,您将仅评估 ConsumedReadCapacityUnits
指标来确定 GSI 是否未使用。
要通过 AWS AWS CLI 查看 GSI 指标,您可以使用以下命令评估表的读取数:
aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time <start-time> --end-time <end- time> --period <period> --namespace AWS/DynamoDB --statistics Sum -- dimensions Name=TableName,Value=<table-name> Name=GlobalSecondaryIndexName,Value=<index-name>
为了避免错误地将表标识为未使用,您需要评估较长时段内的指标。选择合适的开始时间和结束时间范围(例如 30 天)以及合适的时间段,例如 86400。
在返回的数据中,任何大于 0 的 Sum(合计)都表示您所评估的表在该时间段内收到了读取流量。
以下结果显示 GSI 在评估时段内收到了读取流量:
{ "Timestamp": "2022-08-17T21:20:00Z", "Sum": 36319167.0, "Unit": "Count" }, { "Timestamp": "2022-08-11T21:20:00Z", "Sum": 1869136.0, "Unit": "Count" },
以下结果显示 GSI 在评估时段内收到了极少的读取流量:
{ "Timestamp": "2022-08-28T21:20:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-15T21:20:00Z", "Sum": 2.0, "Unit": "Count" },
以下结果显示 GSI 在评估时段内未收到读取流量:
{ "Timestamp": "2022-08-17T21:20:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-11T21:20:00Z", "Sum": 0.0, "Unit": "Count" },
清理未使用的 GSI 资源
如果您已确定未使用的 GSI,则可以选择将其删除。由于 GSI 中存在的所有数据也存在于基表中,因此在删除 GSI 之前无需进行额外备份。如果以后会再次需要 GSI,则可以将其重新添加到表中。
如果您发现了不常使用的 GSI,则应考虑更改应用程序中的设计,以便将其删除或减少其成本。例如,虽然 DynamoDB 扫描会消耗大量系统资源而应谨慎使用,但如果很少使用其支持的访问模式,则它们可能比 GSI 更具成本效益。
此外,如果需要 GSI 来支持不频繁的访问模式,可以考虑规划一组更有限的属性。尽管后续可能需要对基表进行查询以支持不频繁的访问模式,但它有可能显著降低存储和写入成本。
清理未使用的全局表
Amazon DynamoDB 全局表 为部署多区域、多活跃数据库提供了完全托管式解决方案,而不必构建和维护您自己的复制解决方案。
全局表非常适合在靠近用户的位置提供对数据的低延迟访问,也可以用作灾难恢复的辅助区域。
如果为某个资源启用了全局表选项以提供低延迟的数据访问,但该选项并未包括在灾难恢复策略中,请通过评估副本的 CloudWatch 指标来验证这两个副本是否正在主动处理读取流量。如果一个副本没有处理读取流量,则它可能是未使用的资源。
如果全局表包括在灾难恢复策略中,则在主动/备用模式下,预计会有一个副本不会收到读取流量。
清理未使用的备份或时间点故障恢复(PITR)
DynamoDB 提供两种备份方式。时间点故障恢复提供 35 天的连续备份,帮助您防止意外写入或删除,而按需备份则允许创建可长期保存的快照。这两种类型的备份都有相关的成本。
请参阅 DynamoDB 的备份和还原 和 DynamoDB 的时间点备份 文档,以确定您的表是否启用了可能不再需要的备份。