本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
评估您的表使用模式
本节概述如何评估您使用 DynamoDB 表是否高效。有些使用模式对于 DynamoDB 来说不是最佳的，在性能和成本方面还有优化的空间。
执行更少的强一致性读取操作
DynamoDB 允许您根据每个请求来配置读取一致性。默认情况下，读取请求为最终一致性的。最终一致性读取的收费标准是 4KB 及以下数据量为 0.5RCU。
大多数分布式工作负载具有灵活性，能够容许最终一致性。但是，也有一些访问模式需要强一致性读取。强一致性读取的收费标准是 4KB 及以下数据量为 1RCU，读取成本基本上翻了一倍。DynamoDB 提供了在同一个表上使用这两种一致性模式的灵活性。
您可以评估一下您的工作负载和应用程序代码，确认是否只在需要时才使用强一致性读取。
执行更少的读取操作事务
DynamoDB 允许您以某种方式对某些操作进行分组，这意味着您可以使用 DynamoDB 执行 ACID 事务。 all-or-nothing 但是，如同在关系数据库中一样，不必让每个操作都遵循此方法。
一个 4KB 及以下数据量的事务型读取操作会占用 2RCU，而以最终一致性方式读取同样数量的数据会占用默认的 0.5RCU。写入操作的成本是翻倍的，这意味着，1KB 及以下数量的事务型写入将占用 2WCU。
要确定表上的所有操作是否都是事务，可以将表格的 CloudWatch 指标向下筛选到事务 API。如果表的 SuccessfulRequestLatency 指标下只剩下事务 API 图，则可以确认，每个操作就是该表的一个事务。或者，如果整体容量利用率趋势与事务 API 趋势一致，请考虑重新审视应用程序设计，因为它似乎被事务 API 所主导。
执行更少的扫描
Scan 操作的广泛使用通常源于对 DynamoDB 数据运行分析查询的需求。在大型表上频繁运行 Scan 操作既效率低下又成本高昂。
更好的替代方法是使用 “导出到 S3” 功能并选择一个时间点将表状态导出到 S3。 Amazon 提供像 Athena 这样的服务，然后可以使用这些服务对数据运行分析查询，而不会消耗表中的任何容量。
Scan 操作的频率可以使用 Scan 的 SuccessfulRequestLatency 指标下的 SampleCount 统计数据来确定。如果 Scan 操作确实非常频繁，则应重新评估访问模式和数据模型。
缩短属性名称
在 DynamoDB 中，一个项目的总大小是其属性名称长度加上值的总和。长的属性名称不仅会增加存储成本，还可能导致 RCU/WCU 占用量增加。建议您选择较短的属性名，而不要选择较长的属性名。短的属性名有助于将项目大小限制在下一个 4KB/1KB 范围内，避免占用额外的 RCU/WCU 来访问数据。
启用存活时间 (TTL)
Time to Live（TTL，存活时间）可以发现超过设定的过期时间的项目，并将它们从表中删除。如果您的数据随着时间的推移而增长，并且较旧的数据变得无关紧要，则在表上启用 TTL 可以帮助减少数据并节省存储成本。
TTL 的另一个用处是，当您的 DynamoDB 流上存在过期的项目时，除了删除它们之外，也可以利用它们，并将其存档到一个成本较低的存储层上。此外，通过 TTL 删除项目无需额外成本，既不占用容量，也不产生设计清理应用程序的开销。
用跨区域备份替换全局表
全局表允许您在不同的区域维护多个活动副本表，这些表都可以接受相互间的写入操作和数据复制。设置副本很容易，而且可以替您管理同步。副本使用最后写入器成功策略来聚合为一致状态。
如果您纯粹将全局表作为故障转移或灾难恢复 (DR) 策略的一部分，则可以用一个跨区域备份副本来替换它们，以满足相对宽松的恢复点目标和恢复时间目标要求。如果您不需要快速的本地访问和五个 9 这样的高可用性，则维护全局表副本或许不是故障转移的最佳方法。
作为替代方案，可以考虑使用 B Amazon ackup 来管理 DynamoDB 备份。您可以采用一种比使用全局表更具成本效益的方法，来安排定期备份和跨区域复制，以满足灾难恢复要求。