利用 DynamoDB Accelerator（DAX）实现内存中加速

需要尽可能短的读取响应时间的应用程序。示例包括实时出价、社交游戏和交易应用程序。DAX 为这些使用案例提供快速内存内读取性能。

比其他应用程序更频繁地读取少量项目的应用程序。例如，考虑对某个热门产品进行一日促销的电子商务系统。在销售期间，与所有其他产品相比，对该产品（及其在 DynamoDB 中的数据）的需求将急剧增加。为了消除“热门”键和不均匀流量分布的影响，可以将读取活动转移到一个 DAX 缓存，直到一日促销结束。

不但需要进行大量读取，而且对成本很敏感的应用程序。利用 DynamoDB，可以预置应用程序需要的每秒读取次数。如果读取活动增加，可以增加表的预置读取吞吐量（需额外付费）。或者，也可以将活动从您的应用程序转移到某个 DAX 集群，减少需要另行购买的读取容量单元的数量。

需要针对大量数据进行重复读取的应用程序。此类应用程序可能会从其他应用程序转移数据库资源。例如，长时间运行的区域气候数据分析可能会临时占用 DynamoDB 表中的所有读取容量。这种情况对需要访问相同数据的其他应用程序会产生负面影响。利用 DAX，可以改为对缓存数据进行天气分析。

需要强一致性读取（或无法容忍最终一致性读取）的应用程序。

不需要读取的微秒响应时间的应用程序，或不需要转移基础表中的重复读取活动的应用程序。

写入密集型应用程序。大量写入会导致集群中 DAX 节点间的复制量增加。这会增加资源消耗和出现可用性问题的风险。

无需多次重复读取的应用程序。当缓存命中率超过 90% 时，DAX 的性能最佳。较低的缓存命中率会增加缓存未命中率，从而在 DAX 集群中消耗更多资源。

有关 DAX 可用的 Amazon 区域的列表，请参阅 Amazon DynamoDB 定价。

DAX 支持使用 Go、Java、Node.js、Python 和 .NET 编写的应用程序（通过 Amazon 为这些编程语言提供的客户端）。

DAX 仅适用于 EC2-VPC 平台。

DAX 集群服务角色策略必须允许 dynamodb:DescribeTable 操作才能维护有关 DynamoDB 表的元数据。

DAX 集群维护有关所存储项目的属性名称的元数据。该元数据无限期维护（即使项目已过期或者从缓存中移出）。随着时间的推移，使用不限制数量的属性名称的应用程序会耗尽 DAX 集群中的内存。此限制仅适用于顶级属性名称，不适用于嵌套属性名称。有问题的顶级属性名称的示例包含时间戳、UUID 和会话 ID。

此限制仅适用于属性名称，而不适用于它们的值。类似下面的项目不存在问题。

{
    "Id": 123,
    "Title": "Bicycle 123",
    "CreationDate": "2017-10-24T01:02:03+00:00"
}

但类似下面的项目会存在问题（如果有足够多这样的项，并且它们每个都有不同的时间戳）。

{
    "Id": 123,
    "Title": "Bicycle 123",
    "2017-10-24T01:02:03+00:00": "created"
}