DynamoDB vs ElastiCache
DynamoDB 和 Amazon ElastiCache 都在 AWS 中存储数据，也都被称作很快，但它们回答的是不同的问题。DynamoDB 是一个全托管、无服务器的系统记录数据库：写入会持久化到磁盘，并在可用区之间复制。用 AWS 自己的话说，ElastiCache 是 "a web service that makes it easy to set up, manage, and scale a distributed in-memory data store or cache environment in the cloud." 对大多数系统来说，有用的比较并不是 DynamoDB 还是 ElastiCache——而是哪种缓存（如果有的话）应该放在 DynamoDB 前面。
你该用 DynamoDB 还是 ElastiCache？
把 DynamoDB 用于你承受不起丢失的数据：可大规模按键读写的持久化项目。把 ElastiCache 用作内存层——缓存、会话状态、限流、排行榜、发布/订阅——微秒级读取比持久性保证更重要。如果你专门要加缓存来加速 DynamoDB，真正的决策是 ElastiCache 还是 DAX（DynamoDB 自带的缓存）；该对比见下文。
DynamoDB vs ElastiCache 速览
| 特性 | DynamoDB | ElastiCache |
|---|---|---|
| 角色 | 持久化的系统记录数据库 | 托管的内存数据存储或缓存 |
| 引擎 | 一个托管引擎（DynamoDB 本身） | Valkey、Memcached 和 Redis OSS |
| 数据模型 | NoSQL 键值和文档；带类型的项目，最大 400 KB | 取决于引擎——Valkey/Redis OSS 上的字符串、哈希、列表、集合、有序集合和流；Memcached 上是简单的键值 |
| 持久性 | 每次写入持久化到磁盘，并在可用区之间复制 | 默认在内存中；基于节点的 Valkey 集群可通过分布式多可用区事务日志启用持久性 |
| 一致性 | 默认最终一致；可按请求获取强一致读取 | 主节点对其自己的键是强一致的；副本读取可能滞后 |
| 访问 | 原生 API（GetItem、Query、Scan、…）加上 PartiQL | 通过缓存端点的引擎命令；没有跨键查询语言 |
| 容量模型 | 磁盘上的存储；随数据量扩展 | 受预置内存限制——无服务器模式由 AWS 为你扩展，基于节点的集群由你自己定规格 |
| 运维模型 | 无服务器；无需预置或打补丁 | 无服务器缓存或基于节点的集群；AWS 管理预置、监控、节点替换和补丁 |
| 典型用途 | 必须存活的记录 | 缓存旁路层、会话存储、限流、队列和发布/订阅 |
何时 DynamoDB 是更好的选择
- 数据必须保留下来。 DynamoDB 默认持久化并复制每次写入。ElastiCache 缓存是内存优先的；持久性需要你在基于节点的 Valkey 集群上启用，而不是默认姿态。
- 你的工作集超过内存。 DynamoDB 成本随存储增长。ElastiCache 容量受你预置的 RAM 或无服务器缓存扩展到的内存限制。
- 你需要强一致读取。 DynamoDB 可按请求提供。数据库前面的缓存在构造上就是与它最终一致的。
- 你想要 AWS 控制平面。 时间点恢复、备份、Streams、IAM 和 Lambda 触发器都是 DynamoDB 表上的配置项。
何时 ElastiCache 是更好的选择
- 你需要微秒级读取。 RAM 中的数据比持久存储更快，无论后面是什么数据库。
- 你需要丰富的内存数据结构。 有序集合、计数器、流和发布/订阅在 Valkey 和 Redis OSS 上是一等公民，在持久化存储中建模它们则是额外工作。
- 数据确实是临时的。 会话、限流窗口和可重新计算的结果适合缓存的生命周期。
- 你缓存的不只是 DynamoDB。 ElastiCache 可以放在任何东西前面——RDS、Aurora、API、搜索索引。DAX 只加速 DynamoDB。
搭配使用
常见的生产形态是两者都有：DynamoDB 保存持久化记录，内存层吸收热读取。ElastiCache 作为通用的缓存旁路层，由你编写代码——应用检查缓存，未命中时回退到 DynamoDB，并在未命中时填充缓存。DynamoDB 也有自己的替代方案 DAX，无需缓存旁路代码即可做到同样的事。
DynamoDB 前面用 ElastiCache 还是 DAX
这是大多数团队真正在做决策的地方，而 AWS 文档比营销页回答得更尖锐。
DAX 即插即用；ElastiCache 需要改代码。 DAX "API-compatible with DynamoDB. Therefore, it requires only minimal functional changes to use with an existing application." 它把最终一致性读取的延迟 "by an order of magnitude from single-digit milliseconds to microseconds." 用 ElastiCache 则要自己编写并维护缓存旁路逻辑，包括失效处理。
AWS 文档列出的四个 DAX 不适配场景。 AWS 列出了 DAX 不 理想的用例，每一条都对应真实工作负载：
- 强一致读取。 DAX 提供最终一致的数据。如果读取路径需要
ConsistentRead，DAX 就不是选项。 - 写入密集型工作负载。 "High volume of writes lead to increased replication across DAX nodes in a cluster," 提高资源占用和可用性风险。
- 重复读取率低。 "DAX performs best when cache hit rates exceed 90%." 低于该阈值，未命中会消耗资源却买不到多少延迟收益。
- 语言支持。 "DAX supports applications written in Go, Java, Node.js, Python, and .NET, using AWS-provided clients." 如果你的服务是 Rust、Ruby、PHP 或 Elixir，DAX 实际上对你关闭，而 ElastiCache——可通过任何 Valkey、Redis OSS 或 Memcached 客户端访问——才是务实选择。这一条比任何延迟基准更常决定问题，而且很容易被忽略。
DAX 还 "only available for the EC2-VPC platform."
建模前值得了解的 DAX 陷阱。 AWS 记录了一个与常见 DynamoDB 建模习惯相冲突的限制：
DAX clusters maintain metadata about the attribute names of items they store. That metadata is maintained indefinitely (even after the item has expired or been evicted from the cache). Applications that use an unbounded number of attribute names can, over time, cause memory exhaustion in the DAX cluster. This limitation applies only to top-level attribute names, not nested attribute names.
对照人们如何构建稀疏或异构项目来读这段话。项目的值是时间戳和 UUID 没问题。把时间戳、会话 ID 或租户 ID 作为顶级属性名——把 map 展平到项目上以保持可查询时会出现的形状——会让 DAX 的元数据永远增长。项目从缓存逐出后，缓存也不会回收这部分空间。
缓解办法是建模层面的，不是配置层面的：把标识符放在属性_值_里，把可变键嵌套在 map 下一层，而该限制明确不适用于嵌套属性名。ElastiCache 没有等效约束，因为它根本不跟踪你的项目 schema。
持久性已不再是清晰的分界线。 说 ElastiCache 不能持久化的常见说法已经过时。AWS 文档写明 "for node-based Valkey clusters, you can enable durability to persist your data in a distributed Multi-AZ transactional log," 并且 "with durability enabled, your data is protected even if all cache nodes fail." 这并不让 ElastiCache 成为系统记录——但意味着你不能不先核对引擎和集群类型就主张"缓存重启就丢一切"。
使用 DynamoDB
无论你在前面放哪种缓存，DynoTable 都是原生桌面客户端，可在 macOS、Windows 和 Linux 上浏览、编辑和查询底下的 DynamoDB 表。它读取你标准的 AWS 凭证链，所以没有什么需要迁移。它的网格会解码 USER#123 这类复合键并标记 TTL 属性，让你能直观看到缓存会被要求持有哪些项目形状——以及哪些顶级属性名。
要构建缓存填充代码所需的键条件和过滤器，免费的 DynamoDB Expression Builder 无需安装即可生成可直接粘贴的 SDK、CLI 和 PartiQL 输出。DynoTable 是一款闭源商业应用；本页描述的是它做什么，而不是它如何构建。
FAQ
ElastiCache 能取代 DynamoDB 吗？
不能作为系统记录。ElastiCache 是内存存储；即使在基于节点的 Valkey 集群上启用了持久性，它也是为缓存层设计的，而不是数据所在的数据库。DynamoDB 默认将每次写入持久化并在可用区之间复制。
DAX 还是 ElastiCache 更适合 DynamoDB？
如果你的应用用 Go、Java、Node.js、Python 或 .NET 编写，读取是最终一致的，且缓存命中率会超过 90%——选 DAX；它兼容 API，几乎不用改代码。如果你需要其他语言、需要缓存 DynamoDB 以外的东西，或想要 DAX 不提供的内存数据结构——选 ElastiCache。
ElastiCache 节点重启会丢数据吗？
默认在内存中，应视为易失。AWS 现在为基于节点的 Valkey 集群提供可选持久性，持久化到分布式多可用区事务日志，即使所有缓存节点失败数据也能存活。你的缓存是否易失取决于你选择的引擎和集群类型。
相关内容
- 了解何时使用 DynamoDB，以及 DynamoDB TTL 如何让类似缓存的项目过期。
- 从通用角度比较 DynamoDB 与 Redis 的存储与缓存问题。
- 用单表设计为持久化访问模式建模。
- 下载 DynoTable 来浏览、查询和编辑你的 DynamoDB 表。
参考资料
- What is Amazon ElastiCache?
- In-memory acceleration with DynamoDB Accelerator (DAX)
- What is Amazon DynamoDB?
- DynamoDB read consistency
2026-08-02 对照官方 AWS ElastiCache 用户指南和 DynamoDB 开发人员指南核验。Valkey、Redis OSS 和 Memcached 是其各自所有者的商标；此处引用仅用于标识目的。