# 评估 DAX 是否适合您的用例
<a name="evaluate-dax-suitability"></a>

本节说明何时以及为何使用 DAX。使用本指南可以帮助您确定将 DAX 与 DynamoDB 集成是否符合应用程序的工作负载模式、性能要求和数据一致性需求。本指南还介绍了可能不适合使用 DAX 的场景，例如写入密集型工作负载和不经常访问的数据。

**Topics**
+ [何时以及为何选择 DAX](#choose-dax)
+ [何时不使用 DAX](#dax-unsuitable-scenarios)

## 何时以及为何选择 DAX
<a name="choose-dax"></a>

在几种情况下，您可以考虑将 DAX 添加到您的应用程序堆栈中。例如，可以使用 DAX 来减少针对 DynamoDB 的读取请求的总体延迟，或者最大限度减少对表中相同数据的重复读取。下表列出了您可以充分利用 DAX 与 DynamoDB 集成的场景示例：
+ **高性能要求**
  + **低延迟读取** – 如果应用程序要求快速响应（以微秒为单位）以实现最终一致性读取，则应考虑使用 DAX。DAX 还可以显著缩短访问频繁读取数据的响应时间。
+ **读取密集型工作负载**
  + **读取密集型应用程序** - 对于读写比率（例如 10:1 或更高）较高的应用程序，DAX 会提高缓存命中率并减少陈旧数据。这将减少对表的读取量。为了避免在应用程序写入量大的情况下从缓存读取陈旧的数据，请确保为缓存设置较低的[在 DynamoDB 中使用生存时间（TTL）](TTL.md)。
  + **缓存常见查询** – 如果您的应用程序经常读取相同的数据（例如电子商务平台上的热门产品），DAX 可以直接从其缓存中处理这些请求。
+ **突发流量模式**
  + **更顺畅的表扩展** – DAX 有助于缓解流量突然激增带来的影响。DAX 提供缓冲区来轻松纵向扩展 DynamoDB 表的容量，从而降低读取节流风险。
  + **提高了对每个项目的读取吞吐量** – DynamoDB 为每个项目分配单独的分区。但是，当项目达到 3,000 个读取[容量单位](provisioned-capacity-mode.md#read-write-capacity-units)（RCU）时，分区会开始限制对该项目的读取。DAX 允许您将单个项目的读取量扩展到 3,000 RCU 以上。
+ **成本优化**
  + **降低 DynamoDB 成本** – 从 DAX 读取数据可以减少发送到 DynamoDB 表的读取量，从而直接影响成本。缓存命中率较高时，降低的表读取成本可能会超过 DAX 集群成本，从而降低净成本。
+ **数据一致性要求**
  + **最终一致性** – DAX 支持最终一致性读取。这使得 DAX 适用于即时一致性并不重要的用例。
  + **直写缓存** – 您对 DAX 所进行的写入采用[直写](DAX.consistency.md)方式。一旦 DAX 确认已将项目写入 DynamoDB，它就会将该项目版本保留在项目缓存中。这种直写机制有助于在缓存和数据库之间保持更紧密的数据一致性，但会使用额外的 DAX 集群资源。

## 何时不使用 DAX
<a name="dax-unsuitable-scenarios"></a>

虽然 DAX 功能强大，但它并不适用于所有场景。下表举例说明了不适合将 DAX 与 DynamoDB 集成的场景：
+ **写入密集型工作负载** – DAX 的主要优势是加快读取速度，但写入操作使用的 DAX 资源多于读取操作。如果您的应用程序主要是写入密集型应用程序，那么 DAX 的优势可能会受到限制。
+ **不经常读取数据** – 如果您的应用程序不经常访问数据或访问大量很少重复使用的数据（冷数据），则可能会遇到[cache hit ratio](pres-guide-monitor-dax.md#cachehitratio)低的情况。在这种情况下，维护缓存的开销可能无法抵消性能收益。
+ **批量读取或写入** - 如果您的应用程序执行的批量写入操作多于单次写入操作，则应围绕 DAX 执行写入操作。此外，对于批量读取，您应该直接对 DynamoDB 表运行全表扫描。
+ **严格的一致性或事务要求** – DAX 将强一致性读取和 [TransactGetItem](https://docs.amazonaws.cn/amazondynamodb/latest/APIReference/API_TransactGetItems.html) 调用传递给 DynamoDB 表。您应该在 DAX 集群中进行这些读取，以避免使用集群资源。以这种方式读取的项目不会被缓存；因此，通过 DAX 传送此类项目没有任何意义。
+ **性能要求适中的简单应用程序** – 对于性能要求适中且可容忍直接 DynamoDB 延迟的应用程序，没必要增加 DAX 带来的复杂性和成本。DynamoDB 本身可以处理高吞吐量并提供个位数的毫秒性能。
+ **除了键值访问之外，还需要复杂查询** – DAX 针对键值访问模式进行了优化。如果您的应用程序需要复杂的查询和筛选功能（例如[查询](https://docs.amazonaws.cn/amazondynamodb/latest/APIReference/API_Query.html)和[扫描](https://docs.amazonaws.cn/amazondynamodb/latest/APIReference/API_Scan.html)操作），那么 DAX 缓存的优势可能会受到限制。

  在这种情况下，可使用 [Amazon ElastiCache (Redis OSS)](https://docs.amazonaws.cn/AmazonElastiCache/latest/red-ug/WhatIs.html) 作为替代方案。ElastiCache (Redis OSS) 支持高级数据结构，例如列表、集合和哈希。它还提供发布/订阅、地理空间索引和脚本编写等功能。
+ **合规要求** – DAX 目前不提供与 DynamoDB 相同的合规认证。例如，DAX 尚未获得 SOC 认证。