本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 評估資料表的容量模式
<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 中設定讀取/寫入容量模式](ReadWriteCapacityMode.md)。

**隨需容量模式**  
隨需容量模式旨在消除規劃或佈建 Amazon Keyspaces 資料表容量的需求。在此模式中，您的資料表會立即容納請求，而不需要擴展或縮減任何資源 （高達資料表先前尖峰輸送量的兩倍）。

隨需資料表的計費方式是針對資料表計算實際請求數，因此您只需支付您使用的項目，而非已佈建的項目。

**佈建容量模式**  
佈建容量模式是一種較傳統的模型，您可以在其中定義資料表可直接或在 Application Auto Scaling 的協助下可用於請求的容量。由於會在任何指定時間為資料表佈建特定容量，因此是根據佈建的容量而非請求數目進行計費。超過配置的容量也可能導致資料表拒絕請求，並減少應用程式使用者的體驗。

佈建容量模式需要在未過度佈建或佈建資料表下之間取得平衡，以實現低輸送量容量不足錯誤和最佳化成本。

## 何時選取隨需容量模式
<a name="CostOptimization_TableCapacityMode_OnDemand"></a>

當您有類似下圖所示的無法預測工作負載時，最佳化成本時，隨需模式是您的最佳選擇。

這些因素會導致這種類型的工作負載：
+ 無法預測的請求時機 (導致流量尖峰)
+ 變動的請求量 (由批次工作負載導致)
+ 下降到指定小時峰值的零或低於峰值的 18% （由開發或測試環境產生）

![\[影像顯示尖峰工作負載，其流量峰值隨機分佈。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeOnDemand.png)


對於具有上述特性的工作負載，使用 Application Auto Scaling 來維持足夠容量讓資料表回應流量激增，可能會導致不良結果。資料表可能過度佈建且成本超過必要，或者資料表可能佈建不足，且請求導致不必要的低容量輸送量錯誤。在這種情況下，隨需資料表是更好的選擇。

由於隨需資料表是依請求計費，因此您不需要再在資料表層級執行任何操作來最佳化成本。您應該定期評估隨需資料表，以確認工作負載仍具有上述特性。如果工作負載已穩定，請考慮變更為佈建模式，以維持成本最佳化。

## 何時選取佈建容量模式
<a name="CostOptimization_TableCapacityMode_Provisioned"></a>

佈建容量模式的理想工作負載是具有更可預測用量模式的工作負載，如下圖所示。

下列因素會導致可預測的工作負載：
+ 特定一小時或一天內的可預測/周期性流量
+ 有限度的短期突發流量

![\[影像顯示可預測性佳且流量峰值有限的工作負載。\]](http://docs.aws.amazon.com/zh_tw/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 有機會開始調整資料表容量為止。