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

評估 DynamoDB 資料表用量模式

本節概述如何判斷您有效地使用 DynamoDB 資料表。某些用量模式對 DynamoDB 來說並非最理想的，且從效能和成本角度來看，這些模式仍有最佳化空間。

執行較少高度一致性讀取操作

DynamoDB 可讓您根據每個請求設定讀取一致性。根據預設，讀取請求最終會保持一致。最後，一致性的讀取會RCU針對最多 4 KB 的資料收取 0.5 的費用。

分散式工作負載的多數部分都具有彈性，可以容忍最終一致性。但是，有些存取模式要求高度一致性讀取。對於RCU最多 4 KB 的資料，強烈一致的讀取收費為 1，基本上是讀取成本的兩倍。DynamoDB 讓您能在同一個資料表上使用這兩種一致性模式。

您可以評估工作負載和應用程式的程式碼，確定是否僅在需要時使用高度一致性讀取。

執行較少的讀取操作交易

DynamoDB 可讓您以某種 all-or-nothing方式將特定動作分組，這表示您可以使用 DynamoDB 執行ACID交易。但是，如同關聯式資料庫，並非每個動作都需要遵循這種方法。

與預設 0.5 RCUs 相反，最多 4 KB 的交易讀取操作會耗用 2，RCUs以最終一致的方式讀取相同數量的資料。寫入操作會將成本加倍，這表示交易寫入最多 1 KB 等於 2 WCUs。

若要判斷資料表上的所有操作是否為交易，資料表的 CloudWatch 指標可以篩選為交易 APIs。如果交易APIs是資料表SuccessfulRequestLatency指標下唯一可用的圖形，這將確認每個操作都是此資料表的交易。或者，如果整體容量使用率趨勢與交易API趨勢相符，請考慮重新檢視應用程式設計，因為它似乎是由交易 所主導APIs。

執行較少掃描

會廣泛使用 Scan 操作，通常源於對 DynamoDB 資料執行分析查詢的需求。在大型資料表上執行頻繁 Scan 操作可能既低效又昂貴。

更好的替代方案是使用 Export to S3 功能，並選擇時間點將資料表狀態匯出至 S3。 AWS 提供 Athena 等服務，然後可用於在資料上執行分析查詢，而不會消耗資料表中的任何容量。

您可以使用 Scan 的 SuccessfulRequestLatency 指標下的 SampleCount 統計資料，決定 Scan 操作的頻率。若 Scan 操作確實十分頻繁，則應重新評估存取模式和資料模型。

縮短屬性名稱

DynamoDB 項目的總大小是其屬性名稱長度和值的總和。屬性名稱過長不僅會導致儲存成本，還可能導致更高的 RCU/WCU 消耗。建議您選擇較短的屬性名稱，而不是較長的屬性名稱。屬性名稱較短有助於限制下一個 4KB/1KB 界限內的項目大小，之後您會使用其他 RCU/WCU 來存取資料。

啟用存留時間 (TTL)

存留時間 （TTL） 可以識別比您在項目上設定的到期時間更早的項目，並從資料表中移除它們。如果您的資料隨著時間的推移而增長，而較舊的資料變得無關，在資料表TTL上啟用 有助於縮減資料並節省儲存成本。

的另一個實用方面TTL是，過期項目會在 DynamoDB 串流上發生，因此，除了從您的資料中移除資料之外， 還可以從串流中取用這些項目，並將其封存到成本較低的儲存層。此外，透過 刪除項目TTL無需額外成本 — 它不會消耗容量，而且設計清除應用程式不會額外負荷。

以跨區域備份取代全域資料表

全域表格可讓您在不同區域中維護多個使用中複本資料表 — 這些資料表皆可接受寫入操作，並彼此複寫資料。您可以輕鬆設定複本，系統會為您管理同步處理。使用最後一個寫入獲勝策略，將複本收斂到一致。

若您僅使用全域資料表做為容錯移轉或災難復原 (DR) 策略的一部分，您可以將資料表取代為跨區域備份複本，以達到相對較寬鬆的復原點目標，和復原時間目標需求。若您不需要快速的本機存取和五個九的高可用性，維護全域資料表複本可能不是容錯移轉的最佳方法。

或者，請考慮使用 AWS Backup 來管理 DynamoDB 備份。與使用全域資料表相比，您可以排程定期備份並跨區域複製備份，以更符合成本效益的方式滿足 DR 需求。