DynamoDB vs Redshift
DynamoDB 和 Amazon Redshift 很少是二选一。DynamoDB 是运营数据库——对已知键的个位数毫秒级读写，服务实时应用流量。Redshift 是 "a fully managed, petabyte-scale data warehouse service in the cloud," 为扫描和聚合大型数据集做报表与分析而构建。同时运行两者的团队才是常态，AWS 也提供了在二者之间单向搬运数据的托管集成。
你该用 DynamoDB 还是 Redshift？
把 DynamoDB 用于应用的实时数据：正在下的订单、正在读的会话、按键取出的记录。把 Redshift 用于需要跨整个数据集提问的场景——按区域和月份的收入、队列留存、连接多个来源的仪表板。"选哪一个"通常归结为"DynamoDB 走写入路径，Redshift 给分析师"，中间是零 ETL 集成。
DynamoDB vs Redshift 速览
| 特性 | DynamoDB | Redshift |
|---|---|---|
| 工作负载 | 运营型（OLTP 风格）——高容量按键读写 | 分析型——扫描和聚合大型数据集 |
| 数据模型 | 无 schema 的 NoSQL 项目，最大 400 KB；每项属性各异 | 关系型表，带声明式列、分布键和排序键 |
| 查询语言 | 原生 API（GetItem、Query、Scan、…）加上 PartiQL | 完整 SQL，以及随之而来的 BI 和 SQL 工具链 |
| 联接与聚合 | 无服务端联接；聚合不是服务端操作 | 联接、窗口函数、GROUP BY 以及分析型 SQL 的其余部分 |
| 访问模式 | 围绕已知键设计；Scan 是昂贵的例外 | 为扫描而设计——读取大量行是常态 |
| 延迟 | 每次请求个位数毫秒 | 每次分析查询数秒到数分钟，覆盖远多数据 |
| 扩展 | 无服务器；分区由 AWS 管理 | 无服务器工作组或预置集群；容量按查询工作负载定规格 |
| 新鲜度 | 按需读你所写 | 取决于加载方式——零 ETL 集成每 15–30 分钟落地更新 |
| 定价模型 | 按请求或预置容量，加存储 | 计算容量加存储；空闲的无服务器仓库不计计算费用 |
何时 DynamoDB 是更好的选择
- 实时应用流量。 对已知键可预测的个位数毫秒读写，任意请求速率。
- 每项 schema 各异。 DynamoDB 一张表里的异构项目很正常；数据仓库需要声明式列。
- 无服务器运维。 没有需要定规格、打补丁或暂停的集群。
- 写入密集型路径。 DynamoDB 以吸收高容量写入为主业；数据仓库为批量加载和读取而优化。
何时 Redshift 是更好的选择
- 跨整张表的问题。 聚合一年的订单本质上是扫描，正是 DynamoDB 要你避免的访问模式，也是 Redshift 为之设计的模式。
- 跨多个来源的联接。 数据仓库做联接。DynamoDB 没有服务端联接。
- BI 工具。 Redshift 通过 JDBC/ODBC 说 SQL，因此能接入现有仪表板和 "the same SQL-based tools and business intelligence applications that you use today."
- 不能打扰生产的分析。 在副本上跑分析，把负载从服务用户的表上挪开。
搭配使用
标准模式是单向的：DynamoDB 服务应用，副本落到 Redshift，分析师在副本上工作。AWS 支持两条路径——较老的 COPY 命令，可直接 "from Amazon S3 or Amazon DynamoDB into Amazon Redshift," 以及托管零 ETL 集成，自行保持副本最新。
零 ETL 集成实际做什么
"Zero-ETL" 听起来像实时视图。它不是，在设计仪表板之前这些细节很重要。
它是定时复制的管道。 AWS 写得很精确："On activation, the integration exports the full DynamoDB table to populate the Amazon Redshift database." 然后 "the zero-ETL integration then incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." 因此 Redshift 中的数据最多滞后半小时。这对日报没问题，对需要反映用户上一动作的任何界面则是错的。
时间点恢复（PITR）是强制前提——原因现在很清楚了。 前提写得很直白："A zero-ETL integration between Amazon DynamoDB and Amazon Redshift requires your source DynamoDB table to have Point-in-time recovery (PITR) enabled." AWS 在一处写要求，在另一处写机制，却没有把它们连起来，但你必须附加的基于资源的策略暴露了真相——它授予 redshift.amazonaws.com 执行 dynamodb:ExportTableToPointInTime 的权限。集成建立在 DynamoDB 导出到 S3 的机械装置上，而该装置从连续备份读取。没有 PITR，就没有导出，也就没有集成。
这有一个人们很晚才碰到的预算后果：在大表上启用 PITR 是按表大小持续收费，为分析管道而非为恢复而承担。把集成定价为"Redshift 加 PITR"，而不是 Redshift 单独——免费的 DynamoDB 定价计算器 能在你承诺之前估算存储侧成本。
两个会卡住现有表的约束。 二者都是文档化的限制，事后修复都很别扭：
- "The DynamoDB table and Amazon Redshift cluster need to be in the same Region." 合并多个区域的数据仓库无法通过这条路径全部拉入。
- "The source DynamoDB table must be encrypted with either an Amazon-owned or Customer-managed AWS KMS key. Amazon managed encryption is not supported for the source DynamoDB table." 在 AWS 托管加密下创建的表需要先改加密设置才能创建集成。
数据形状会在哪里咬你。 DynamoDB 项目按设计就是异构的；数据仓库表有列。在单一分区键约定下存放多种实体类型的单表设计，复制过去不会自动变成干净的星型 schema。数据落地后要在 Redshift 里做建模工作——集成去掉的是管道，不是 schema 设计。
何时你还不需要数据仓库
并非每个聚合都是分析问题。大量"我们应该放进 Redshift"的起点只是一个问题——这个状态有多少项、这位客户的总额是多少、哪些分区键占主导——偶尔由工程师针对一张表提出。
DynoTable 的 SQL Workbench 直接在 DynamoDB 上按需回答这类问题：真正的 SQL，带 COUNT、SUM、AVG、MIN、MAX、GROUP BY、HAVING 和 DISTINCT，以及 INNER/LEFT JOIN。定位刻意收窄——在 DynamoDB 的访问模式规则内的 SQL。它是单个 SELECT；没有 CTE、没有 UNION、没有窗口函数，也没有标量子查询；联接目标必须是分区键或 GSI 分区键。结果流式返回并带部分结果标记，查询跑完后变为精确，读取数据仍然按读取计费。
这不是数据仓库的替代品，上面的限制就是诚实的边界。但它比复制管道、PITR 费用和 schema 设计更快给出答案——并帮你在建仓之前判断这个问题是否值得一个数据仓库。运行 Workbench 查询是付费功能；编辑器和自动补全免费。DynoTable 是一款闭源商业应用；本页描述的是它做什么，而不是它如何构建。
FAQ
Redshift 能取代 DynamoDB 吗？
不能用于应用流量。Redshift 是为扫描和聚合而构建的数据仓库；它不是为高容量按键查找、个位数毫秒延迟而设计的。二者并行运行，DynamoDB 服务应用，Redshift 中的副本服务分析。
Redshift 中的 DynamoDB 数据有多新？
使用零 ETL 集成时，最多大约滞后 30 分钟。AWS 文档写明，初始全量导出后它 "incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." 把它当作近实时报表，而不是实时视图。
为什么零 ETL 集成要求 PITR？
因为它建立在 DynamoDB 的时间点导出上。集成所需的基于资源的策略授予 Amazon Redshift dynamodb:ExportTableToPointInTime 操作，而该导出从 PITR 维护的连续备份读取。因此启用 PITR 是集成真实、持续的成本。
相关内容
- 了解何时使用 DynamoDB，以及为什么 Scan 代价高昂。
- 比较 DynamoDB 与 PostgreSQL 的运营型关系型问题。
- 用单表设计提前建模访问模式。
- 用免费的 DynamoDB 定价计算器 估算存储和容量侧成本。
- 下载 DynoTable 直接查询和聚合你的 DynamoDB 表。
参考资料
- What is Amazon Redshift?
- DynamoDB zero-ETL integration with Amazon Redshift
- Zero-ETL integrations — Amazon Redshift Management Guide
- Point-in-time recovery for DynamoDB
- What is Amazon DynamoDB?
2026-08-02 对照官方 AWS Redshift 管理指南和 DynamoDB 开发人员指南核验。