DynamoDB月度时间序列计数统计场景表结构设计选型问询

核心业务约束 #

• 单用户最多维护100类月度聚合计数，用来比对订阅计划的额度上限和实际使用量
• 数据留存周期5年，折算下来单用户总数据点为 100类指标 * 5年 * 12月 = 6000个
• 基础能力要求：支持计数器的原子增减、低延迟查询
• 访问特征非常明确：几乎所有写操作都集中在当前自然月的4-5个指标上，不存在跨用户批量查询的需求
• 典型指标样例：

numberOfPosts: Int
numberOfImages: Int
numberOfContacts: Int
// 其余同类型计数指标共100类

初始三类设计方案的问题 #

模式1：单表项存单个用户的全量时间序列数据 #

结构定义：

type TimeSeriesData {
   period: AWSDate
   value: Int
}

type TimeSeries {
   owner_id: ID
   numberOfPosts: [TimeSeriesData]
   numberOfImages: [TimeSeriesData]
   numberOfContacts: [TimeSeriesData]
}

这个方案可以直接排除。单条记录要存储用户5年的所有指标数据，每次修改当月的几个计数，都要读写整条约165KB的条目。按DynamoDB的容量计费规则，单次操作要消耗42个读容量单位（RCU）、166个写容量单位（WCU），成本极高，是所有方案里性价比最差的。

模式2：单表项存单个用户单类指标的全周期数据 #

结构定义：

type TimeSeries {
   key: String # 组合键规则：owner_id.指标名
   owner_id: ID
   name: String
   data: [TimeSeriesData]
}

这个方案比模式1开销小，但问题也很明显：每次更新当月的4-5个指标，就要分别读写4-5条记录，每条记录存储单个指标5年共60个数据点，写入冗余度很高；如果要查询某个用户当月的全量指标使用情况，还需要多次读请求拼接结果，效率不高。

模式3：单表项存单个独立数据点 #

结构定义：

type TimeSeries {
   key: String # 组合键规则：owner_id.周期.指标名
   owner_id: ID
   period: AWSDate
   name: String
   value: Int
}

这个方案逻辑拆分最清晰，也是很多人第一反应会选的结构，但完全不符合当前业务的访问特征。更新当月5个指标需要5次独立GetItem读取当前值、5次独立WriteItem写入新值，就算用批量操作减少请求次数，容量开销也降不下来：单次更新5个指标要消耗5 RCU、5 WCU，完全没利用到DynamoDB单次读写最小按1KB计费的规则，浪费了很多已购买的容量。

最终落地的最优方案 #

采用单用户单周期对应单条表项的设计，结构如下：

type TimeSeries {
   key: String # 组合键规则：owner_id.周期
   owner_id: ID
   period: AWSDate
   attribute1: Int
   attribute2: Int
   attribute3: Int
   // ... 最多扩展到100个指标属性
   attribute100: Int
}

实际收益 #

• 操作效率高：绝大多数写操作只针对当月周期，单次更新只需要1次GetItem、1次PutItem就能完成4-5个指标的修改，调用次数远低于其他方案，还可以直接用DynamoDB的原子更新操作，不需要先读再写，进一步降低延迟。
• 成本极低：单条记录存储单月100个指标时，就算属性名平均长度有15个字符，整条记录大小也不到2KB，单次读写只消耗1 RCU、2 WCU，比模式3的成本低60%，实际测算下来成本只有模式1的1/79。
• 容量利用率高：完全贴合DynamoDB的计费规则，把同周期会一起更新、查询的指标打包在同一条记录里，把单次读写的容量额度用满，没有冗余开销。
• 查询方便：核对用户当月使用量、判断是否超出订阅额度时，只需要一次读请求就能拿到全量指标，不需要多次查询拼接结果。

内容的提问来源于stack exchange，提问作者good1492