本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 评估表的容量模式
<a name="CostOptimization_TableCapacityMode"></a>

本节概述如何为 Amazon Keyspaces 表选择合适的容量模式。每种模式都经过优化，以满足不同工作负载对吞吐量变化的响应能力以及使用量计费方式的需求。在制定决策时，您必须平衡这些因素。

**Topics**
+ [有哪些表容量模式可用](#CostOptimization_TableCapacityMode_Overview)
+ [何时选择按需容量模式](#CostOptimization_TableCapacityMode_OnDemand)
+ [何时选择预置容量模式](#CostOptimization_TableCapacityMode_Provisioned)
+ [选择表容量模式时需要考虑的其他因素](#CostOptimization_TableCapacityMode_AdditionalFactors)

## 有哪些表容量模式可用
<a name="CostOptimization_TableCapacityMode_Overview"></a>

创建 Amazon Keyspaces 表时，您必须选择按需容量模式或预置容量模式。有关更多信息，请参阅 [在 Amazon Keyspaces 中配置 read/write 容量模式](ReadWriteCapacityMode.md)。

**按需容量模式**  
按需容量模式用于消除规划或预置 Amazon Keyspaces 表容量的需求。在此模式下，您的表会即时适应请求数，无需扩展或缩减任何资源（最高为表之前峰值吞吐量的两倍）。

按需容量表通过计算表的实际请求数进行计费，因此您只需按实际使用量付费，而不是按预置容量付费。

**预置容量模式**  
预置容量模式是一种更为传统的模式，在这种模式下，您可以直接定义可供表用于处理请求的容量，也可以借助 Application Auto Scaling 来定义。由于在任何给定时间表都预置了具体容量，因此基于预置容量而不是请求数量进行计费。而且，如果请求数超出分配的容量，就会导致表拒绝请求，降低应用程序用户的体验。

预置容量模式要求既不过度预置表容量，也不让表容量预置不足，以降低吞出容量不足错误出现的可能性和优化成本。

## 何时选择按需容量模式
<a name="CostOptimization_TableCapacityMode_OnDemand"></a>

在优化成本时，如果您有类似于下图的不可预测工作负载，则按需模式是您的最佳选择。

以下因素会导致此类工作负载：
+ 不可预测的请求时机（导致流量峰值）
+ 请求数量变动（由批量工作负载导致）
+ 某个时段内降至零或低于峰值的 18%（由开发或测试环境导致）

![\[图中显示了具有随机流量峰值的尖峰工作负载。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeOnDemand.png)


对于具有上述特征的工作负载，使用 Application Auto Scaling 来保持足够的容量以供表应对流量激增可能会导致不良后果。要么表过度预置，成本超出必要范围，要么表预置不足，请求导致了不必要的吞出容量不足错误。在这种情况下，按需容量表是更好的选择。

由于按需容量表按请求进行计费，您无需在表级别执行任何其他操作来优化成本。您应该定期评估按需容量表，以验证工作负载是否仍然具备上述特征。如果工作负载已经稳定，则可考虑改为预置模式以保持成本优化。

## 何时选择预置容量模式
<a name="CostOptimization_TableCapacityMode_Provisioned"></a>

适合预置容量模式的工作负载应该是具有可预测使用模式的工作负载，如下图所示。

以下因素有助于实现可预测的工作负载：
+ 给定时段或一天内的可预测/周期性流量
+ 短期内流量爆发有限

![\[图中显示了易于预测且峰值流量有限的工作负载。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeProvisioned.png)


由于给定时段或一天内的流量更加稳定，您可以将预置容量设置为相对接近于表的实际使用量。预置容量表的成本优化过程归根到底是一个练习的过程，即在不增加表的 `ThrottledRequests` 事件的情况下，让预置容量（蓝线）尽可能靠近使用容量（橙线）。两条线之间的空间既是容量浪费，又是避免吞出容量不足错误导致用户体验欠佳的保障。

Amazon Keyspaces 为预置容量表提供 Application Auto Scaling，该功能会自动为您实现均衡。您可以跟踪全天使用的容量，并根据一些变量来配置表的预置容量。

**最小容量单位**  
您可以设置表的最小容量来限制吞出容量不足错误的发生，但这不会降低表的成本。如果您的表有一段时间使用量较低，然后突然出现高使用量，那么设置最小值可以防止 Application Auto Scaling 将表容量设置得过低。

**最大容量单位**  
您可以设置表的最大容量，以限制将表扩大到超出预期值。对于无需大规模负载测试的开发或测试表，可考虑应用最大值。您可以为任意表设置最大值，但在生产环境中使用该表时，请务必定期根据表的使用基准评估此设置，以防止意外出现吞出容量不足错误。

**目标利用率**  
对于预置容量表，设置表的目标利用率是优化其成本的主要方法。将此值设置为较低的百分比会提高表的过度预置程度，进而增加成本，但可以降低出现吞出容量不足错误的风险。将此值设置为较高的百分比可以降低表的过度预置程度，但会提高出现吞出容量不足错误的风险。

## 选择表容量模式时需要考虑的其他因素
<a name="CostOptimization_TableCapacityMode_AdditionalFactors"></a>

在两种容量模式之间做出选择时，还需要考虑另外一些因素。

 在两种表模式之间做出选择时，请考虑这种额外折扣对表的成本有多大的影响。在许多情况下，在过度预置的预置容量表上，即使是相对不可预测的工作负载，采用预留容量也可能更经济。

**提高工作负载的可预测性**  
在某些情况下，工作负载可能会同时具有可预测和不可预测的模式。虽然按需容量表可以轻松支持这种模式，但如果能够改善工作负载中不可预测的模式，则可能会降低成本。

造成这种模式的最常见原因之一是批量导入。这种类型的流量通常会超过表的基准容量，以至于在运行表时出现吞出容量不足错误。要在预置容量表上确保此类工作负载的运行，请考虑以下选项：
+ 如果批处理按照预定时间进行，则可以在运行之前，计划增加应用程序自动扩缩容量。
+ 如果批处理随机进行，则可以考虑尝试延长运行所需的时间，而不是尽快执行。
+ 为导入操作添加一个加速期，在此期间，开始时导入的速度较慢，但会在几分钟内缓慢加快，直到 Application Auto Scaling 有机会开始调整表容量。