使用 DynamoDB Auto Scaling 自动管理吞吐能力
许多数据库工作负载本质上是周期性的，而另一些则难以提前进行预测。例如，考虑一个大多数用户在白天处于活跃状态的社交网络应用程序。数据库必须能够处理白天活动，但夜间不需要相同级别的吞吐量。而在另一个例子中，请考虑正在经历用户快速增长的新移动游戏应用程序。如果此游戏变得太受欢迎，它可能会超出可用的数据库资源，从而导致性能降低并使客户感到不满。这些类型的工作负载通常需要手动干预来扩展或缩减数据库资源，以便响应不断变化的使用量级别。
Amazon DynamoDB Auto Scaling 使用 Amazon Application Auto Scaling 服务代表您动态调整预置的吞吐容量，以响应实际的流量模式。这使表或全局二级索引（GSI）能够增大其预置的读取和写入容量来处理突发的流量增加，而不会发生节流。当工作负载减少时，Application Auto Scaling 可以减少吞吐量，这样您就无需为未使用的预置容量付费。
注意
如果您使用 Amazon Web Services Management Console 创建表或全局二级索引，默认情况下将启用 DynamoDB Auto Scaling。您可以随时修改 Auto Scaling 设置。有关更多信息，请参阅 通过 Amazon Web Services Management Console使用 DynamoDB 自动扩缩。
删除表或全局表副本时，任何关联的可扩展目标、扩缩策略或 CloudWatch 告警都不会随之自动删除。
使用 Application Auto Scaling，您可以创建为表或全局二级索引扩展策略。扩展策略指定是要扩展读取容量还是写入容量（或二者同时扩展），并为表或索引指定最小的和最大的预置容量单位设置。
扩展策略还包含目标使用率，某个时间点已使用的预调配吞吐量的百分比。Application Auto Scaling 使用目标跟踪算法来向上或向下调整表（或索引）的预调配吞吐量以响应实际工作负载，从而使实际容量使用率达到或接近您的目标使用率。
DynamoDB 输出在一分钟时段内所使用的预调配吞吐量。当所使用的容量在两个连续的一分钟时段内均超过配置的目标利用率时，就会触发自动扩缩。在触发自动扩缩之前，CloudWatch 警报可能会有至多几分钟的短暂延迟。这一延迟可确保准确评估 CloudWatch 指标。如果已使用的吞吐量峰值间隔超过一分钟，则可能不会触发自动扩缩。同样，当 15 个连续的数据点低于目标利用率时，则可能发生缩减事件。无论是哪种情况，在自动扩缩触发之后，都会调用 UpdateTable API。然后，需要几分钟的时间才能更新表或索引的预置容量。在此期间，任何超过表的先前预置容量的请求都会被节流。
重要
您无法调整要超过的数据点数量来触发底层警报（尽管当前的数值将来可能会发生变化）。
您可以为读取和写入容量设置介于 20% 和 90% 之间的 Auto Scaling 目标利用率值。
注意
除了表之外，DynamoDB Auto Scaling 还支持全局二级索引。每个全局二级索引均有各自的预置的吞吐容量，这独立于其基表的吞吐容量。在为全局二级索引创建扩展策略时，Application Auto Scaling 将调整索引的预调配吞吐量设置，确保其实际使用量达到或接近所需的使用率。
DynamoDB Auto Scaling 的工作原理
注意
要快速开始使用 DynamoDB Auto Scaling，请参阅 通过 Amazon Web Services Management Console使用 DynamoDB 自动扩缩。
下图简要概述了 DynamoDB Auto Scaling 管理表的吞吐能力的方式。
以下步骤汇总了上图中所示的 Auto Scaling 流程：
-
为 DynamoDB 表创建 Application Auto Scaling 策略。
-
DynamoDB 会将使用的容量指标发布到 Amazon CloudWatch。
-
如果表使用的容量在特定时段内超出目标使用率 (或低于目标使用率)，则 Amazon CloudWatch 将触发警报。您可以在控制台上查看警报并使用 Amazon Simple Notification Service (Amazon SNS) 接收通知。
-
CloudWatch 警报调用 Application Auto Scaling 来评估扩展策略。
-
Application Auto Scaling 发出
UpdateTable请求以调整表的预调配吞吐量。 -
DynamoDB 处理
UpdateTable请求，并动态增加（或减少）表的预置的吞吐容量，使它接近目标使用率。
为了解 DynamoDB Auto Scaling 的工作方式，假定您有一个名为 ProductCatalog 的表。由于很少将数据批量加载到表中，因此不会出现大量写入活动。不过，表会遇到大量的读取活动，此活动随时间的推移而变化。通过监控 ProductCatalog 的 Amazon CloudWatch 指标，您确定表需要 1200 个读取容量单位（避免在活动到达峰值时出现 DynamoDB 限制读取请求的情况）。您还确定，在读取流量达到其最低值时，ProductCatalog 至少需要 150 个读取容量单位。有关防止限制的更多信息，请参阅DynamoDB 节流问题。
在 150 到 1200 个读取容量单位的范围内，您确定 70% 的目标使用率将适合 ProductCatalog 表。目标利用率是使用的容量单位与预置容量单位的比率（以百分比表示）。应用 Application Auto Scaling 使用其目标跟踪算法来确保 ProductCatalog 会根据需要进行调整，使利用率保持在 70% 或接近 70%。
注意
仅当实际工作负载在几分钟的持续时段内保持提高或降低时，DynamoDB Auto Scaling 才会修改预调配吞吐量设置。Application Auto Scaling 目标跟踪算法寻求使目标使用率长期达到或接近选定值。
表的内置容量暴增将容纳活动的短时间突增峰值。有关更多信息，请参阅 容量爆增。
要为 ProductCatalog 表启用 DynamoDB Auto Scaling，请创建扩展策略。此策略指定以下内容：
-
要管理的表或全局二级索引
-
要管理的容量类型（读取容量或写入容量）
-
预配置吞吐量设置的上限和下限
-
您的目标利用率
创建扩展策略时，Application Auto Scaling 将代表您创建一对 Amazon CloudWatch 警报。每对警报均指明预调配吞吐量设置的上限和下限。当表的实际使用率在一段持续时间内偏离目标使用率时，将触发这些 CloudWatch 警报。
当触发某个 CloudWatch 警报时，Amazon SNS 将向您发送通知（如果您已启用通知）。随后，CloudWatch 警报将调用 Application Auto Scaling，后者随之通知 DynamoDB 视情况向上或向下调整 ProductCatalog 表的预配置容量。
在扩展事件发生期间，Amazon Config 按记录的配置项目进行收费。发生扩展事件时，会为每个读取和写入自动扩缩事件创建四个 CloudWatch 警报，即两个 ProvisionedCapacity 警报（ProvisionedCapacityLow、ProvisionedCapacityHigh）和两个 ConsumedCapacity 警报（AlarmHigh、AlarmLow）。这会导致总共创建八个警报。因此，Amazon Config 为每个扩展事件记录八个配置项目。
注意
您还可以安排 DynamoDB 扩展，使其在特定时间进行。点击此处了解基本步骤。
使用说明
在开始使用 DynamoDB Auto Scaling 之前，您应了解以下内容：
-
DynamoDB Auto Scaling 会根据您的自动扩缩策略增加读取容量或写入容量任意次数。所有 DynamoDB 配额都将保持有效，如 Amazon DynamoDB 中的配额 中所述。
-
DynamoDB Auto Scaling 不会阻止您手动修改预置的吞吐量设置。这些手动调整不会影响与 DynamoDB Auto Scaling 相关的任何现有 CloudWatch 警报。
-
如果您为包含一个或多个全局二级索引的表启用 DynamoDB Auto Scaling，强烈建议您也对这些索引统一应用自动扩缩。这将有助于确保更好的表写入和读取性能，并帮助避免节流。您可以在 Amazon Web Services Management Console 中选择将相同设置应用到全局二级索引来启用自动扩缩。有关更多信息，请参阅 在现有表上启用 DynamoDB 自动扩缩。
-
删除表或全局表副本时，任何关联的可扩展目标、扩缩策略或 CloudWatch 告警都不会随之自动删除。
-
为现有表创建 GSI 时，系统不会为 GSI 启用自动扩缩。在构建 GSI 时，您必须手动管理容量。GSI 上的回填完成并到达活动状态后，自动扩缩操作将正常运行。