何时该用 DynamoDB（以及何时不该）
对于它所擅长的工作负载，DynamoDB 是一个出色的数据库；对于其余的，它令人沮丧。决定性的问题 不是「它能不能扩展到 web 级？」—— 而是**「我是否提前知道我的访问模式，而且它们是基于键的吗？」** 把这点搞对，DynamoDB 会在任意规模下给你个位数毫秒的读取；搞错了，你就会永远跟它缺乏 join 和 即席查询的事实较劲。
何时该使用 DynamoDB？
当你的访问模式已知、基于键且吞吐量高，并且希望在任意规模下获得可预测的个位数毫秒延迟、无需管理任何服务器时，选择 DynamoDB。如果你需要即席查询、复杂 join 或全数据集分析，或者数据量小且查询形态还在不断变化，则应避开它。
- 在以下情况用 DynamoDB：你的访问模式已知、基于键、且高流量 —— 而你想要在任意规模下都 可预测的延迟，且无服务器要管。
- 在以下情况避开它：你需要即席查询、丰富的 join，或对整个数据集做分析；或者数据量小而查询 形态又不断变化。
- 核心取舍：DynamoDB 要你提前为查询做设计；作为回报，它在你增长时永不变慢。
- 它不是换了套语法的关系型数据库 —— 把它当关系型来建模是痛苦的头号来源。
偏向 DynamoDB 的信号
当下面这些大多成立时，DynamoDB 大放异彩：
- 你提前知道访问模式。 你能列出应用发起的确切查询（「按 id 取一个用户」、「列出某用户的 订单，最新优先」），而且它们不会随意变。DynamoDB 就是围绕这些查询建模的。
- 访问是基于键的。 你按已知的分区键查找项，而不是为任意属性组合做扫描。
- 规模与可预测延迟很重要。 无论表里装的是一千个项还是十亿个项，DynamoDB 都交付 稳定的个位数毫秒 性能。
- 你想要零运维负担。 没有实例、没有故障转移、没有 vacuum —— 它完全托管，并能按需缩容 到零。
- 写入吞吐量高而尖峰。 事件日志、IoT 遥测、会话/购物车状态、排行榜 —— 带有清晰键的、 以追加为主的工作负载。
反对它的信号
在以下情况转向关系型数据库（或搜索/分析引擎）：
- 你的查询是即席的。 分析师按任意列切分数据，或需求每周都变。这时 SQL 的灵活性胜出； DynamoDB 则需要为每个模式建一个新索引。
- 你需要在整个数据集上做真正的 join 和聚合。 报表、商业智能、「按地区按月汇总收入」—— 那是 OLAP/关系型的活儿。
- 数据集小且低流量。 一个安静的管理后台里几千行数据，从 DynamoDB 的规模里得不到好处， 反而失去了 SQL 的便利。
- 你还无法预测访问模式。 早期产品仍在摸索形态？一个你能自由重新查询的关系型 schema 在 模式稳定下来之前更宽容。
在投入前算清成本
DynamoDB 的定价跟随读取、写入和存储 —— 而非实例小时 —— 所以它对尖峰和无服务器工作负载很便宜， 对持续的大量扫描则可能昂贵。在投入之前用 DynamoDB 定价计算器给你真实的读/写组合建模；一个技术上 看似合适的工作负载，在成本上也应该算得过来。
一旦你判定它合适
工作就转向建模了。DynamoDB 奖励那些把表围绕查询来设计的做法 —— 见如何在 DynamoDB 中建模数据和 单表设计——以及明确的 何时不该采用单表设计。
陷阱与下一步
- 别把 DynamoDB 当关系型数据库来建模 —— 在读取时 join 的规范化表，正是它惩罚得最狠的 反模式。
- 别拿它做分析 —— 把它和一个分析存储搭配（或导出到一个），用于报表，而不是去扫描。
- 不确定访问模式？再等等。 在你了解自己的查询之前就采用 DynamoDB，是选了那个唯一要求你 必须先了解查询的数据库。
- 相关： Query 与 Scan 展示了「基于键的访问」究竟为你买到了什么。
想在把应用押上去之前先探索一张 DynamoDB 表吗？下载 DynoTable，直接连到你的数据。