评估预置容量大小是否合适
本节概述如何评估您的 DynamoDB 表预置大小是否合适。随着工作负载的演变，您应该相应地修改操作程序，尤其是当您的 DynamoDB 表以预置模式配置时，因为它们可能存在过度配置或配置不足的风险。
下述程序需要来自于支持您的生产应用程序的 DynamoDB 表的统计信息。要了解您的应用程序行为，应该定义一个足够长的周期，以捕捉应用程序中的数据季节性特点。例如，如果您的应用程序表现出周模式，则不妨使用三周的周期来分析应用程序吞吐量需求。
如果您不知道从哪里开始，可根据至少一个月的使用数据来进行以下计算。
在评估容量时，DynamoDB 表可以独立配置读取容量单位 (RCU) 和写入容量单位 (WCU)。如果您的表配置了任何全局二级索引 (GSI)，则需要指定它们将占用的吞吐量，这些吞吐量也将独立于基表的 RCU 和 WCU。
注意
本地二级索引 (LSI) 占用基表的容量。
如何检索 DynamoDB 表上的占用指标
要评估表和 GSI 容量，请监控以下 CloudWatch 指标，然后选择适当的维度来检索表或 GSI 信息：
| 读取容量单位 | 写入容量单位 |
|---|---|
|
|
|
|
|
|
|
|
|
您可以通过 Amazon CLI 或 Amazon Web Services Management Console 来执行此操作。
如何识别配置不足的 DynamoDB 表
对于大多数工作负载，如果一个表持续消耗其配置容量超过 80%，则该表被视为配置不足。
容量暴增是 DynamoDB 的一项功能，它允许客户临时消耗比最初配置更多的 RCU/WCU（超过表中定义的每秒预置吞吐量）。创建容量暴增的目的是应对因特殊事件或使用量高峰而突然增加的流量。这种容量暴增不能永远持续下去。一旦未用的 RCU 和 WCU 耗尽，您再试图消耗比预置更多的容量时，就会被节流。当您的应用程序流量接近 80% 的利用率时，被节流的风险会大大增加。
80% 的利用率规则因数据的季节性和流量增长而异。考虑以下场景：
-
如果您的流量在过去 12 个月中一直稳定在大约 90% 的利用率，那么您的表容量正合适
-
如果您的应用程序流量在不到 3 个月内以每月 8% 的速度增长，那么您将达到 100% 利用率
-
如果您的应用程序流量在略长于 4 个月内以每月 5% 的速度增长，那么您仍然将达到 100% 利用率
以上查询的结果可以说明您的利用率。将它们作为指导，来进一步评估其他指标，以帮助您在需要时选择增加表容量（例如：每月或每周增长率）。与您的运营团队合作，为您的工作负载和表定义一个合适的百分比。
在有些特殊场景中，当我们每天或每周进行数据分析时，会发现数据是倾斜的。例如，季节性应用程序在工作时间会出现使用量激增情况（但在工作时间之外则降至几乎为零），您可以通过安排自动扩缩来轻松指定一天中什么时间（以及一周中的星期几）增加预置容量，以及何时减少预置容量。即使您的季节性不那么明显，也可以利用 DynamoDB 表自动扩缩配置，而无需为了涵盖繁忙时间而设定较高的容量。
注意
为基表创建 DynamoDB Auto Scaling 配置时，请记住为任何与该表关联的 GSI 包括另一个配置。
如何识别过度配置的 DynamoDB 表
从上述脚本中获得的查询结果提供了执行某些初始分析所需的数据点。如果您的数据集在多个时间间隔内显示为利用率低于 20%，则您的表可能配置过度。要进一步确定是否需要减少 WCU 和 RCU 的数量，应重新查看间隔内的其他读数。
当您的表包含多个低使用量间隔时，您其实可以利用自动扩缩策略，安排自动扩缩，或者为表配置基于利用率的默认自动扩缩策略。
如果您的工作负载具有低利用率和高节流比率（间隔内的 Max(ThrottleEvents)/Min(ThrottleEvents)），这说明在某些天（或几小时）内流量大增，因而造成了非常高的工作负载，但总体上流量一直较低。在这些场景中，使用预定自动扩缩可能有所裨益。