工业系统的数据建模与信息系统有本质差异。关系型数据库以业务实体（订单、用户、账户）为建模中心，强调实体间的关联关系和事务一致性。工业时序数据以物理设备为建模中心，每个设备持续产生时间序列数据，设备之间通过物理拓扑关联而非外键关联。这种差异决定了时序数据库的数据建模需要一套独立的方法论——不是把关系型模型的表结构搬过来，而是从工业数据的物理特征出发重新设计。
测点元数据：标签与字段的边界
工业测点（Measurement Point）是数据建模的基本单元。一个测点包含两类信息：描述性元数据（设备在哪、是什么、属于哪个产线）和随时间变化的测量值（温度、压力、转速）。在时序数据库的数据模型中，这两类信息分别对应标签（Tag）和字段（Field）。
标签是静态的设备属性。变电站编码、间隔名称、设备编号、测点类型、工程单位——这些属性在设备生命周期内不变化或极少变化。标签值存储在元数据层，不随每条数据重复存储，仅在查询时用于过滤。标签的设计原则是：只选设备固有属性，不选运行时变化属性。
字段是随时间变化的测量数据。遥测值（电压、电流、温度）、遥信状态（开关分合、告警标志）、品质标志——这些数据持续产生，每条数据携带时间戳和字段值。字段值按列式存储，相同字段在时间维度上连续排列，有利于压缩和聚合。
标签与字段的边界划分是建模质量的关键。一个常见的错误是把运行状态做标签。例如把"设备运行/停机"状态做标签，实际上设备状态频繁变化，每变化一次就需要修改标签。标签修改在时序数据库中是重操作——需要更新元数据、重建索引，影响写入性能。正确做法是把设备状态作为字段，每条数据携带当前状态值。
建模维度 | 关系型数据库 | |
建模中心 | 业务实体（订单/用户） | 物理设备（传感器/装置） |
表组织 | 按业务域分表 | 按设备类型分超级表 |
实例区分 | 外键关联 | 标签值区分 |
数据排序 | 无强制排序 | 时间戳强制有序 |
写入模式 | 事务批量写入 | 单设备追加写入 |
查询模式 | JOIN为主 | 标签过滤+时间聚合 |
索引策略 | B+树（多列组合） | 时间分区+标签索引 |
存储格式 | 行式存储 | 列式存储 |
超级表设计原则
超级表（STable）是时序数据库中同类型设备的模板。一张超级表定义了该类设备所有实例共享的表结构——标签列、字段列、时间戳列。每个具体设备实例对应一张子表（Subtable），继承超级表的结构，拥有独立的标签值和数据行。
超级表设计的第一原则是同类设备共用一张超级表。一个工厂有200台温度传感器，型号可能不同（PT100、热电偶K型、热电偶J型），但测量的物理量相同——温度。将所有温度传感器归入一张超级表sensor_temperature，标签中标注型号差异。这样做的好处是：查询"全厂温度"时只需查一张超级表，标签过滤可以按型号、产线、工位细分。
第二原则是标签数量控制在合理范围。标签数过多会增加元数据管理开销和写入时的标签匹配成本。工程实践中，标签数量控制在4-8个为宜。核心标签包括：设备标识（唯一）、所属产线/间隔、设备类型、位置信息。非核心属性（如安装日期、额定参数）放在设备资产管理系统中，不进入标签设计。
第三原则是避免标签值的基数过高。标签基数指标签不同值的数量。设备编号标签的基数等于设备数量——如果设备有10000台，设备编号标签基数就是10000。标签基数过高会膨胀元数据规模，增加标签索引内存占用。对于设备数量超大的场景，应考虑按区域或类型拆分超级表，控制单表标签基数在合理范围。
标签设计反模式
几种常见的标签设计错误会严重损害系统性能。
把高频变化字段做标签。某项目将"当前班次"（早班/中班/夜班）做标签，班次每8小时切换一次。每切换班次，相关设备子表的标签值更新，触发元数据重建。在生产高峰期，班次切换时的标签更新操作导致写入延迟突增。正确做法：班次作为字段，每条数据记录当前班次值。
把唯一性ID做标签但基数过大。某物联网平台将设备序列号（SN）做标签，设备数量500万。标签基数500万意味着超级表下有500万张子表，元数据内存占用数GB，启动加载和标签索引重建耗时显著。对于超大规模设备场景，应按区域分库或分超级表，控制单表子表数量在百万级以内。
标签值使用过长字符串。标签值作为索引键存储和比较，过长字符串增加内存占用和比较开销。某项目标签值使用完整设备描述文本（如"一号生产线主变压器A相绕组上部温度传感器"），实际应使用短编码（如"T1_A_WU"）替代，长描述在资产系统中维护。
子表分片与写入机制
子表是数据的物理载体。每条写入数据通过子表名称路由到对应的物理分片。TDengine的子表写入采用无锁追加模式——每个子表对应一个Vnode内部的独立写入路径，不同子表之间无锁竞争。200台设备同时写入200张子表，互不干扰，写入吞吐随子表数量线性扩展。
这种无锁写入机制是时序数据库相比关系型数据库在工业写入场景的核心优势。关系型数据库的多行并发写入需要锁机制（行锁/表锁）保证一致性，高并发写入时锁争用严重。该模型下单设备写入是追加操作——时间戳严格递增，不修改历史数据——天然无冲突，无需锁。
分片机制在集群层面扩展写入能力。TDengine的Vnode分片将不同子表分布到不同物理节点，写入压力分散到多台机器。分片策略默认按子表名哈希分配，也支持按标签值指定分布。一个1000台设备、每台10Hz采样的系统，写入负载10000点/秒，3节点集群每节点承担约3300点/秒，单节点轻松支撑。
建模实践：电力与工控场景
电力设备建模遵循变电站的物理拓扑。层次结构为：变电站→电压等级→间隔→设备→测点。在超级表设计中，标签包含变电站编码、电压等级（220kV/110kV/35kV）、间隔名称、设备类型，字段包含各测点的遥测值和遥信状态。
以线路保护装置为例。超级表relay_line_protection的标签为：substation_id（变电站编码）、voltage_level（电压等级）、bay_name（间隔名称）、device_id（装置编号）、device_model（装置型号）。字段为：phase_a_current（A相电流）、phase_b_current、phase_c_current、phase_a_voltage、phase_b_voltage、phase_c_voltage、active_power、reactive_power、breaker_status（断路器状态）、protection_flag（保护动作标志）。每个保护装置实例为一张子表，标签值标注该装置的物理位置。
工控设备建模遵循产线的工艺流程。层次结构为：工厂→车间→产线→工位→设备→参数。以CNC加工中心为例，超级表cnc_machining_center的标签为：factory_id、workshop_id、line_id、station_id、device_id、device_model。字段为：spindle_speed（主轴转速）、spindle_load（主轴负载）、feed_rate（进给速度）、axis_x_pos（X轴位置）、axis_y_pos、axis_z_pos、coolant_pressure（冷却液压力）、tool_id（刀具编号）、program_no（程序号）、alarm_code（报警代码）。
两种场景的建模逻辑一致：标签标注设备的空间拓扑归属，字段记录设备的运行参数。差异在于标签的具体维度——电力侧按电压等级和间隔，工控侧按车间和产线——但模型结构是统一的。
结语
工业时序数据建模不是关系型建模的变体，而是一套独立的方法论。核心原则只有一条：以设备为中心组织数据，标签标注固有属性，字段记录变化参数，时间戳提供全局排序基准。超级表+子表的模型结构天然适配工业设备的"同类多实例"特征。建模质量不取决于标签和字段的数量，而取决于标签值是否真正稳定、字段是否覆盖核心测量维度、超级表的划分是否对应设备的物理分类。建模阶段的决策影响写入性能、查询效率和存储成本，是时序数据库落地的第一个关键工程决策点。
