1. 时序数据库概述
1.1 时序数据的特点
时序数据（Time Series Data）是按时间顺序记录的系统状态、测量值或事件流。在厂务监控场景中，温度、湿度、压力、电压、流量等传感器每秒都在产生大量带时间戳的数值。时序数据具有以下核心特征：
- 时间戳为主键：每条记录都依赖一个精确的时间标识，数据按时间顺序追加。
- 结构化且稳定：数据模式（metric + tags + timestamp + value）几乎不变，极少更新或删除。
- 高写入吞吐：厂务监控中数千个测点同时上报，写入量可达每秒数十万点。
- 冷热分明：近期数据频繁查询，历史数据逐渐归档，生命周期管理是刚需。
- 聚合与降采样：原始数据保留周期短，长期趋势依赖分钟级、小时级聚合值。
厂务场景示例： 一条典型的时序数据记录包含
timestamp=2025-03-21T14:30:00Z、tag=fab_1_floor_2、field=temperature、value=23.5。每秒可能有 5000 条这样的记录同时写入。
1.2 InfluxDB 在厂务监控中的角色
InfluxDB 是专为时序数据设计的开源数据库，在厂务监控系统中承担 数据中枢 的角色。它连接底层传感器网络与上层监控、分析、告警系统，提供高性能写入、灵活查询和自动数据生命周期管理。
| 厂务监控层级 | 组件/系统 | InfluxDB 角色 |
|---|---|---|
| 数据采集层 | PLC、传感器、边缘网关 | 接收 MQTT/Modbus 数据，通过 Telegraf 写入 |
| 数据存储层 | InfluxDB 集群 | 时序数据持久化、保留策略、降采样 |
| 数据处理层 | Kapacitor / 自定义任务 | 实时告警、异常检测、数据清洗 |
| 数据展示层 | Grafana / 厂务大屏 | 提供 Flux / SQL 查询接口，渲染趋势图 |
厂务监控最佳实践： 使用 Telegraf 作为采集代理，通过 MQTT Consumer 插件订阅传感器主题，批量写入 InfluxDB。单机写入性能可达每秒 50 万点以上（取决于硬件和 schema 设计）。
1.3 时序数据库与传统数据库对比
传统关系型数据库（如 MySQL、PostgreSQL）在设计上并未针对时序数据优化。下表从多个维度对比时序数据库（以 InfluxDB 为例）与传统数据库的差异：
| 对比维度 | 传统数据库（MySQL / PG） | 时序数据库（InfluxDB） |
|---|---|---|
| 数据模型 | 表 + 行 + 列，支持复杂关联 | measurement + tag + field + timestamp，扁平化 |
| 写入模式 | 随机写入，支持事务 ACID | 顺序追加写入，批量提交，无事务开销 |
| 写入性能 | 单机约 1k~10k 行/秒 | 单机可达 500k~1M 点/秒 |
| 存储压缩 | 通用行/页压缩，压缩比 2~4x | 列式压缩 + 差值编码，压缩比 10~30x |
| 查询模式 | 随机点查、复杂 JOIN、事务 | 时间范围扫描、聚合、降采样、窗口函数 |
| 数据生命周期 | 手动分区 + 定时清理脚本 | 自动保留策略（RP） + 连续查询（CQ） |
| 索引结构 | B+Tree / Hash 索引 | TSI（Time Series Index）+ 倒排索引 |
| 典型场景 | 订单、用户、库存、CMS | IoT 监控、运维指标、金融行情、厂务数据 |
常见误区： 不要将传感器数据直接存入 MySQL 并期望获得高性能。厂务场景中每秒数万条写入会迅速耗尽 MySQL 的写入吞吐和磁盘 IO，导致查询延迟飙升。InfluxDB 专为这种高写入、时间范围扫描的场景设计，存储成本可降低 70% 以上。
1.4 厂务场景为什么选择 InfluxDB
厂务监控系统对数据库的核心要求是：高写入吞吐、低成本存储、快速时间范围查询、自动数据生命周期管理。InfluxDB 在以下方面与厂务需求高度匹配：
- 原生时序模型：measurement + tags + fields + timestamp 天然适配传感器数据，无需额外建模。
- 高性能写入管道：批量写入、WAL 预写日志、TSM 列式存储，单机轻松应对 10 万点/秒以上。
- 自动保留策略：可配置数据过期自动删除，无需手动清理历史数据。
- 连续查询与降采样：自动将原始数据聚合为分钟级、小时级数据，降低存储成本。
- 丰富的生态集成：Telegraf 采集、Grafana 可视化、Kapacitor 告警，开箱即用。
厂务案例： 某半导体工厂部署 2000+ 传感器，每秒产生约 8 万条数据。使用 InfluxDB OSS 单节点，配合 Telegraf 批量写入（每批 5000 点），写入延迟稳定在 5ms 以内，存储压缩比达到 18x，原始 10TB 数据压缩后仅占用约 550GB。