氦检工位每次检测，产出的不是一个"合格/不合格"，而是一条曲线。

充氦、稳定、采样，这段时间里质谱仪每隔一小段时间给一个读数。判定用的是曲线上的某一段，追溯用的是整条曲线。一条线跑一段时间以后，这些曲线会累积成相当大的数据量。

存得不讲究，问题会在三个月后集中出现：查询变慢、磁盘吃紧、想按批次回溯时发现字段没留。

这篇讲三件事：数据长什么样、表怎么设计、查询怎么写才不扫全表。

氦检数据的形状很规整，属于典型的时序数据。

每条记录有一个时间戳，有若干维度用于过滤，有若干测量值随时间变化。

维度大致是这些：产线编号、工位编号、设备编号、盖板规格、批次号、追溯码。测量值大致是：腔体压力、氦分压信号、温度、判定限值、判定结果。

一条曲线上可能有几十到几百个采样点，采样间隔通常在毫秒到几十毫秒量级，具体取决于配方。

数据流的走向是：设备控制层按固定周期采样，攒一小批以后写入数据库，判定逻辑读最近一段做计算，追溯查询按追溯码或批次号回查整条曲线。

时序库通常把列分成两类：tag 建索引但不存值序列，field 存值但不建索引。

这个区分搞反了，性能会差一个量级。

产线、工位、设备、规格、批次、追溯码这几项，属于"要按它过滤"的，放 tag。腔体压力、氦分压、温度这些随时间变化的，放 field。

一个常见的错误是把追溯码当 field。追溯码的基数极高，放进 field 以后，想按码回查就只能扫时间范围，扫完再过滤，越到后期越慢。放进 tag 会撑大索引，但查询能直接命中。

另一个错误是把温度当 tag。温度是连续变化的测量值，当 tag 会让序列数爆炸。

序列数大致等于各 tag 取值的组合数。

产线 10 条、工位每线 4 个、设备每工位 2 台、规格 8 种，这几个组合起来已经是几百。如果再把批次号和追溯码算进去，序列数会迅速涨到百万级。

百万级序列对多数单机时序库来说，写入会开始抖，内存会开始涨。

处理办法有几个方向，按代价排序。

第一是把高基数维度从主表里拆出去。曲线数据只按设备、工位、规格存，追溯码单独建一张轻量的映射表，记录"哪个码对应哪个时间段的哪台设备"。

第二是按批次聚合。批次号本身基数不高，可以留在主表；追溯码不进主表。

第三是靠降采样。原始曲线保留一段时间，之后按分钟级聚合成均值、最大值、最小值、点数四个字段，长期留存用聚合值。

一次检测产生几百个点，如果每个点单独发一次写请求，网络往返的开销会远大于数据本身。一条线满负荷跑，写入端会先撑不住。

做法是把一次检测的整条曲线攒成一个批次，一次写入。

def buffer_points(batch_id, device, points, buf, threshold=2000, max_wait=1.0):
    # points: [(ts, pressure, helium_signal, temperature, limit, verdict), ...]
    for p in points:
        buf.append({
            "measurement": "helium_test",
            "tags": {"line": device.line, "station": device.station,
                     "device": device.id, "cap_spec": device.cap_spec,
                     "batch_no": batch_id},
            "time": p[0],
            "fields": {"chamber_pressure": p[1], "he_signal": p[2],
                       "temperature": p[3], "limit": p[4], "verdict": p[5]},
        })
    if len(buf) >= threshold or elapsed() > max_wait:
        write_batch(buf)
        buf.clear()

批次大小要试。太小没效果，太大则单次失败重传的代价高，而且内存占用随峰值波动。

时序数据最容易出的一类脏数据，是时钟不一致。

设备控制层用自己的系统时间打点，采集网关用自己的时间打点，数据库再按写入时间补一个时间戳。三个时间来源，就会有三种偏差。

表现出来是曲线错位：同一次检测的点，在库里被拆到两个时间窗口，聚合时算出两个不完整的均值。

处理办法是统一时间源。控制层采样时带一个单调递增的采样序号，采集网关按"检测开始时间 + 序号 × 间隔"重建时间戳，并在批次记录里保留原始的检测开始时间。

这样即使网关时钟漂了几秒，同一批点仍然落在同一个窗口里。

写之前先想清楚要查什么。氦检数据的查询大致四种。

第一种是按追溯码查一只盖板的曲线。这是单点查询，要快。

第二种是按批次查一批盖板的判定分布。这是范围聚合，要能下推到存储层。

第三种是按设备查某段时间的读数漂移。这是趋势查询，通常配降采样。

第四种是按限值查边界件。这是过滤查询，用判定结果字段加时间范围。

四种查询里，第一种最容易被忽略。它的特点是"时间未知、码已知"，如果主表按时间分区、码在 field 里，这条查询就只能全表扫。用一个独立的码到时间的映射表，这条查询就变成两次点查。

一个常见做法是把判定规则写成查询里的表达式，比如"信号最大值超过限值的 1.3 倍且持续超过 50 毫秒"。

这样写在原型阶段很快，到后期会变成负担：规则一改，历史数据没法用同一口径重算；不同客户限值不同，查询要拼字符串。

更稳的做法是判定在采集侧完成，把判定结果、判定所用限值、判定算法版本一起落库。查询只做过滤和聚合。

算法版本这一列看着多余，出问题的时候能救命：同一批数据用两个版本算出来结论不同，没有版本号就说不清是哪边的问题。

一个可用的分档是：原始曲线保留一段时间，用于故障复盘和方法验证；分钟级聚合值保留更长时间，用于趋势和漂移分析；判定结果与限值长期保留，用于追溯和审计。

分档的依据不是磁盘价格，而是"哪种问题需要用哪一级数据回答"。追溯一只盖板判过没判过，用判定结果就够；复盘一次批量误判，必须回到原始曲线。

氦检数据不难存，难在存之前想清楚三件事：哪些维度要索引、序列基数怎么控制、查询模式是什么样。

这三件事定下来，选哪个时序库反而是次要问题。

反过来，先把库选好再想数据模型，通常会在半年后重做一次。

氦检漏率曲线的时序存储：怎么存才查得快

网络运营

数据库

物联网

后端

氦检曲线数据存储优化指南：维度放tag、测量值放field，控制序列基数，批量写入，统一时间戳，查询避免全表扫描，并提前规划保留策略。

数据流

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

氦检漏率曲线的时序存储：怎么存才查得快

氦检漏率曲线的时序存储：怎么存才查得快

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐