时序数据库在工业数据存储中的应用

工业自动化系统产生的数据具有鲜明的特征：数据量巨大、产生频率高且严格依赖时间戳。传统的关系型数据库（如 MySQL、Oracle）在处理每秒数万甚至数十万次的写入请求时，往往会出现延迟甚至宕机。时序数据库（TSDB）专门针对带有时间戳的数据进行优化，能够高效解决工业数据的存储与查询难题。

一、 核心概念：为什么选择时序数据库

在电气自动化领域，传感器每隔几毫秒就会上传一次电压、电流、温度等数值。这类数据被称为“时序数据”。相比传统数据库，时序数据库在数据建模和存储引擎上做了针对性简化，去掉了复杂的事务处理机制，专注于“高速写入”和“按时间范围查询”。

以下对比展示了两种数据库在工业场景下的差异：

二、 架构设计：从设备到数据库

在实施存储方案前，必须理清数据流向。工业现场设备（PLC、仪表）通常使用 Modbus、OPC UA 等协议，时序数据库无法直接识别这些协议，因此需要一个“中间件”层进行协议转换和数据转发。

以下是典型的数据采集存储流程：

分析 上图可知，数据链路分为三个核心环节：

1. 采集：网关负责从设备读取原始数据。
2. 传输：数据被转换为数据库能识别的格式（如 JSON 或 Line Protocol）。
3. 存储：数据库接收数据并落盘。

三、 实施步骤：搭建存储环境

以常用的 InfluxDB 为例，演示如何从零开始构建一个工业数据存储环境。假设我们需要存储一条生产线上的电机温度和转速数据。

1. 规划数据模型

传统数据库需要设计表结构，而时序数据库（如 InfluxDB）采用“指标-标签-字段”模型。

• 指标：数据集的名称，如 motor_status（电机状态）。
• 标签：用于标识数据的来源，通常是不变的元数据，如 line_id（产线编号）、device_id（设备编号）。标签用于快速查询和分组。
• 字段：实际测量的数值，如 temperature（温度）、speed（转速）。字段用于计算和聚合。

设计 数据模型如下：

• Measurement: motor_status
• Tags: line="A01", device="Motor_01"
• Fields: temperature=65.5, speed=1480.0

2. 部署数据库服务

在 Linux 服务器上，执行 以下命令安装并启动 InfluxDB 服务（以 Ubuntu/Debian 为例）：

# 更新软件源
sudo apt-get update
# 安装 InfluxDB
sudo apt-get install influxdb
# 启动服务
sudo systemctl start influxdb
# 设置开机自启
sudo systemctl enable influxdb

3. 创建数据库与保留策略

工业数据通常不需要永久保存，例如高频采集的原始数据可能只需保留 30 天。进入 数据库命令行界面：

influx

在交互式命令行中，执行 以下 SQL 语句创建数据库并设置自动过期策略：

-- 创建名为 factory_db 的数据库
CREATE DATABASE factory_db

-- 创建保留策略，名为 rp_30days，数据保留30天，设为默认策略
CREATE RETENTION POLICY "rp_30days" ON "factory_db" DURATION 30d REPLICATION 1 DEFAULT

4. 写入数据（模拟采集端）

工业网关通常通过 HTTP API 将数据推送到数据库。发送 POST 请求进行数据写入。

假设当前时间为 Unix 时间戳 1672531200，产线 A01 的 Motor_01 设备温度为 75.5 度，转速为 1490 RPM。

构建 写入请求（使用 curl 命令模拟）：

curl -i -XPOST 'http://localhost:8086/write?db=factory_db' --data-binary 'motor_status,line=A01,device=Motor_01 temperature=75.5,speed=1490 1672531200000000000'

解释 关键参数：

• motor_status：指标名称。
• line=A01,device=Motor_01：标签键值对，用逗号分隔。
• temperature=75.5,speed=1490：字段键值对。
• 1672531200000000000：纳秒级时间戳（必须为整数）。

5. 查询与数据降采样

直接存储高频原始数据会占用大量空间，且查询缓慢。工业分析通常关注每分钟的平均值或最大值。使用 聚合函数进行查询。

查询产线 A01 下 Motor_01 设备在过去 1 小时内的平均温度，采样间隔为 10 分钟：

SELECT mean("temperature") 
FROM "motor_status" 
WHERE "line"='A01' AND "device"='Motor_01' AND time > now() - 1h 
GROUP BY time(10m)

在此查询中，mean() 函数 计算 平均值，GROUP BY time(10m) 将数据按 10 分钟的时间窗口进行切片。

四、 存储空间计算与优化

在规划存储容量时，需要根据采集频率和测点数量进行预估。

假设一条生产线有 100 个测点，每个测点每秒采集 1 次数据，每个数据点（包含时间戳和数值）平均占用 16 字节（经压缩后）。

计算每小时的原始数据存储空间（近似值）：

$$ Storage_{hour} = N_{points} \times F_{sample} \times T_{sec} \times S_{byte} $$

$$ Storage_{hour} = 100 \times 1 \times 3600 \times 16 \approx 5.76 \text{ MB} $$

分析 结果显示，单条生产线每小时仅需不到 6MB 空间。若使用传统数据库未压缩存储，空间占用可能扩大 10 倍以上。

执行 以下优化策略进一步降低成本：

1. 启用压缩：确认数据库配置文件中开启了 snappy 或 lz4 压缩算法。
2. 调整精度：对于非关键指标，修改 采集频率从 1 秒改为 10 秒，存储量将减少 90%。
3. 数据降采样：配置 连续查询，将历史数据自动聚合为分钟级或小时级数据，并删除原始高频数据。