4. 时序数据库概述
在工业数据管道中，设备每秒产生的温度、压力、振动、电流等测点数据，天然带有时间戳，并且以“只追加、极少更新、按时间范围查询”的方式持续增长。传统关系型数据库虽然也能存储这些数据，但当数据量从百万级跃升到百亿级、写入从每秒几十条增长到每秒百万条时，关系型数据库的瓶颈会迅速暴露。时序数据库（Time Series Database，TSDB）正是为这类“时间戳 + 测点值”数据而生的专用数据库。
一、时序数据库的定义与核心特征
时序数据库是一种针对时间序列数据优化的数据库系统。时间序列数据由三要素构成：时间戳、测点标识（如设备编号、传感器名称、标签集合）和数值。它的核心特征包括：
- 高吞吐写入：面向追加写优化，支持每秒数十万到数百万数据点的持续写入。
- 时间分区存储：按时间窗口切分数据块，便于过期数据自动删除和冷热分层。
- 列式压缩：同一测点连续时间戳和数值具有强规律性，压缩率通常可达 5～20 倍。
- 时间范围聚合：内置降采样、滑动窗口、插值、同比环比等时序计算能力。
- 标签索引：通过设备、产线、区域等标签快速过滤测点集合。
二、发展历程：从通用数据库到专用时序引擎
时序数据库的发展大致经历了四个阶段。第一阶段是通用关系库阶段，早期工业系统用 MySQL、Oracle 存储历史数据，通过时间字段建索引，但写入和压缩能力有限。第二阶段是文件与自定义格式阶段，如 CSV、二进制归档文件，成本低但查询和并发能力弱。第三阶段是专用时序数据库兴起阶段，2010 年前后 InfluxDB、OpenTSDB、Graphite 等产品出现，明确提出 tag、field、measurement 等时序模型。第四阶段是云原生与融合阶段，TDengine、TimescaleDB、QuestDB、Apache IoTDB 等产品在分布式、SQL 兼容、流批一体和边缘协同上持续演进。
这一演进背后的驱动力很明确：工业物联网设备数量爆炸、采样频率提高、数据保留周期变长，同时业务要求实时监控、历史回溯和智能分析并存。
三、与传统关系型数据库的对比
理解时序数据库，最有效的方式是与传统关系型数据库做维度化对比。下表从数据模型、写入、查询、压缩、扩展和典型场景六个方面进行对照：
| 对比维度 | 传统关系型数据库 | 时序数据库 |
|---|---|---|
| 数据模型 | 行式表、强 Schema、外键关联 | 时间戳 + 标签 + 字段，弱 Schema 或灵活 Schema |
| 写入模式 | 随机读写、事务频繁 | 顺序追加写、批量写入 |
| 查询语义 | 点查、关联、事务一致性 | 时间范围扫描、降采样、聚合、插值 |
| 压缩能力 | 通用压缩，压缩率有限 | 时间戳差分、数值编码，压缩率高 |
| 扩展方式 | 垂直扩展为主，分库分表复杂 | 水平扩展、分片、副本原生支持 |
| 典型场景 | 订单、用户、财务等事务系统 | 设备监控、能耗分析、趋势预测 |
需要强调的是，时序数据库并不替代关系型数据库。工业系统中常见做法是：关系库保存设备台账、工单、用户权限等事务数据，时序库保存测点历史数据，两者通过设备编号关联。
四、主流产品分类与选型维度
当前主流时序数据库可按架构和定位分为几类：
- 独立时序库：InfluxDB、TDengine、QuestDB，专注时序场景，写入和压缩性能突出。
- 关系库扩展型：TimescaleDB 基于 PostgreSQL 扩展，兼顾 SQL 生态与时序能力。
- 分布式列式型：Apache IoTDB、OpenTSDB + HBase，适合海量测点和集群部署。
- 云托管型：阿里云 TSDB、AWS Timestream、华为云 GaussDB(for Influx)，降低运维成本。
选型时建议从以下维度评估：
- 写入吞吐与延迟：能否支撑当前和未来 3 年的测点规模。
- 查询能力：是否支持 SQL、降采样、窗口聚合、跨设备关联。
- 压缩与存储成本：长期保留历史数据时的单位成本。
- 生态与协议：是否兼容 MQTT、OPC UA、Kafka、Grafana 等工业与可视化工具。
- 部署与运维：边缘轻量部署、集群高可用、备份恢复是否成熟。
- 数据保留与分层：是否支持自动过期、冷热分层、对象存储下沉。
五、典型场景与常见误区
以某汽车零部件工厂为例，车间有 2000 台设备，每台设备 50 个测点，采样周期 1 秒，则每天新增约 86 亿个数据点。若用 MySQL 单表存储，写入和查询都会迅速恶化；改用 TDengine 后，按设备建子表、按天分区，写入稳定在每秒百万点，历史查询通过降采样在秒级返回。这个案例说明，时序数据库的价值不仅是“存得下”，更是“写得快、查得快、压得小”。
常见误区有三个：一是把时序数据库当关系库用，频繁做点更新和复杂关联，导致性能下降；二是忽视标签设计，把高基数、频繁变化的字段作为标签，造成索引膨胀；三是只关注写入性能，忽略查询模式和保留策略，最终存储成本失控。复盘时应回到数据模型：时间戳、标签、字段各司其职，标签用于过滤，字段用于计算，时间用于分区。
-- 典型时序建表思路（以 TDengine 为例）
CREATE DATABASE power KEEP 365 DURATION 10;
CREATE STABLE meters (
ts TIMESTAMP,
current FLOAT,
voltage INT,
phase FLOAT
) TAGS (
device_id NCHAR(32),
group_id INT,
location NCHAR(64)
);
-- 每个设备自动建子表，按时间分区，标签用于过滤
掌握时序数据库的定义、演进、对比和选型维度，是构建工业数据管道的第一块基石。后续的数据采集、存储分层、流式计算和可视化，都将围绕这一存储核心展开。