一、ThingsBoard数据持久化概述
为什么需要数据持久化？
说实话，我刚接触ThingsBoard那会儿，也想过这个问题——数据存着干嘛？实时看看不就行了？
后来在一个工厂项目里吃了大亏。客户要求查看三个月前的温度曲线，我当场就懵了。系统默认的内存存储，重启一次数据就全没了。嗯，从那以后，我再也不敢轻视数据持久化。
数据持久化，说白了就是让数据「活」下来。它解决三个核心问题：
- 数据不丢失——服务器重启、断电、崩溃，数据还在
- 历史可追溯——昨天的告警、上周的指标、上个月的报表，随时能查
- 分析有价值——没有历史数据，机器学习、趋势预测都是空谈
核心观点：ThingsBoard默认的H2内存数据库只适合开发测试。生产环境必须上持久化方案，这是架构底线。
ThingsBoard中的数据流架构
我习惯把ThingsBoard的数据流画成一条「管道」。数据从设备端进来，经过处理，最终落地存储。你想想看，整个过程其实就三步：
- 数据采集层——设备通过MQTT/CoAP/HTTP上报数据
- 数据处理层——规则引擎做过滤、转换、告警判断
- 数据持久化层——把处理后的数据写入数据库
这里有个容易踩的坑。我曾经以为数据到了持久化层才落盘，其实不是。ThingsBoard的规则引擎里，每一步都可能触发持久化操作。比如：
// 规则引擎中的持久化节点示例
{
"name": "保存遥测数据",
"type": "org.thingsboard.rule.engine.telemetry.TbMsgTelemetryNode",
"configuration": {
"defaultTTL": 0, // 0表示永不过期
"useServerTs": false
}
}这个节点一执行，数据就直接写入数据库了。所以数据流不是「先处理再存」，而是「边处理边存」。
持久化层在整体架构中的位置
咱们把ThingsBoard的架构拆开来看。我一般把它分成四层：
| 层级 | 组件 | 职责 |
|---|---|---|
| 接入层 | MQTT Broker、HTTP Server | 接收设备连接和数据 |
| 处理层 | 规则引擎、核心服务 | 数据过滤、转换、告警 |
| 持久化层 | 数据库、缓存 | 数据存储与查询 |
| 展示层 | 仪表板、API | 数据可视化与对外接口 |
持久化层处于中间偏下的位置。它承上启下——上面处理完的数据要存进来，下面展示层要读出去。
我的经验：持久化层是性能瓶颈的高发区。设备量一上来，数据库先扛不住。所以选型和调优特别重要，后面几章我会详细讲。
持久化层到底存什么？
很多人以为ThingsBoard只存遥测数据，其实不止。我列一下主要存储对象：
- 遥测数据——温度、湿度、电压等时序数据，数据量最大
- 属性数据——设备配置、固件版本等，更新频率低
- 告警数据——触发规则后产生的告警记录
- 事件数据——设备上下线、生命周期变更等
- 元数据——租户、客户、设备、仪表板等实体信息
不同类型的存储需求不一样。遥测数据写多读少，属性数据读多写少。你想想看，用同一套方案去处理，肯定出问题。
避坑指南：我曾经在一个项目中把所有数据都塞进关系型数据库。结果遥测数据一多，查询直接超时。后来才明白——时序数据就该用时序数据库，关系型数据库存元数据就够了。
持久化方案的选择思路
ThingsBoard支持多种持久化方案。我个人习惯按场景来选：
- 开发测试——H2内存数据库，开箱即用
- 小规模生产——PostgreSQL + 本地文件存储
- 中大规模生产——PostgreSQL + Cassandra/TimescaleDB
- 超大规模——PostgreSQL + Kafka + 分布式时序数据库
这里有个关键点：ThingsBoard的持久化层是插件化的。你不需要改代码，改配置文件就能切换数据库。这个设计很聪明，降低了迁移成本。
好了，这一章先讲到这里。下一章我会深入分析ThingsBoard支持的几种数据库方案，包括它们的优缺点和适用场景。到时候咱们再细聊。