4. Historian数据存储模型
Ignition Tag Historian 并不是把每个标签的每次变化都原样写进一张“大表”，而是围绕时间序列存储设计了一套分层的数据模型。理解这套模型，是后续做历史查询、容量规划、性能调优和跨系统集成的根基。本节从数据表结构、分区策略、时间戳精度、数据压缩与死区设置五个维度，拆解 Historian 的存储机制。
一、核心原理：Historian 的存储分层
Historian 的存储模型可以概括为“元数据 + 分区表 + 数据块”三层结构。元数据层记录标签路径、数据类型、工程单位、死区、压缩模式等配置信息；分区层按时间把数据切分成可独立管理的物理块；数据块层则保存真正的时间戳与数值对。查询时，Historian 先通过元数据定位标签，再根据时间范围裁剪分区，最后在数据块内做时间戳检索。
这种设计的关键在于：写入路径与查询路径分离。写入时数据先进入内存缓冲，按分区键批量落盘；查询时按时间范围做分区裁剪，避免全表扫描。因此，Historian 的性能瓶颈通常不在“数据量大小”，而在“分区粒度是否合理”和“死区设置是否过松或过紧”。
二、数据表结构与分区策略
在 Ignition 中，Historian 的底层通常使用 SQL 数据库（如 PostgreSQL、SQL Server、MySQL）或专用时序存储。以 SQL 数据库为例，核心表包括：
- sqlth_te：标签实体表，记录 Tag ID、路径、数据类型、工程单位、死区、压缩模式等元数据。
- sqlth_partitions：分区表，记录每个分区的起止时间、分区键、存储位置。
- sqlth_1_data / sqlth_2_data：数据块表，按分区键分表存储时间戳、数值和质量码。
- sqlth_1_events：事件表，记录标签配置变更、系统事件等。
分区策略决定了数据如何切分。常见做法是按时间分区（日、周、月）或按标签组分区。时间分区适合查询范围明确、数据量大的场景；标签组分区适合按设备或产线隔离数据的场景。分区粒度过粗会导致单分区过大、查询变慢；粒度过细会导致分区数量膨胀、元数据管理开销上升。
三、时间戳精度与数据压缩
时间戳精度决定了 Historian 能区分的最小时间间隔。Ignition 默认使用毫秒级时间戳，但在实际工程中，需要根据采集频率和查询需求选择合适精度。如果采集频率是 1 秒，毫秒精度足够；如果采集频率是 10 毫秒，则需要更高精度或使用专用时序数据库。
数据压缩是 Historian 控制存储成本的核心手段。Ignition 支持多种压缩模式：
| 压缩模式 | 原理 | 适用场景 | 存储节省 |
|---|---|---|---|
| None | 不压缩，每个变化都存储 | 调试、审计、高精度回放 | 0% |
| Deadband | 仅当数值变化超过死区时存储 | 模拟量、温度、压力等缓变量 | 50%～90% |
| Analog Compression | 基于斜率变化压缩，保留趋势特征 | 连续模拟量、趋势分析 | 60%～95% |
| Discrete | 仅存储状态变化点 | 开关量、报警状态 | 80%～99% |
死区（Deadband）是压缩策略中最关键的参数。它定义了“数值变化多少才值得记录”。死区设置过小，会导致大量冗余数据写入；死区设置过大，会丢失关键趋势细节。例如，温度标签量程 0～100°C，死区设为 0.5°C，意味着温度变化小于 0.5°C 时不记录，这样既能保留趋势，又能大幅减少存储量。
# 典型 Historian 标签配置示例
Tag Path: Plant/Line1/Temperature
Data Type: Float8
Engineering Units: °C
Deadband: 0.5
Compression Mode: Analog Compression
Sample Mode: On Change
Timestamp Precision: Milliseconds
Partition Strategy: Daily
四、案例场景：从配置到查询的完整链路
假设某工厂有 200 个温度标签，采集频率 1 秒，量程 0～150°C，要求保留 1 年数据。如果采用“不压缩”模式，每个标签每天产生 86400 条记录，200 个标签一年约 63 亿条记录，存储成本极高。采用“Analog Compression + 死区 0.5°C”后，实际写入量可能降到原来的 5%～10%，一年约 3～6 亿条记录，存储成本大幅下降，同时趋势查询仍然准确。
查询时，Historian 会根据时间范围自动裁剪分区。例如查询“最近 7 天”的数据，系统只会扫描最近 7 个日分区，而不是全表。这就是分区策略与查询性能的直接关系。
五、误区与复盘
- 死区设为零：认为“不丢数据”就是好，结果存储爆炸、查询变慢。
- 分区粒度过粗：按月分区导致单分区过大，查询时扫描大量无关数据。
- 忽略时间戳精度：高频采集却用秒级精度，导致时间戳重复、排序混乱。
- 压缩模式与标签类型不匹配：开关量用模拟量压缩，导致状态跳变丢失。
复盘时，建议从三个指标入手：写入速率（每秒写入记录数）、查询响应时间（典型查询耗时）、存储增长率（每天新增数据量）。如果写入速率过高，优先检查死区；如果查询响应慢，优先检查分区策略；如果存储增长过快，优先检查压缩模式。三者联动调整，才能让 Historian 在精度、性能和成本之间取得平衡。