# 评估 DynamoDB 表的容量模式
本部分概述如何为 DynamoDB 表选择合适的容量模式。每种模式都经过优化，以满足不同工作负载对吞吐量变化的响应能力以及使用量计费方式的需求。在制定决策时，您必须平衡这些因素。
**Topics**
+ [有哪些表容量模式可用](#CostOptimization_TableCapacityMode_Overview)
+ [何时选择按需容量模式](#CostOptimization_TableCapacityMode_OnDemand)
+ [何时选择预置容量模式](#CostOptimization_TableCapacityMode_Provisioned)
+ [选择表容量模式时需要考虑的其他因素](#CostOptimization_TableCapacityMode_AdditionalFactors)
## 有哪些表容量模式可用
创建 DynamoDB 表时，您必须选择按需容量模式或预置容量模式。
在 24 小时滚动窗口内，表最多可以从预置容量模式切换到按需模式四次。您可以随时将表从按需模式切换到预置容量模式。
**按需容量模式**
[按需容量模式](on-demand-capacity-mode.md)旨在消除规划或预置 DynamoDB 表容量的需求。在此模式下，您的表会即时适应对表的请求数，无需扩展或缩减任何资源（最高为表之前峰值吞吐量的两倍）。
DynamoDB 按需模式针对读取和写入请求提供按请求支付定价，您只需为使用的资源付费。
**预置容量模式**
[预置容量](provisioned-capacity-mode.md)模式是一种更为传统的模式，在这种模式下，您必须定义表可供请求使用的容量，此容量可以是直接供请求使用的，也可以是借助自动扩缩功能供请求使用的。由于在任何给定时间表都为表预置了特定的容量，因此，将基于预置的总容量而不是使用的请求数量来进行计费。而且，如果请求数超出分配的容量，就会导致表拒绝请求，降低应用程序用户的体验。
预置容量模式要求持续监控，以便在不过度预置表容量与避免预置容量不足之间找到平衡点，从而尽量避免节流并优化成本。
## 何时选择按需容量模式
在优化成本时，如果工作负载类似于下面的各图，则按需模式是您的最佳选择。
以下因素会导致此类工作负载：
+ 随时间推移而演变的流量模式
+ 请求数量变动（由批量工作负载导致）
+ 不可预测的请求时机（导致流量峰值）
+ 在给定时段内降至零或峰值的 30% 以下
![\[这些图显示了不可预测、可变的工作负载，包括峰值和活动量较低的时段。\]](http://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/images/choose-on-demand-1.png)![\[这些图显示了不可预测、可变的工作负载，包括峰值和活动量较低的时段。\]](http://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/images/choose-on-demand-2.png)
对于具有上述因素的工作负载，使用自动扩缩功能在表上维持足够的容量来应对流量峰值时，可能会导致过度预置表容量而超出必要的成本，或者表容量预置不足，请求受到不必要的限制。按需容量模式是更好的选择，因为它可以处理波动的流量，而无需您预测或调整容量。
使用按需模式的按请求付费定价模式，您不必担心闲置的容量，因为您只需为您实际使用的吞吐量付费。将按所消耗的读取或写入请求向您收费，因此成本直接反映了实际使用量，从而可以轻松平衡成本和性能。或者，您还可以为各个按需表和全局二级索引配置每秒最大读取和/或写入吞吐量，来协助限制成本和用量。有关更多信息，请参阅[按需表的最大吞吐量](on-demand-capacity-mode-max-throughput.md)。
## 何时选择预置容量模式
如下图所示，预置容量模式的理想工作负载是具有更稳定和更可预测的使用模式的工作负载。
**注意**
建议在对预置容量采取行动之前，在精细的时段（例如 14 天）查看指标。
以下因素会导致此类工作负载：
+ 给定时段或一天内稳定、可预测和周期性流量
+ 短期内流量爆发有限
![\[该图描绘了可预测的周期性工作负载，且流量峰值受限。\]](http://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/images/choose-provisioned-1.png)
由于给定时段或一天内的流量更加稳定，因此，您可以将表的预置容量设置为相对接近于表的实际使用容量。预置容量表的成本优化过程归根到底是一个练习的过程，即在不增加表上 `ThrottledRequests` 的情况下，让预置容量（蓝线）尽可能靠近使用容量（橙线）。两条线之间的空间既是容量浪费，又是避免节流导致用户体验欠佳的保障。如果您可以预测应用程序的吞吐量需求，并且更喜欢成本可预测性（控制读取和写入容量），那么您可能需要继续使用预置表。
DynamoDB 为预置容量表提供自动扩缩功能，此功能会代表您自动进行平衡。这样，您便可以跟踪全天使用的容量，并根据一些变量来设置表的容量。使用自动扩缩时，表将被过度预置，您需要微调限制数量与过度预置的容量单位之间的比率，以满足工作负载需要。
![\[DynamoDB 控制台。预置容量，且已启用自动扩缩。目标利用率设置为 70。\]](http://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/images/CostOptimization/TableCapacityModeAutoScaling.png)
**最小容量单位**
您可以设置表的最小容量来限制节流的情况，但这不会降低表的成本。如果您的表具有低使用量时段，然后突然出现高使用量，则设置最小值可以防止自动扩缩操作将表容量设置得过低。
**最大容量单位**
您可以设置表的最大容量，以限制将表扩大到超出预期值。对于无需大规模负载测试的开发或测试表，请考虑应用最大值。您可以为任意表设置最大值，但是在生产中使用该表时，请务必定期根据表的使用基准评估此设置，以防止意外节流。
**目标利用率**
对于预置容量表，设置表的目标利用率是优化其成本的主要方法。将此值设置为较低的百分比会增加过度预置的表容量，进而增加成本，但可以降低出现节流的风险。将此值设置为较高的百分比会减少过度预置的表容量，但会增加出现节流的风险。
## 选择表容量模式时需要考虑的其他因素
在两种模式之间做出选择时，还需要考虑另外一些因素。
**预置容量利用率**
要确定按需模式的成本何时会低于预置容量，查看预置容量利用率会有所帮助，这是指所分配（或“预置”）的资源的使用效率。对于平均预置容量利用率低于 35% 的工作负载，按需模式的成本更低。在许多情况下，即使对于预置容量利用率高于 35% 的工作负载，使用按需模式也可能更具成本效益，尤其是在工作负载处于低活动期但偶尔会出现峰值的情况下。
**预留容量**
对于预置容量表，DynamoDB 允许您为读取和写入容量购买预留容量（复制写入容量单位 (rWCU, Replicated Write Capacity Unit) 和标准-IA 表目前不符合条件）。与标准预置容量定价相比，预留容量可享受大幅折扣。
在两种表模式之间做出选择时，请考虑这种额外折扣对表的成本有多大的影响。在某些情况下，在过度预置的预置容量表上运行相对不可预测的工作负载时，采用预留容量可以实现更低的成本。
**提高工作负载的可预测性**
在某些情况下，工作负载可能会同时具有可预测和不可预测的模式。虽然按需表可以轻松支持这种模式，但如果能够改善工作负载中不可预测的模式，则可能会获得更好的成本。
造成这些模式的最常见原因之一是批量导入。这种类型的流量通常会超过表的基准容量，以至于在运行此操作时表会出现节流。要在预置容量表上确保此类工作负载的运行，请考虑以下选项：
+ 如果批处理按照预定时间进行，则可以在运行之前，计划增加自动扩缩容量。
+ 如果批处理随机进行，请考虑尝试延长运行时间，而不是尽快执行
+ 为导入操作添加一个加速期，在此期间，开始时导入的速度较小，但会在几分钟内缓慢增加，直到自动扩缩功能有机会开始调整表容量。