Amazon DynamoDB
开发人员指南 (API 版本 2012-08-10)
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

利用 DAX 实现内存中加速

Amazon DynamoDB 具有很高的可扩展性和性能。在大多数情况下,DynamoDB 响应时间可在几毫秒内测得。但是,还存在需要以微秒计的响应时间的特定使用案例。对于这些使用案例,DynamoDB 加快器 (DAX) 提供了访问最终一致的数据的最短的响应时间。

DAX 是一项与 DynamoDB 兼容的缓存服务,可让您受益于针对要求苛刻的应用的极高的内存内性能。DAX 可处理三个核心方案:

  1. 作为内存中的缓存,DAX 将最终一致性读取工作量的响应时间缩短了一个数量级 - 从毫秒级缩短到了微秒级。

  2. DAX 通过提供与 Amazon DynamoDB 在 API 上兼容的托管服务降低了运营和应用复杂性,并因此只需要进行最少的功能性更改就能与现有应用程序一起使用。

  3. 对于读取量大或突发式的工作负载,DAX 通过降低过度预置读取容量单位来增加吞吐量和潜在运营成本节省。对于需要针对各个密钥进行重复读取的应用,这尤其有用。

DAX 使用案例

DAX 提供了对 DynamoDB 表中最终一致的数据的访问权限 (延迟以微秒为单位)。一个多可用区 DAX 集群每秒可处理数百万个请求。

DAX 非常适用于:

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

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

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

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

DAX 适用于:

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

  • 不需要读取的微秒响应时间的应用程序,或不需要分载基础表中的重复读取活动的应用程序。

  • 需要进行大量写入或不执行太多读取活动的应用程序。

  • 已在将其他缓存解决方案用于 DynamoDB 并将其自己的客户端逻辑用于使用该缓存解决方案的应用程序。

使用说明

  • 有关 DAX 可用的 AWS 区域的列表,请参阅 http://amazonaws.cn/dynamodb/pricing

  • DAX 支持在 Java、Node.js、.Python 和 .NET 中使用适用于这些编程语言的 AWS 客户端所编写的应用程序。

  • DAX 不支持传输层安全性 (TLS)。

  • DAX 仅适用于 EC2-VPC 平台。(不支持 EC2-Classic 平台。)

  • 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” }

本页内容: