时序库对照

DynamoDB 可存时序数据（PK=设备+时间桶，SK=时间戳），但 不是专用时序引擎。本课对照 TimescaleDB、InfluxDB，明确本站主路径。

学习目标

• 了解 DynamoDB 存时序的常见键设计
• 对照专用时序库的能力边界
• 明确 CodeRoadMap 不以 DynamoDB 作时序主存储

核心内容

DynamoDB 时序键模式

PK = DEVICE#sensor-01#2026-03-01    ← 按日分桶，避免热点
SK = 2026-03-01T10:00:00.000Z       ← ISO 时间排序
attrs: temp, humidity

aws dynamodb query \
  --table-name SensorReadings \
  --key-condition-expression "PK = :pk AND SK BETWEEN :t1 AND :t2" \
  --expression-attribute-values '{
    ":pk": {"S": "DEVICE#sensor-01#2026-03-01"},
    ":t1": {"S": "2026-03-01T09:00:00Z"},
    ":t2": {"S": "2026-03-01T10:00:00Z"}
  }'

TTL 属性可自动过期旧数据，降低存储成本（aws-essentials）。

与专用时序库对比

能力	DynamoDB	TimescaleDB / InfluxDB
聚合 downsampling	应用层/Lambda	内置 continuous aggregate
压缩	无专用算法	高压缩比
查询语言	Query API	SQL / Flux
保留策略	TTL 手动	原生 retention policy
运维	全托管	自建或 Cloud 版

postgresql-essentials + Timescale 扩展适合 SQL 生态内时序；IoT 海量写入常选 InfluxDB。

在本站架构里

课时行为日志（实验）  → MongoDB lesson_logs（[mongodb-essentials](/tracks/mongodb-essentials)）
课程元数据（权威）    → MySQL cf_track（[sql-essentials](/tracks/sql-essentials)）
传感器/监控时序（若需）→ 非主路径；生产可考虑 CloudWatch / 专用 TSDB
DynamoDB              → 高并发键值进度，非时序首选

DynamoDB Streams + Lambda 可做 rollup（分钟→小时聚合），但复杂 analytics 仍导出到 SQL 仓库。

练习

• 设计 SensorReadings 表 PK/SK，说明分桶如何防热点
• 写一条 Query 取某设备最近 1 小时读数
• 200 字说明：监控指标为何不用 DynamoDB 作主存储

小结

DynamoDB 能存时序，专用场景用 TimescaleDB/InfluxDB；本站 cf_track 与日志各有主库。 下一课 DynamoDB vs MySQL 选型。