DynamoDB 按需容量 vs 预置容量

DynamoDB 对吞吐量有两种计费方式。按需（On-Demand）按请求收费——你用多少付多少，可缩容到零。预置（Provisioned）预留一个固定的读/写速率，不管你用不用都要付费，但每单位价格低得多。选错模式是最容易多花钱的方式之一。

审计日志让这个选择变得具体。审计写入是尖峰式且不可预测的：整夜安静，然后某个客户跑了一次批量操作、或某次事故生成了数千条事件时，涌来一波洪流。那种流量形态就是整个决策的关键。

我该用 DynamoDB 按需容量还是预置容量？

按需按请求收费并可缩容到零，因此对于尖峰式、全新或不可预测的流量，它是安全的默认选择。预置以低得多的每单位价格预留一个固定的读/写速率，只有当持续、稳定的流量让那份预留保持高利用率时才占优。除非你的用量已被证明且可预测，否则就选按需。

用预置容量，你要承诺，比如说，每秒 1,000 个写入单位。如果审计日志平均每秒 50 次写入，而你却按事故日的峰值来预置，那你就得全天候为 1,000 付费，实际只用到二十分之一。反过来若按平均值预置，事故日的洪流就会被限流——写入遭到拒绝。

所以固定容量对尖峰式流量强加了一个糟糕的取舍：要么持续多付，要么预置不足、在最要紧的时候丢弃写入。按需的存在正是为了消除这个取舍。

按需只对你实际消耗的读、写请求单位收费，没有容量需要配置——它能即时容纳最高达你此前流量峰值两倍的尖峰，并在空闲时缩容到零。超出短时间窗口内那个 2 倍的跃升，它在爬升期间仍可能限流。你为那份弹性支付每请求的溢价。

预置预留每秒一定数量的读取容量单位（RCU）和写入容量单位（WCU）。每单位价格低得多，但你要为那份预留持续付费，用不用都一样。超出它，DynamoDB 就会限流，除非启用了自动扩缩以在配置的边界内增长容量——不过自动扩缩以分钟为单位反应，所以一个突然的尖峰在它跟上之前仍可能被限流。

分水岭是利用率。粗略地说：如果你持续、可预测的流量让预置容量保持高利用率，预置在价格上胜出；如果流量尖峰化、突发化或未知，按需靠不为闲置预留收费而胜出。

审计日志平均每秒写入约 50 条事件，但在事故期间会突增到数千条，读取流量则低得多（合规导出、偶尔的调查）。每条事件都很小——远不到 1 KB。

在预置模式下，你要么按突发峰值预留（全天候为它付费），要么冒着限流事故日洪流的风险——那是最不该丢弃审计写入的时候。在按需模式下，安静时段几乎不花钱，而最高达近期峰值两倍的突发无需任何配置就被吸收；你只为真正发生的写入付费。

对于这种工作负载，按需是正确的默认选择。一般规则是：任何全新或尖峰式的表都从按需起步，只有当流量被证明足够稳定、能让一份预留保持高利用率时，才转到预置。

代入你自己的数字——每秒读/写、条目大小、存储——就能在单个区域下并排看到两种模式：

按需与预置成本对比

US$209.60/ 月

更便宜

US$69.44/ 月

价格：美国东部（弗吉尼亚北部），强一致读取，不含免费套餐。仅为估算 —— 不含备份与传输。预置模式需要 100 RCU / 100 WCU。

要看应用了免费额度的完整多区域全貌，请用 DynamoDB 定价计算器。

容量决策要从真实数字出发：条目有多大、有多少个、被写入的速度有多快。靠猜这些，正是表最终被错误预置的原因。

要把一条示例事件换算成它实际消耗的 RCU/WCU，把它跑一遍条目大小计算器。然后把决策落在你的真实表上：DynoTable 会呈现它的元数据——条目数量和大小——并让你查看有代表性的条目，好让你准确地估算它们。

切换模式有速率限制，而且不对称。预置切按需在每 24 小时内最多四次；按需切预置不受限。把它当作一个深思熟虑的决定，而不是一个随手拨动的旋钮。
自动扩缩不是即时的。它以分钟为单位反应，所以预置模式下一个陡峭的尖峰可能在容量增长之前就被限流。对于真正突发的流量，按需能更好地应对尖峰——即时最高达你此前峰值的两倍。如果你知道某个尖峰会超出那个范围（一次发布或促销），提前给表设置暖吞吐量（warm throughput）来预先预置突发余量。
热分区不管哪种模式都会限流。即便是按需也有每分区限制——不均匀的键可能在表看起来还没到容量时就限流。参见热分区。
有它们自己的容量。每个索引单独计费，若预置不足还会限流基表写入——参见为什么 GSI 会限流基表写入。

容量模式决定了你在单个区域运行这张表要付多少钱。接下来：用 DynamoDB 全局表把它跨区域复制。

下载 DynoTable，在你决定容量模式之前先读出你表的真实大小和条目数量。