# 评估您的 DynamoDB 表使用模式
<a name="CostOptimization_TableUsagePatterns"></a>

本节概述如何评估您使用 DynamoDB 表是否高效。有些使用模式对于 DynamoDB 来说不是最佳的，在性能和成本方面还有优化的空间。

**Topics**
+ [执行更少的强一致性读取操作](#CostOptimization_TableUsagePatterns_StronglyConsistentReads)
+ [执行更少的读取操作事务](#CostOptimization_TableUsagePatterns_Transactions)
+ [执行更少的扫描](#CostOptimization_TableUsagePatterns_Scans)
+ [缩短属性名称](#CostOptimization_TableUsagePatterns_AttributeNames)
+ [启用生存时间（TTL）](#CostOptimization_TableUsagePatterns_TTL)
+ [用跨区域备份替换全局表](#CostOptimization_TableUsagePatterns_GlobalTables)

## 执行更少的强一致性读取操作
<a name="CostOptimization_TableUsagePatterns_StronglyConsistentReads"></a>

DynamoDB 允许您根据每个请求来配置[读取一致性](HowItWorks.ReadConsistency.md)。默认情况下，读取请求为最终一致性的。最终一致性读取的收费标准是 4KB 及以下数据量为 0.5RCU。

大多数分布式工作负载具有灵活性，能够容许最终一致性。但是，也有一些访问模式需要强一致性读取。强一致性读取的收费标准是 4KB 及以下数据量为 1RCU，读取成本基本上翻了一倍。DynamoDB 提供了在同一个表上使用这两种一致性模型的灵活性。

您可以评估一下您的工作负载和应用程序代码，确认是否只在需要时才使用强一致性读取。

## 执行更少的读取操作事务
<a name="CostOptimization_TableUsagePatterns_Transactions"></a>

DynamoDB 允许您采用“全或无”的方式对某些操作进行分组，这意味着您可以使用 DynamoDB 执行 ACID 事务。但是，如同在关系数据库中一样，不必让每个操作都遵循此方法。

一个 4KB 及以下数据量的[事务型读取操作](transaction-apis.md#transaction-capacity-handling.title)会占用 2RCU，而以最终一致性方式读取同样数量的数据会占用默认的 0.5RCU。写入操作的成本是翻倍的，这意味着，1KB 及以下数量的事务型写入将占用 2WCU。

要判断表上的所有操作是否都是事务，可以筛选表的 CloudWatch 指标，直到只剩下事务 API。如果表的 `SuccessfulRequestLatency` 指标下只剩下事务 API 图，则可以确认，每个操作就是该表的一个事务。或者，如果整体容量利用率趋势与事务 API 趋势一致，请考虑重新审视应用程序设计，因为它似乎被事务 API 所主导。

## 执行更少的扫描
<a name="CostOptimization_TableUsagePatterns_Scans"></a>

`Scan` 操作的广泛使用通常源于对 DynamoDB 数据运行分析查询的需求。在大型表上频繁运行 `Scan` 操作既效率低下又成本高昂。

一种更好的替代方法是使用[导出到 S3](S3DataExport.HowItWorks.md#S3DataExport.HowItWorks.title) 功能并选择将表状态导出到 S3 的一个时间点。AWS 提供了类似 Athena 这样的服务，可以在不占用任何表容量的情况下对数据运行分析查询。

`Scan` 操作的频率可以使用 `Scan` 的 `SuccessfulRequestLatency` 指标下的 `SampleCount` 统计数据来确定。如果 `Scan` 操作确实非常频繁，则应重新评估访问模式和数据模型。

## 缩短属性名称
<a name="CostOptimization_TableUsagePatterns_AttributeNames"></a>

在 DynamoDB 中，一个项目的总大小是其属性名称长度加上值的总和。长的属性名称不仅会增加存储成本，还可能导致 RCU/WCU 占用量增加。建议您选择较短的属性名，而不要选择较长的属性名。短的属性名有助于将项目大小限制在下一个 4KB/1KB 范围内，避免占用额外的 RCU/WCU 来访问数据。

## 启用生存时间（TTL）
<a name="CostOptimization_TableUsagePatterns_TTL"></a>

[生存时间（TTL）](TTL.md#TTL.title)可以发现超过设定的过期时间的项目，并将它们从表中删除。如果您的数据随着时间的推移而增长，并且较旧的数据变得无关紧要，则在表上启用 TTL 可以帮助减少数据并节省存储成本。

 TTL 的另一个用处是，当您的 DynamoDB 流上存在过期的项目时，除了删除它们之外，也可以利用它们，并将其存档到一个成本较低的存储层上。此外，通过 TTL 删除项目无需额外成本，既不占用容量，也不产生设计清理应用程序的开销。

## 用跨区域备份替换全局表
<a name="CostOptimization_TableUsagePatterns_GlobalTables"></a>

[全局表](GlobalTables.md#GlobalTables.title)允许您在不同的区域维护多个活动副本表，这些表都可以接受相互间的写入操作和数据复制。设置副本很容易，而且可以替您管理同步。副本使用最后写入器成功策略来聚合为一致状态。

如果您纯粹将全局表作为故障转移或灾难恢复 (DR) 策略的一部分，则可以用一个跨区域备份副本来替换它们，以满足相对宽松的恢复点目标和恢复时间目标要求。如果您不需要快速的本地访问和五个 9 这样的高可用性，则维护全局表副本或许不是故障转移的最佳方法。

作为替代方案，可以考虑使用 AWS Backup 来管理 DynamoDB 备份。您可以采用一种比使用全局表更具成本效益的方法，来安排定期备份和跨区域复制，以满足灾难恢复要求。