DynamoDB：容量模式与计费

可视化演示

动态演示DynamoDB的核心机制，通过基础/核心/应用/扩展四种模式展示关键概念与交互流程。

容量模式总览

刚开店时，阿珍根本不知道每天会来多少客人。她选了“按单付费”：每个客人点一份餐，系统就记一笔钱，没人来的时候一分钱都不用花。客人多就多付，客人少就少付，账单完全跟着流量走——这就是 DynamoDB 的按需模式（on-demand）。另一种是预置模式（provisioned）：提前租好一整队厨师和传菜员，约定“每秒最多出多少菜”，无论有没有客人，工资都照发。

切换到技术语言：DynamoDB 把数据读取比作传菜，把数据写入比作炒菜。按需模式下，AWS 自动保证后厨随时有资源，你只需要为实际消耗的读写请求单位付费；预置模式下，你需要明确设置每秒的读容量（RCU）和写容量（WCU），AWS 按小时向你收“固定租金”。选择哪种模式，最重要的指标是容量利用率——预置容量到底被用掉了多少：

AWS 允许表在两种模式之间切换，但限制每个自然日的切换次数有限（通常不超过两次，以官方最新文档为准）。切换过程不丢数据、不中断服务，只是计费规则变了。按需模式适合流量波动剧烈、难以预测的场景，比如新应用上线、突发营销活动；预置模式适合流量平稳、规律可预测的业务。

阿珍总结：按单付是“随缘经营”，包月是“固定班底”。生意难测时就随缘，摸清客流规律之后再换包月，能省下不少冤枉钱。

按需计费机制

自助餐厅的规则是“一碟菜大小决定价格”。阿珍发现，客人点一条小黄鱼（1KB 的数据）和点一整只烤全羊（50KB 的数据），后厨的辛苦程度完全不同。DynamoDB 也一样，它不看“存储了几条数据”，而看“每条数据有多大、被读写过多少次”。

具体来说，DynamoDB 用两个标准单位来计费：读请求容量单位 RCU（read capacity unit）和写请求容量单位 WCU（write capacity unit）。1 个 WCU 支持每秒写入最多 1KB 数据；1 个 RCU 支持每秒强一致读取最多 4KB 数据（弱一致读可以读 8KB，相当于打了五折）。一个数据项消耗多少个单位，是由它的大小决定的：

按需模式的账单就是所有读请求的 RCU 合计乘以单价（约每百万个 0.25 美元），加上所有写请求的 WCU 合计乘以单价（约每百万个 1.25 美元）。它没有最低消费、没有预留费，一切按实际发生量计费。这也意味着，只要把数据项做小，比如字段精简、避免存超大嵌套文档，就能直接降低每一笔请求的单价。

阿珍觉得按需账单就像水电费：没人住的时候水表不走字，心里踏实；但单价确实比“包年套餐”贵一些。所以它最适合试营业期、流量忽高忽低的阶段。

预置计费机制

客流稳定之后，阿珍改成了“包月雇厨师”：固定雇 60 位厨师和 200 位传菜员，无论下雨打烊还是排队长龙，工资都照发。包月的单价更便宜，但她的账本上从此多了一笔雷打不动的“硬支出”。这就是预置模式：你为表设置每秒的读写容量，AWS 按小时计费，不管实际用了多少。

预置模式的月度成本由两个数字决定：预置的 RCU 数量和预置的 WCU 数量。以写为例，每 WCU 小时约 0.00065 美元，每 RCU 小时约 0.00013 美元，一个月按 730 小时估算。同时，DynamoDB 还允许你把“没来得及用的能力”存起来，最多积攒 300 秒，在突发时一次性借出，这就是突发容量：

一旦超过预置容量，DynamoDB 不会让请求安静地排队，而是直接“请你稍等”——返回节流错误（ProvisionedThroughputExceededException）。客户端必须做指数退避重试，否则订单就会丢失。所以预置容量不是设得越高越好，也不是越低越省，而是要在“够用”和“不浪费”之间找平衡。

阿珍说，包月模式让她养成了“看表炒菜”的习惯：平时压着容量跑，短时爆单靠突发额度硬扛，长期不够就赶紧联系 AWS 加人——否则后厨会礼貌地拒绝上菜。

自动伸缩策略

总是手动调厨师太累，阿珍雇了一位“调度经理”。他时刻盯着大堂的排队人数，客人多了就临时加厨师，客人少了就裁掉几个，让工资账单跟着客流起伏。这位经理在 DynamoDB 里叫自动伸缩（Auto Scaling），它使用的策略叫“目标追踪”。

原理很简单：你告诉系统一个目标利用率（默认 70%），再设定容量上下限。系统持续监控“实际消耗容量 ÷ 当前预置容量”，一旦发现消耗超过目标，就按比例把预置容量往上调；反过来，如果利用率长期偏低，就往下调。扩容的目标值由下面的公式决定：

自动伸缩不是瞬间完成的，它需要若干个评估周期（比如 1 分钟粒度）才能生效。因此它适合应对“缓慢起伏”的稳态波动，扛不住“一秒之内暴涨”的极端尖峰。要想防秒杀，还得多留余量，或者干脆用按需模式。另外，配置自动伸缩还需要在 IAM 里授权，让 DynamoDB 有权限帮你调整吞吐量。

调度经理不是魔术师，数人头、写排班表都需要时间。但有了他，阿珍的工资账单终于第一次跟着客流上下起伏，而不是永远一个样。

分区键设计

厨房里有 100 张桌子，每张桌子就是 DynamoDB 里的一个分区。数据坐哪张桌子，由分区键（partition key）决定。阿珍一开始图省事，用“下单时间”当分区键，结果每晚八点所有订单都挤进第一张桌子，其他桌子空转，传菜员全部堵在过道——这就是典型的热点键问题。

好的分区键要满足两个条件：取值多（高基数），访问均匀。比如用户 ID、订单 ID、设备 ID 都很合适；而时间戳、地区编号这类取值少或分布偏斜的字段，容易让某一两个分区承担绝大部分流量。每个分区还有硬性吞吐上限：最多支持 1000 WCU/s 或 3000 RCU/s，超出就会被节流。一张表需要多少个分区，取决于总吞吐和单分区上限：

除了分区键，DynamoDB 还允许设置排序键（sort key），让同一分区内的数据按某种顺序排列，方便范围查询，例如“同一个用户 ID 下的订单按时间排序”。设计时尽量让访问均匀落到所有分区，写密集场景尤其要避免使用顺序递增的键（如自增 ID、纯时间戳），否则最新数据永远打在最后一个分区上。

阿珍把分区键换成用户 ID 之后，订单像客人均匀落座一样分散到各个包间，每张桌子都热闹但井然有序，厨房的效率一下子提升了好几倍。

与Cassandra对比

隔壁老陈卖了好几年烤肉饭，配方和 DynamoDB 有些像：都是键值/宽列风格的 NoSQL 数据库。但老陈选择自己开摊——他自建了一个叫 Cassandra 的烧烤摊集群。两者的区别，核心在“经营方式”：DynamoDB 是 AWS 全托管，服务器、备份、扩缩容全由平台负责；Cassandra 是自建开源软件，节点、修复、压缩、升级全得自己操心。

一致性模型是两者最重要的差异之一。DynamoDB 默认提供最终一致读，也可以显式请求强一致读；Cassandra 则提供可调一致性，每次读写都可以指定 ONE、QUORUM、ALL 等级别。理解 Cassnadra 的仲裁机制，可以用一个经典不等式：

运维上，DynamoDB 几乎免运维，但会和 AWS 生态深度绑定；Cassandra 可以部署在任何机房、避免厂商锁定，但要自己承担集群故障、数据修复和版本升级的长期成本。选型建议：如果你已经在 AWS 上、追求省心省力，选 DynamoDB；如果必须跨云或私有化部署、需要灵活的自定义查询（如 CQL 宽表聚合），选 Cassandra 更合适。

阿珍最后想明白：两家店卖的都是“烤肉饭”，但一个是点外卖（托管服务），一个是自己开店当老板（自建集群）。没有绝对优劣，只有适不适合自己的经营半径。

选型优化成本

终于到了算总账的时刻。阿珍把一年的账单摊开：按需单价贵但灵活，预置单价便宜但怕闲置。核心判断指标还是那个“利用率”——只要利用率高到一定程度，包月就稳赚。以写请求为例，可以做一个简单的盈亏平衡估算：

优化路径可以总结为四步：第一步，分析访问模式，区分读多写少、高峰低谷；第二步，用 AWS Pricing Calculator 分别估算两种模式的月度成本；第三步，设置 CloudWatch 监控，盯着 ConsumedWriteCapacityUnits 和 ThrottledWriteEvents 这类指标；第四步，稳态高利用率场景采用预置加自动伸缩，波动大场景用按需，长期稳定还能考虑 AWS 的长期用量承诺折扣，最高可省下可观的比例。

阿珍最后把这笔账做成了一张表：不是越便宜的方案越好，而是最贴合客流曲线的方案最好。人少时别养闲厨子，人多时别让客人干等——这就是 DynamoDB 容量模式的经营哲学。

AI 应用场景

Python 演示

import math def item_units(size_kb, mode):    """计算单条数据消耗的容量单位: 读按4KB, 写按1KB向上取整"""    if mode == 'read':        return math.ceil(size_kb / 4.0)    return math.ceil(size_kb / 1.0) def demand(hour):    """模拟一天客流: 晚上8点达到高峰, 清晨最低"""    peak = 0.5 + 0.5 * math.cos(2 * math.pi * (hour - 20) / 24)    writes_per_s = 20 + 80 * peak    reads_per_s = 4 * writes_per_s    return writes_per_s, reads_per_s def hourly_cost(prov_w, prov_r, writes_s, reads_s, size_kb):    """计算某小时两种模式各自的花费以及是否会节流"""    wcu = item_units(size_kb, 'write') * writes_s    rcu = item_units(size_kb, 'read') * reads_s    ondemand = wcu * 3600 * 1.25e-6 + rcu * 3600 * 0.25e-6    provisioned = prov_w * 0.00065 + prov_r * 0.00013    throttled_w = max(0, writes_s - prov_w / item_units(size_kb, 'write'))    throttled_r = max(0, reads_s - prov_r / item_units(size_kb, 'read'))    return ondemand, provisioned, throttled_w + throttled_r def main():    size_kb = 8    prov_w = 600    prov_r = 1600    total_on = 0.0    total_prov = 0.0    print("hour  on-demand  provisioned  throttled/s")    for hour in range(24):        ws, rs = demand(hour)        on, prov, thr = hourly_cost(prov_w, prov_r, ws, rs, size_kb)        total_on += on        total_prov += prov        if hour % 3 == 0:            print("{:2d}   {:8.4f}   {:8.4f}   {:6.1f}".format(hour, on, prov, thr))    print("24h total: on-demand ${:.2f}, provisioned ${:.2f}".format(total_on, total_prov))    print("提示: 把 demand() 改成尖峰流量, 就能看到按需模式的优势") if __name__ == '__main__':    main()

1. return math.ceil(size_kb / 4.0)读取容量按 4KB 向上取整，数据越大消耗的 RCU 越多。
2. return math.ceil(size_kb / 1.0)写入容量按 1KB 向上取整，写入比读取更“贵”，计价粒度更细。
3. writes_per_s = 20 + 80 * peak用余弦函数模拟白天高峰与夜间低谷的流量曲线。
4. wcu = item_units(size_kb, 'write') * writes_s每秒消耗的写容量单位 = 单条数据占用的 WCU × 每秒写入条数。
5. ondemand = wcu * 3600 * 1.25e-6 + rcu * 3600 * 0.25e-6按需费用 = 每秒容量单位 × 3600 秒 × 每百万单位单价。
6. provisioned = prov_w * 0.00065 + prov_r * 0.00013预置费用 = 预置 WCU × 小时单价 + 预置 RCU × 小时单价。
7. throttled_w = max(0, writes_s - prov_w / item_units(size_kb, 'write'))每秒写入条数超过预置能承载的上限时，超出部分会被节流。
8. if hour % 3 == 0:每 3 小时打印一次账单，方便观察早晚高峰的成本差异。

常见误区

面试题