物联网数据存储架构：从时序数据库到时序+关系型混合存储的选型复盘

物联网数据存储架构：从时序数据库到时序+关系型混合存储的选型复盘

物联网存储的挑战不是"存得下"，而是"查得快"——当你需要在1秒内从万亿条传感器数据中找到某个设备过去7天的所有异常温度点时，存储架构的选择就决定了答案。

一、问题的分层

物联网平台的数据按属性天然分为两类：

这个划分是架构决策的基石。试图用MySQL同时解决两类问题，就是大多数物联网项目性能崩塌的根源。

二、时序数据库的深度对比

我们在同一硬件环境（3节点×32C64G×NVMe SSD）上做了全面的基准测试。

2.1 写入性能

测试数据：1000万设备，每设备每10秒上报1条（10字段），持续1小时 TDengine 3.2: ████████████████████████████████ 12,800,000 points/sec InfluxDB 2.7: ██████████ 3,200,000 points/sec TimescaleDB: ██████ 1,900,000 points/sec ClickHouse: ██████████████████████ 8,500,000 points/sec

2.2 查询延迟对比（10亿条数据规模）

2.3 为什么选择TDengine

5个决定性因素：

1. "一个设备一张表"的存储模型——同一设备的数据物理连续存储，时间范围查询本质上是顺序读，这是8ms延迟的物理基础。
2. 列式存储+两级压缩——delta-of-delta时间戳压缩+类Gorilla浮点压缩，8:1的压缩比是实测数据。
3. 超级表（STable）抽象——既保留了每设备独立存储的优势，又提供了跨设备的聚合查询能力。
4. 内置降采样——滚动窗口聚合不需要再写Flink作业。
5. 极低运维成本——3节点集群即可支撑每天TB级写入，不像ClickHouse需要更多节点。

三、关系型存储的MySQL建模

设备元数据虽然数据量不大，但模型复杂度不低：

-- 产品定义（设备模板） CREATE TABLE product_definition ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_key VARCHAR(64) NOT NULL UNIQUE COMMENT '产品标识', product_name VARCHAR(128) NOT NULL, device_type ENUM('sensor','actuator','gateway','camera') NOT NULL, protocol_type ENUM('mqtt','coap','http','modbus','opcua') NOT NULL, data_format ENUM('json','cbor','binary','protobuf') NOT NULL DEFAULT 'json', -- TSL(Thing Specification Language) - 物模型定义 thing_model JSON NOT NULL COMMENT '属性/服务/事件定义', status TINYINT DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) COMMENT '产品定义表'; -- 设备实例 CREATE TABLE device_instance ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_id VARCHAR(64) NOT NULL UNIQUE COMMENT '设备唯一标识', device_name VARCHAR(128), product_id BIGINT NOT NULL, -- 设备密钥（一机一密） device_secret VARCHAR(128) NOT NULL, -- 激活状态 activation_status ENUM('inactive','active','disabled','deleted') DEFAULT 'inactive', first_online_time DATETIME, last_online_time DATETIME, -- 设备属性（冗余物模型中的关键字段，避免JSON解析） firmware_version VARCHAR(32), ip_address VARCHAR(45), rssi INT COMMENT '信号强度', -- 地理位置 location POINT SRID 4326 COMMENT 'GPS坐标', geo_hash VARCHAR(12) COMMENT 'GeoHash(用于空间查询)', -- 租户/分组 tenant_id BIGINT NOT NULL, group_id BIGINT, -- 标签（JSON，支持动态扩展） tags JSON, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_product (product_id), INDEX idx_tenant (tenant_id), INDEX idx_status (activation_status), SPATIAL INDEX idx_location (location), INDEX idx_geo_hash (geo_hash) ) COMMENT '设备实例表'; -- 设备关系（如：传感器属于某个网关） CREATE TABLE device_relation ( id BIGINT PRIMARY KEY AUTO_INCREMENT, parent_device_id VARCHAR(64) NOT NULL COMMENT '父设备(网关)', child_device_id VARCHAR(64) NOT NULL COMMENT '子设备(传感器)', relation_type ENUM('topology','group','shadow') NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_relation (parent_device_id, child_device_id, relation_type), INDEX idx_child (child_device_id) ) COMMENT '设备拓扑关系表';

四、冷热数据分层存储

这是控制成本的核心策略。不加以分层，时序数据的存储成本会随设备数量线性增长，2年内吃掉所有利润。

@Service public class TieredStorageManager { // 分层策略 private static final Duration HOT_RETENTION = Duration.ofDays(7); // TDengine保留7天 private static final Duration WARM_RETENTION = Duration.ofDays(90); // Parquet保留90天 // >90天自动归档到冷存储（S3 Glacier类型） /** * 每日执行的数据迁移 */ @Scheduled(cron = "0 0 2 * * ?") // 每天凌晨2点 public void migrateData() { // 1. TDengine → Parquet（7天→90天） migrateHotToWarm(); // 2. Parquet → S3 Glacier（90天→永久） migrateWarmToCold(); // 3. 降采样：原始数据 → 聚合摘要 downsampleOldData(); } private void migrateHotToWarm() { // 从TDengine导出第8天数据，写入Parquet String sql = """ SELECT ts, device_id, temperature, humidity, vibration_rms FROM sensor_data WHERE ts >= NOW - 8d AND ts < NOW - 7d """; // 按设备ID分区写入Parquet，每个文件10000行 try (ResultSet rs = tdengineQuery(sql)) { ParquetWriter writer = new ParquetWriter( "/data/warm/date=" + LocalDate.now().minusDays(8) + "/", CompressionCodecName.ZSTD // ZSTD压缩比最好 ); List<SensorRecord> batch = new ArrayList<>(10000); while (rs.next()) { batch.add(mapToRecord(rs)); if (batch.size() >= 10000) { writer.writeBatch(batch); batch.clear(); } } writer.close(); } // 迁移完成后删除TDengine热数据（TDengine RETENTION自动处理） } /** * 降采样策略 * 原始数据10s采样 → 1分钟聚合 → 1小时聚合 → 1天聚合 */ private void downsampleOldData() { // 30天以上数据：从1分钟聚合到1小时粒度 downsampleService.aggregate( sourceTable = "sensor_data_1m", targetTable = "sensor_data_1h", windowDuration = Duration.ofHours(1), aggregations = List.of("AVG", "MIN", "MAX", "STDDEV"), startDate = LocalDate.now().minusDays(90), endDate = LocalDate.now().minusDays(30) ); } }

4.1 查询路由

查询层需要感知数据在哪一层：

@Service public class QueryRouter { public QueryResult query(QueryRequest request) { Instant queryStart = request.getStartTime(); if (queryStart.isAfter(Instant.now().minus(HOT_RETENTION))) { // 全部在热存储：直接查TDengine return tdengineQuery(request); } else if (queryStart.isAfter(Instant.now().minus(WARM_RETENTION))) { // 跨热温存储：并行查询，结果合并 CompletableFuture<QueryResult> hotFuture = CompletableFuture.supplyAsync(() -> tdengineQuery(request.restrictTo(HOT_RETENTION))); CompletableFuture<QueryResult> warmFuture = CompletableFuture.supplyAsync(() -> parquetQuery(request.before(HOT_RETENTION))); return hotFuture.thenCombine(warmFuture, QueryResult::merge).join(); } else { // 涉及冷存储：返回降采样数据 + 提示 QueryResult result = parquetQuery(request); result.setNote("查询范围超过90天，返回降采样数据（1小时粒度）"); return result; } } }

五、总结

物联网数据存储架构的选型核心是"分层"——按数据特性分层、按冷热分层、按粒度分层：

1. 时序数据和元数据必须分离存储。时序数据库（TDengine）处理高频写入和时间范围聚合，MySQL处理设备关系和属性查询。混用MySQL的结果就是写入瓶颈和查询超时。

2. TDengine在当前是物联网时序场景的最优解——8:1的压缩比、"一个设备一张表"的物理模型、毫秒级的单设备查询，这三个指标直接决定了系统的可行性和运营成本。

3. 冷热分层不是可选的优化手段，而是架构设计的必选项。7天热数据（TDengine）+ 90天温数据（Parquet）+ 永久冷数据（S3 Glacier）+ 多级降采样，这套策略让我们的存储成本控制在每月1.2万元，而全量存TDengine的成本是8.6万元。

数据的价值与查询频率正相关，与存储成本负相关——分层的本质是让每一条数据待在它应该在的位置。