物联网系统中“时序数据库（TSDB）”和“关系型数据库（RDBMS）”
在物联网系统中，将MQTT设备数据分别存储在时序数据库（TSDB）和关系型数据库（RDBMS），主要是基于两者不同的设计特性和适用场景，目的是为了兼顾高性能写入/查询和业务关联分析的需求。以下是具体对比和目的说明：
1. 时序数据库（InfluxDB/TimescaleDB/Prometheus等）
核心目的：高效处理时间序列数据，满足物联网场景下的高频写入和时序查询需求。
适用场景：
- 设备传感器产生的周期性、时间戳严格有序的数据（如温度、湿度、GPS坐标等）。
- 高频写入（每秒数千甚至数百万数据点）。
- 基于时间范围的聚合分析（如“过去24小时的平均温度”）。
优势：
- 写入性能极高：针对时间序列数据优化，压缩率高，写入吞吐量远高于关系型数据库。
- 存储效率高：自动数据降采样（Downsampling），支持TTL（自动过期旧数据）。
- 时序查询优化：内置时间窗口函数（如
GROUP BY time(1h)）、插值、连续查询（CQ）等功能。 - 横向扩展：易于分布式部署（如InfluxDB Cluster）。
示例查询：
-- 查询设备A在过去1小时内的温度平均值（每5分钟一个点）
SELECT mean("temperature") FROM "sensor_data"
WHERE "device_id"='A' AND time > now() - 1h
GROUP BY time(5m)
2. 关系型数据库（MySQL/PostgreSQL等）
核心目的：支持业务逻辑关联查询和事务处理，存储设备元数据、用户信息等结构化数据。
适用场景：
- 设备元数据管理（如设备型号、所属用户、安装位置等）。
- 业务系统关联查询（如“查询设备A的所有者联系方式”）。
- 需要ACID事务的操作（如设备权限变更、用户订阅关系）。
优势：
- 复杂查询能力：支持多表JOIN、子查询、事务等。
- 数据一致性：严格遵循ACID，适合关键业务数据。
- 灵活性：支持动态Schema修改（如新增字段）。
示例查询：
-- 查询设备A的所有者信息（需要关联设备表和用户表）
SELECT u.name, u.phone FROM devices d
JOIN users u ON d.owner_id = u.id
WHERE d.device_id = 'A';
3. 为什么需要同时使用两者？
物联网系统的典型架构中，两类数据库通常协同工作：
- 时序数据库：
- 存储原始传感器数据，支持实时监控和大规模时序分析。
- 例如：存储温度传感器的每秒读数。
- 关系型数据库：
- 存储设备静态信息、用户权限、业务规则等。
- 例如：存储设备所属的客户、保修期、告警阈值等。
协同流程示例：
- 设备通过MQTT上报数据 → 数据同时写入InfluxDB（原始数据）和MySQL（设备状态快照）。
- 前端展示时：
- 实时曲线图从InfluxDB查询时序数据。
- 设备详情页从MySQL查询元数据和用户信息。
4. 对比总结
| 特性 | 时序数据库 | 关系型数据库 |
|---|---|---|
| 数据模型 | 时间序列（时间戳+指标） | 结构化表（行和列） |
| 写入性能 | 极高（百万级/秒） | 中等（万级/秒） |
| 查询优势 | 时间范围聚合、降采样 | 多表关联、复杂条件过滤 |
| 存储成本 | 低（压缩率高，自动过期） | 较高（需手动归档） |
| 典型场景 | 监控、传感器数据分析 | 用户管理、设备元数据 |
5. 实际案例
- 智能家居系统：
- InfluxDB：存储温湿度传感器的实时数据，支持APP中的历史曲线查询。
- PostgreSQL：存储用户账号、设备绑定关系、告警规则。
- 工业物联网：
- TimescaleDB：存储工厂设备的振动频率时序数据，用于预测性维护。
- MySQL：存储设备保养记录、工程师工单信息。
通过这种分工，既能满足物联网场景下的高性能时序数据处理，又能支持业务系统的复杂逻辑。