评估 DAX 是否适合您的用例
本节说明何时以及为何使用 DAX。使用本指南可以帮助您确定将 DAX 与 DynamoDB 集成是否符合应用程序的工作负载模式、性能要求和数据一致性需求。本指南还介绍了可能不适合使用 DAX 的场景，例如写入密集型工作负载和不经常访问的数据。
何时以及为何选择 DAX
在几种情况下，您可以考虑将 DAX 添加到您的应用程序堆栈中。例如，可以使用 DAX 来减少针对 DynamoDB 的读取请求的总体延迟，或者最大限度减少对表中相同数据的重复读取。下表列出了您可以充分利用 DAX 与 DynamoDB 集成的场景示例：
-
高性能要求
-
低延迟读取 – 如果应用程序要求快速响应（以微秒为单位）以实现最终一致性读取，则应考虑使用 DAX。DAX 还可以显著缩短访问频繁读取数据的响应时间。
-
-
读取密集型工作负载
-
读取密集型应用程序 - 对于读写比率（例如 10:1 或更高）较高的应用程序，DAX 会提高缓存命中率并减少陈旧数据。这将减少对表的读取量。为了避免在应用程序写入量大的情况下从缓存读取陈旧的数据，请确保为缓存设置较低的在 DynamoDB 中使用生存时间（TTL）。
-
缓存常见查询 – 如果您的应用程序经常读取相同的数据（例如电子商务平台上的热门产品），DAX 可以直接从其缓存中处理这些请求。
-
-
突发流量模式
-
更顺畅的表扩展 – DAX 有助于缓解流量突然激增带来的影响。DAX 提供缓冲区来轻松纵向扩展 DynamoDB 表的容量，从而降低读取节流风险。
-
提高了对每个项目的读取吞吐量 – DynamoDB 为每个项目分配单独的分区。但是，当项目达到 3,000 个读取容量单位（RCU）时，分区会开始限制对该项目的读取。DAX 允许您将单个项目的读取量扩展到 3,000 RCU 以上。
-
-
成本优化
-
降低 DynamoDB 成本 – 从 DAX 读取数据可以减少发送到 DynamoDB 表的读取量，从而直接影响成本。缓存命中率较高时，降低的表读取成本可能会超过 DAX 集群成本，从而降低净成本。
-
-
数据一致性要求
-
最终一致性 – DAX 支持最终一致性读取。这使得 DAX 适用于即时一致性并不重要的用例。
-
直写缓存 – 您对 DAX 所进行的写入采用直写方式。一旦 DAX 确认已将项目写入 DynamoDB，它就会将该项目版本保留在项目缓存中。这种直写机制有助于在缓存和数据库之间保持更紧密的数据一致性，但会使用额外的 DAX 集群资源。
-
何时不使用 DAX
虽然 DAX 功能强大，但它并不适用于所有场景。下表举例说明了不适合将 DAX 与 DynamoDB 集成的场景：
-
写入密集型工作负载 – DAX 的主要优势是加快读取速度，但写入操作使用的 DAX 资源多于读取操作。如果您的应用程序主要是写入密集型应用程序，那么 DAX 的优势可能会受到限制。
-
不经常读取数据 – 如果您的应用程序不经常访问数据或访问大量很少重复使用的数据（冷数据），则可能会遇到cache hit ratio低的情况。在这种情况下，维护缓存的开销可能无法抵消性能收益。
-
批量读取或写入 - 如果您的应用程序执行的批量写入操作多于单次写入操作，则应围绕 DAX 执行写入操作。此外，对于批量读取，您应该直接对 DynamoDB 表运行全表扫描。
-
严格的一致性或事务要求 – DAX 将强一致性读取和 TransactGetItem 调用传递给 DynamoDB 表。您应该在 DAX 集群中进行这些读取，以避免使用集群资源。以这种方式读取的项目不会被缓存；因此，通过 DAX 传送此类项目没有任何意义。
-
性能要求适中的简单应用程序 – 对于性能要求适中且可容忍直接 DynamoDB 延迟的应用程序，没必要增加 DAX 带来的复杂性和成本。DynamoDB 本身可以处理高吞吐量并提供个位数的毫秒性能。
-
除了键值访问之外，还需要复杂查询 – DAX 针对键值访问模式进行了优化。如果您的应用程序需要复杂的查询和筛选功能（例如查询和扫描操作），那么 DAX 缓存的优势可能会受到限制。
在这种情况下，可使用 Amazon ElastiCache (Redis OSS) 作为替代方案。ElastiCache (Redis OSS) 支持高级数据结构，例如列表、集合和哈希。它还提供发布/订阅、地理空间索引和脚本编写等功能。
-
合规要求 – DAX 目前不提供与 DynamoDB 相同的合规认证。例如，DAX 尚未获得 SOC 认证。
