数据库模型设计（DynamoDB + RDS 混合架构）

目录

一、总体设计目标与原则

1.冷热分离（Hot/Cold Data Separation）

2.关系数据与事务管理

3.成本与性能平衡

4.可扩展性

二、总体表格分配

三、DynamoDB 表设计详解

1.DeviceTelemetry

2.DeviceEvents

3.Commands

4.DeviceStateCache

四、RDS 模式设计详解

users

tenants

devices

audit_logs

commands_history

五、数据流与同步策略

写入路径

读取路径

异步归档

六、可观测性与安全设计

七、总结与优化方向

适用场景：智能锁系统（ESP32 设备上报 telemetry / event，后端存储业务数据与用户关系）

一、总体设计目标与原则

1.冷热分离（Hot/Cold Data Separation）

智能锁系统的设备数据具有明显的冷热特征：

• 热数据（Hot Data）：实时 telemetry（如电量、锁状态、信号强度）与事件（如开锁、报警）。

• 冷数据（Cold Data）：用户、订单、设备注册信息、审计记录等相对低频访问数据。

策略：

• 高频写入、按时间或设备维度检索的数据 → 存入 DynamoDB。

• 事务性、关系性、分析性的数据 → 存入 RDS（PostgreSQL）。

2.关系数据与事务管理

RDS 主要负责：

• 用户账户体系（Users / Tenants）

• 设备注册与分配（Devices）

• 审计与操作日志（AuditLogs）

• 计费与订单（Billing / Orders）

RDS 优势：

• 支持 SQL 与事务；

• 复杂关联查询（JOIN、聚合分析）；

• 符合 ACID 特性，适合权威数据存储。

3.成本与性能平衡

在 AWS 架构下：

• DynamoDB 按访问频率与读写容量计费，适合高并发。

• RDS 按实例规格与存储计费，适合稳定业务表。

通过 冷热数据分层存储 + TTL 机制，在性能与成本之间取得平衡：

• Telemetry/Event 数据在 DynamoDB 设置 TTL（Time To Live），例如 30 天；

• 归档数据通过 AWS Glue 或 Lambda 定期迁移至 RDS 或 S3。

4.可扩展性

架构设计可支撑 百万级设备接入与并发写入，采用：

• DynamoDB GSI（全局二级索引） 进行多维查询；

• 分区键（PK）+ 排序键（SK） 设计提升查询效率；

• 写入解耦（IoT Core → Lambda → DB） 确保可靠性与弹性扩展。

二、总体表格分配