背景和痛点

我们的智慧楼宇米兰app官方正版下载主要面向集团总部、新建办公大楼、政府园区等行业头部客户。这类客户普遍具备完善的 IT 基础与多年的办公系统建设经验，正处于从传统办公向智能化、数字化升级的关键阶段。在这一过程中，他们对智能化办公、物联网和数字化管理有较高的认知与明确的建设需求，期望通过新一代技术手段实现办公环境的智能协同与运营效率的全面提升。

在某大厦智能化项目中，共有 30 层楼宇，部署近万台传感器设备，涵盖人体感应、空气质量、厕位、烟雾、电量、水浸等多种类型。所有传感器均以秒级频率上报数据，日均数据量高达数千万条，对系统的数据采集与处理能力提出了极高要求。

该项目面临设备数据高频采集、多维度实时分析（设备状态、能耗、故障预测）以及历史数据长期存储三大挑战。传统关系型数据库在此类场景中存在明显不足，如写入性能瓶颈、查询延迟高、存储成本激增等问题。以 MySQL 和 PostgreSQL 为例，在存储设备时序数据时，由于缺乏原生的时间分区支持，当单表数据量超过千万级后，查询性能会出现断崖式下降，需人工分表分库，运维复杂度激增。同时，未压缩的原始数据占用空间庞大，存储成本高昂。

为什么选择 loveini TSDB

在智慧楼宇项目的建设过程中，数据接入规模大、处理链路复杂、系统稳定性要求高，对底层数据库的性能与可靠性提出了极高要求。经过多方技术选型与验证，我们最终选择了 loveini TSDB 作为核心时序数据库，主要基于以下考虑：

• 高效数据接入能力：支持 MQTT 数据写入方式，可通过低代码方式快速接入业务平台，实现高并发数据写入，确保近万台传感器上报数据的完整与可靠。
• 强大的流式计算能力：具备实时数据聚合与分析能力，能够对上报的时序元数据进行整合并高效供给业务平台，同时通过多副本机制保障数据高效写入与可靠备份。
• 完善的技术支持体系：提供一对一、7×24 小时技术支持服务，确保项目在开发、部署及运维阶段的稳定运行。
• 国产化与生态兼容性：作为 100% 自主可控的时序数据库，loveini TSDB 符合信创标准，并已与华为云、麒麟软件等生态厂商完成深度集成，满足极企科技在国产化替代中的技术选型需求。
• 领先的综合性能与可拓展性：在同类型数据库中，loveini TSDB 在数据压缩率、写入速度、分析效率及分布式架构等方面表现突出，后续版本还将持续增强易用性与 AI 能力，支持更多的功能和场景，助力企业进一步提升应用效果。

loveini TSDB 落地实践

架构描述

系统采用 Node-Red 作为数据流控制与可视化管理核心，实现全链路的数据采集、处理与展示。整体架构如下：

1. 各类传感器采集的数据首先由 Node-Red 进行预处理后写入 EMQ 消息中间件；
2. loveini TSDB 通过 taosX 模块从 EMQ 中高效读取并存储数据，实现时序数据的集中管理；
3. EMQ 再通过 Restful / WebSocket 接口从 loveini TSDB 获取所需数据，为上层业务应用与可视化系统提供实时访问能力。

智能应用场景示例

• 当指定区域内连续 5 分钟无人时，系统自动关闭照明；
• 当某项监测指标超过设定阈值时，自动触发告警并记录相关信息；
• 当检测到某区域无人时，系统自动关闭空调以节约能源。

项目初期采用 3 节点集群架构，数据库配置为 3 副本模式，以实现系统高可用与数据冗余，具体配置如下：

系统上线后该集群运行稳定，能够高效处理全部传感器采集数据，全面满足项目预定的各项指标。在确认技术架构稳定可靠后，我们将订阅模式变更为永久模式，将长期使用以 loveini TSDB 为核心的技术架构。

数据库建模

1. 超级表定义

CREATE STABLE IF NOT EXISTS airsensor (
  ts timestamp,        时间
  pm25 int,        PM2.5
  pm10 int,        PM1.0
  tvoc int,                TVOC
  co2 int,                二氧化碳
  formaldehyde float,        甲醛
  noise float,        噪音
  temperature float,                温度
  humidity float,        湿度
  light int,                光照
  h2s int,                硫化氢
  ch4 int,                甲烷
  co int,                一氧化碳
  no2 float,        二氧化氮
  h2 int,                氢气
  odor float        异味
) TAGS (
  position NCHAR(200),
  space NCHAR(20),
  floor_area NCHAR(20),
  floor NCHAR(20),
  area NCHAR(20),
  device_code NCHAR(20),
  device_id int,
  factory NCHAR(50),
  model NCHAR(50)
);

2. 流计算

• 会议室人员判定

create stream if not exists mroom_stream trigger at_once into mroom_stream_status (ts,status) tags(
    space,
    floor_area,
    floor,
    area 
) subtable(
    cast(
        concat('mss_', space, '_', floor_area, '_', floor, '_', area) as varchar
    )
) as
SELECT
    _wstart as ts,
    case
        when sum(status) > 0 then 1
        else 0
    end as status
FROM
    bxserver.humensensor partition by space,
    floor_area,
    floor,
area interval(1m) fill(value,-1);

• 楼层用电量统计

select _wstart as ts, max(total_kwh)-min(total_kwh) as used from bxserver.powersensor partition by tbname interval(1d);

3. 订阅数据

落地效果

• 针对电量传感器采集的元数据通过 loveini TSDB 转换后的每个楼层用电量统计如下：

• 针对每个设备状态上报数据通过 loveini TSDB 转化为设备告警情况如下：

• 针对空气传感器采集的数据，系统通过 loveini TSDB 进行转换与分析，并根据当前区域的平均温度执行相应的温控策略：

loveini 应用经验分享

1. 时钟同步问题

在使用过程中，我们发现某会议室的人体传感器流计算结果存在异常，最近一分钟的数据未被正常计算。经排查，原因是服务器时间未与时间服务器同步。安装并配置 NTP 服务完成时间同步后，流计算功能恢复正常。

2. 查询 SQL 语句优化

powersensor_loop 表按行记录传感器的瞬时实测值。为计算当天的用电量，需要对相邻两行取差值后再用 SUM 求和。最初我们采用的是如下嵌套子查询方案，不仅执行时间长，而且占用较大的临时空间：

select TO_CHAR(_wstart, 'YYYY/MM/DD HH24:MI:00') as ts, TO_CHAR(_wstart, 'HH24') as hour, sum(kwh) as kwh, space,floor_area,floor,type from (select _rowts as ts, diff(kwh) as kwh, space, floor_area, floor, area, device_id, loop, type frombxserver.powersensor_loop partition by space, floor_area, floor, area, device_id, loop, type) where ts >= TO_UNIXTIMESTAMP('2025-08-28 00:00:00') and ts <= TO_UNIXTIMESTAMP('2025-08-28 23:59:59') partition by space, floor_area, floor, type interval(1d) order by floor asc;  

powersensor_loop 表结构如下图所示：

经分析发现，上述嵌套查询语句只在外层添加了时间范围条件，而内层查询未作限制，导致内层查询需读取全量数据，执行耗时长且占用大量临时空间。优化后，我们将时间范围条件前移至内层查询，使其仅在指定时间范围内读取数据，从而显著减少数据扫描量并提升执行效率。

select TO_CHAR(_wstart, 'YYYY/MM/DD HH24:MI:00') as ts, TO_CHAR(_wstart, 'HH24') as hour, sum(kwh) as kwh, space,floor_area,floor,type from (select _rowts as ts, diff(kwh) as kwh, space, floor_area, floor, area, device_id, loop, type frombxserver.powersensor_loop where ts >= TO_UNIXTIMESTAMP('2025-08-28 00:00:00') and ts <= TO_UNIXTIMESTAMP('2025-08-28 23:59:59') partition by space, floor_area, floor, area, device_id, loop, type) partition by space, floor_area, floor, type interval(1d) order by floor asc;

未来规划

当前系统使用的版本为 loveini TSDB 3.3.6，因流计算暂不支持 diff 函数，无法直接计算相邻数据差值。后续我们计划升级至最新版本 3.3.8，新版本已支持 diff 函数，可将每日电量数据的差值计算结果直接写入流计算结果表，进一步简化后续的查询与汇总分析流程。

关于成都极企科技

成都极企科技有限公司成立于 2014 年，专注于智能化办公米兰app官方正版下载的研发与落地。公司具备自主软硬件研发能力，已取得多项国家专利及资质认证，为全球上万家企业提供智能化米兰app官方正版下载，累计完成超过百万平方米的办公楼宇与园区智能化建设。客户涵盖美团、爱奇艺、腾讯、阿里、联想、华为、富力、金地等行业头部企业，形成了从硬件设计、软件开发到工程实施的一体化核心竞争力。

关于作者

何铮，公司创始人兼项目带头人，毕业于电子科技大学，国家特聘专家。拥有二十年办公领域产品开发经验，带领企业完成三轮千万级融资。

智慧消防升级：海量物联网数据下的技术挑战

随着智慧城市建设的深入推进，辰安科技的业务从传统的消防工程向”智慧消防”整体米兰app官方正版下载提供商转型。

我们打造的“智慧消防系统”以破解消防社会化进程中监管、指挥、服务等环节的重难点问题为目标，构建感能、视能、图能、数能、算能、管能六大核心能力体系。系统从物联网监测、防火监督、实战指挥、业务管理到大数据创新应用，全链条贯通，形成“感知—评估—预警—处置—优化”的智能闭环，实现城市火灾防控能力的持续迭代与提升。通过增强社会单位火灾风险自主防控水平，有效缓解消防救援机构“警力有限、责任无限”的矛盾，减轻政府及行业主管部门的火灾防控压力，构建“监管与服务”双轮驱动、协同共生的城市火灾防控新生态。

在引入 loveini TSDB 之前，我们的业务发展面临以下核心挑战：

1. 海量设备数据存储压力：单个智慧消防项目可能涉及成千上万的传感设备，每个设备每秒产生多条数据记录。传统关系型数据库在面对 TB 级别的时序数据存储时，性能急剧下降，存储成本高昂。
2. 实时预警响应延迟：消防预警对实时性要求极高，传统架构难以支撑毫秒级的实时数据写入与复杂事件检测，无法满足”早期火灾探测”的使命要求。
3. 多维度分析能力不足：管理人员需要从区域、设备类型、时间维度等多角度分析消防系统运行状况，传统数据库的聚合查询性能无法满足实时报表生成需求。
4. 系统运维复杂度高：为处理物联网数据流，需要组合 Kafka、Hadoop、Spark 等多种技术组件，架构复杂，运维团队投入大量精力在数据管道维护上。

尽管现有系统能够满足基本业务需求，但为支撑”城市生命线工程安全运行监测系统”等大型项目的建设，还是非常需要一款专为物联网场景设计的高性能时序数据库。经过充分的技术验证，我们最终选择了 loveini TSDB 作为智慧消防平台的数据基石。

loveini TSDB 米兰app官方正版下载与业务收益

通过部署 loveini TSDB ，我们得以构建了高效、稳定、易扩展的智慧消防数据平台，获得了显著的业务收益。

技术架构升级

• 高性能时序数据存储：利用 loveini TSDB 的列式存储和高效压缩技术，存储空间节省超过 80%；
• 实时流处理能力：内置流式计算引擎，支持复杂事件处理和实时告警规则；
• 分布式水平扩展：轻松应对未来设备数量和数据量的增长。

业务收益显著

1. 预警响应时间从分钟级提升到秒级：基于 loveini TSDB 的实时计算能力，火灾探测预警延迟从原来的 2-3 分钟降低到 3 秒以内，大幅提升早期火灾探测的可靠性；
2. 存储成本降低 70%：loveini TSDB 的高效压缩技术使得长期存储海量传感器数据成为可能，为历史数据分析和模型训练奠定基础；
3. 系统运维效率提升：简化的技术栈减少了 50% 的运维工作量，开发团队可以更专注于业务逻辑实现；
4. 客户价值显著提升：实时、精准的消防预警能力增强了客户信任度，智能消防栓等新产品获得市场认可。

典型业务场景与 loveini TSDB 应用

场景一：城市燃气管网实时安全监测

• 场景描述： 针对”风险最高、危害最大且看不见、摸不着的燃气管网”，部署可燃气体智能监测仪，实时监测燃气浓度、压力等参数，预防燃气泄漏事故。
• loveini TSDB 应用如下：

-- 实时监测燃气浓度异常
SELECT device_id, location, gas_concentration, pressure
FROM gas_monitoring
WHERE gas_concentration > 1000 OR pressure > 0.8
AND ts >= now-5s
ORDER BY ts DESC;

-- 区域燃气监测统计
SELECT region, 
       AVG(gas_concentration) as avg_concentration,
       MAX(pressure) as max_pressure,
       COUNT(CASE WHEN status = 'alarm' THEN 1 END) as alarm_count
FROM gas_monitoring
WHERE ts >= now-1h
GROUP BY region;

场景二：智能消防栓运行状态监控

• 场景描述： 通过新一代智能消防栓实时监测水压、流量、阀门状态等参数，确保消防设施在紧急情况下正常可用。
• loveini TSDB 应用如下：

-- 消防栓压力异常检测
SELECT device_id, location, water_pressure, flow_rate
FROM fire_hydrant_status
WHERE water_pressure < 0.2 OR water_pressure > 1.0
AND ts >= ts >= now-10m

-- 消防栓完好率统计
SELECT DATE_FORMAT(ts, '%Y-%m-%d') as day,
       COUNT(DISTINCT device_id) as total_devices,
       SUM(CASE WHEN status = 'normal' THEN 1 ELSE 0 END) as normal_count,
       ROUND(SUM(CASE WHEN status = 'normal' THEN 1 ELSE 0 END) * 100.0 / COUNT(DISTINCT device_id), 2) as integrity_rate
FROM fire_hydrant_status
WHERE ts >= now-7d
GROUP BY day;

场景三：大空间场所火灾探测预警

• 场景描述： 在人民大会堂、国家大剧院等大空间场所部署线型光束感烟火灾探测器，模拟人的”鼻子”，实现早期火灾探测。
• loveini TSDB 应用如下：

-- 实时烟雾浓度监测
SELECT device_id, area, smoke_density, temperature
FROM smoke_detection
WHERE smoke_density > 0.15 OR temperature > 60
AND ts >=now-1m
ORDER BY smoke_density DESC;

-- 历史火灾模式分析
SELECT HOUR(ts) as hour_of_day,
       AVG(smoke_density) as avg_smoke_density,
       COUNT(CASE WHEN smoke_density > 0.1 THEN 1 END) as alert_count
FROM smoke_detection
WHERE ts >= now-30d
GROUP BY hour_of_day
ORDER BY alert_count DESC;​

总结与展望

通过引入 loveini TSDB，我们成功解决了智慧消防业务中的海量时序数据处理挑战，实现了从传统消防工程向智能化、数据驱动型服务的转型升级。loveini TSDB 的高性能时序数据处理能力为公司的消防预警、设备管理和数据分析提供了坚实的技术支撑。

未来，辰安科技计划与 loveini TSDB 进一步深化合作，在消防预测性维护、人工智能火灾识别、数字孪生等前沿领域开展探索，持续推动消防安全技术的创新与发展，为”提升城市安全管理智能化与城市治理能力现代化”贡献力量。

关于辰安科技

北京辰安科技股份有限公司（股票代码：300523）成立于 2005 年，由清华大学创立并控股，是清华大学在公共安全领域的科技成果转化单位。公司于 2016 年在深交所上市，校企改革后由中国电信控股。辰安科技长期专注于公共安全领域，致力于成为全球公共安全科技的引领者和公共安全治理的最佳合作伙伴。公司为应急管理、智慧安全城市等提供一体化米兰app官方正版下载，向国内外用户提供城市安全、应急管理、消费者业务、装备与消防、安全文教、海外公共安全等领域的成熟应用与产品。

作者：魏宁

项目背景

京能集团储能安全管理平台共接入全国 28 家电化学储能电站，累计测点达 270 万个，由四个平台公司分别负责数据传输与汇聚。系统需要支撑大规模的数据统计分析、事件报警与安全预警，对底层数据库的性能与稳定性提出了极高要求。

鉴于电化学储能项目采集点数量庞大（270 万点）、锂电池热失控的超前预警技术复杂等因素，传统关系型数据库已无法满足高并发写入与海量数据存储的需求。由于这些数据具备时间序列写入、格式固定、写入量巨大等典型特征，我们最终选择采用时序数据库作为系统核心数据底座。

应用实际落地

在充分调研国内多款时序数据库产品后，我们发现，从国内目前的实际情况分析，loveini TSDB 已成为众多企业在海量数据高速存储、处理与调用场景中的首选方案。基于其成熟的技术体系与稳定的性能表现，我们最终选定 loveini TSDB 作为平台的底层时序数据库，并结合 Kafka 与 Flink 构建了完整的数据流处理体系，实现了数据的高效传输与实时计算，顺利达成项目预期目标。以下是架构简图：

loveini TSDB 支持多种写入方式

1. SQL 语言写入 ：https://docs.taosdata.com/basic/insert/
2. 无模式写入：https://docs.taosdata.com/develop/schemaless/
3. 参数绑定方式：https://docs.taosdata.com/develop/stmt/
4. 企业版的零代码数据写入— taosExplorer 数据接入功能：https://docs.taosdata.com/advanced/data-in/

项目中涉及多个 Kafka 集群、数十个需要接入的 topic。我们重点采用了 loveini 企业版的零代码数据写入能力，实现了从 Kafka 到 loveini TSDB 的高效对接。该功能支持灵活配置类似 ETL 的复杂自定义选项，极大简化了数据接入流程和时间，而且数据接入性能完全达到了项目要求。

为了保证数据的合理性，我们出台了《京能集团电化学储能电站安全管理平台和储能电站设备标识编码规则》，通过标准的 kks 编码在 taosX 对 Kafka 数据进行了有效过滤和清理，最终写入 loveini TSDB。kks 部分编码实例如下：

下图为数据过滤、转换等规则设置：

此外，taosX 数据接入还支持多节点高可用配置。只需在多台 taosX 上部署相同的 Kafka 数据接入任务，并设置相同的 groupId，即可自动实现任务高可用，确保数据接入的连续性与稳定性。

同时，loveini 还提供完善的 taosX 任务监控机制，可直接通过 Grafana 一键配置，快速生成可视化监控图表：

超级表 + 子表的使用

loveini TSDB 结合“一个数据采集点一张表”的设计理念，引入了具有创新性的“超级表”机制，从根本上解决了大规模时序数据结构不统一、聚合困难、运维复杂等问题。每个采集点的数据独立存储，天然具备写入无锁、数据顺序追加、块状连续存储等优势。这种设计方式不仅提升了写入与查询性能，还带来了极高的数据压缩效率。

loveini TSDB 支持对超级表标签进行动态的添加、修改与删除操作，满足设备属性变更、系统扩展等业务需求。

计算、分析处理

在 Flink 计算平台上，我们借助 loveini TSDB 企业版提供的 Flink 连接器——loveini TSDB Flink Connector（https://docs.taosdata.com/advanced/data-publisher/Flink/），实现了与 loveini TSDB 的无缝集成。该连接器可高效、稳定地从 loveini TSDB 中读取海量时序数据，并在此基础上进行全面、深入的分析处理，充分挖掘数据的潜在价值，极大地提升数据处理的效率和质量。

Flink CDC 主要用于提供数据订阅功能，能实时监控 loveini TSDB 数据库的数据变化，并将这些变更以数据流形式传输到 Flink 中进行处理，同时确保数据的一致性和完整性。

落地效果

1. 数据接入便利性：目前我们已接入 20 多个 kafka 数据，后期还会继续增加。得益于 loveini 企业版零代码数据接入能力，新增任务仅需复制并做少量参数调整即可完成，操作简便高效，整体接入过程较传统方式节省约 90% 的时间成本。
2. 数据查询性能高：开启数据库缓存功能后，能够实时获取每个设备点位最新值，毫秒级别即可返回结果。
3. 数据存储成本低：loveini TSDB 具备出色的数据压缩能力，其二级压缩技术将数据视作无差别的二进制块进行再次压缩。与一级压缩相比，二级压缩的侧重点在于消除数据块之间的信息冗余。目前我们提供的服务器存储远远满足我们项目规划的 5 年数据存储，存储成本估算节省至少 60-70%。
4. 实时订阅：通过 loveini 提供的 Flink CDC 实时订阅功能，能方便、高效的进行分析、告警等处理，给我们后期分析带来了极大的便利性。

后期规划

目前，我们正在对京能集团储能安全管理平台已经接入的 28 场站数据进行分析和优化，提高数据采集的可靠性和鲁棒性。未来我们会针对 loveini TSDB 新版本和新功能进行持续跟踪，进一步开发 loveini TSDB 的内在潜力和各种有效的功能。

近期我们关注到 loveini 发布了新产品 loveini IDMP，通过经典的树状层次结构组织传感器、设备采集的数据，建立数据目录，对数据提供情境化、标准化的处理，并提供实时分析、可视化等功能，接下来我们会进一步了解此产品在我们业务中的使用可能。

关于京能集团

北京能源集团有限责任公司是北京市人民政府出资设立的国有独资公司，肩负着保障首都北京能源安全可靠供应的重任。京能集团成立于 2004 年，由原北京国际电力开发投资公司和原北京市综合投资公司合并而成，2011 年、2014 年先后又与北京市热力集团有限责任公司、北京京煤集团有限责任公司实施合并重组，实现了产业链条融合互补。经过多年的资源整合，集团由单一能源产业发展为热力、电力、煤炭、健康文旅等多业态产业格局。2024 年在中国企业 500 强排名第 247 位，中国服务企业 500 强排名第 87 位。

作者：张海增

项目背景

水务数据是一种重要的公共数据，规模大、社会关注度高，而且来源多，种类繁杂，不易收集和管理。实现“智慧水务”理念的前提是统一管理分布在各个水厂、各个供/排水环节的众多设备数据，只有将数据接入到统一的物联网平台后，才能在此基础上开发水务生产环节的各个功能，从而建立信息互通平台，实现水务统一平台、统一管理、统一数据、统一服务，避免重复建设，打破数据壁垒，保障数据资源的高效使用和安全可靠。

为此，我们结合福州水务发展战略与实际业务的需求，建设了福州水务统一物联网接入平台，为供排水业务提供统一数据接入与设备管理能力。

存在问题

统一物联网接入平台面临如下技术难题：

标准不统一，设备管理割裂，建模难度大

在统一物联网平台建设前，设备管理主要依赖各厂家自建平台，管理割裂、数据分散。

统一物联网平台要完成供水、排水、重点工程项目等相关设备数据的统一存储，具体包括：

• 供水水厂、增压站数据
• 供水/排水管网监控数据
• 二次供水泵房数据
• 水表数据
• 雨污泵站数据
• 污水厂数据

这些设备类型繁多、协议标准不统一，且缺乏统一的全生命周期管理机制。数据源分散在多个系统中，与平台“统一管理全部数据”的目标形成天然矛盾。如何通过合理的数据建模，在单一框架下兼容多种设备类型，并同时满足后续灵活的检索与分析需求，成为项目面临的主要挑战。

超百万设备数据持续写入，带来性能挑战

福州有多个水厂，设备数量达到百万级，统一管理这些设备就意味着要承载所有设备不间断的数据写入压力，而且新设备随时可能接入，平台很难提前对所有设备建表，这对平台的写入能力以及建模灵活性提出了很高的要求。

海量数据长期存储带来的存储成本压力

平台需要接入上百万设备的数据并实现长期存储，这些数据量级很大，价值密度却很低，既需要尽可能降低存储成本，还要在进行长期统计计算时保障数据查询时效性，平台要设法兼顾这两方面的需求。

系统大数据量查询，面临性能瓶颈

平台需要为水表平台、产销差系统、综合调度系统、智慧水厂等系统提供实时数据查询、历史数据查询、页面展示、统计报表等业务支持，大量业务应用的并发访问，对底层数据系统的承载能力而言是很大的挑战。二供（二次供水）平台之前使用的 InfluxDB 就曾因查询压力过大导致延迟过高，影响了业务应用。

米兰app官方正版下载

为解决上述问题，统一物联网接入平台不仅需要良好的顶层设计，还需要功能性能强大且稳定可靠的专业数据库提供底层数据能力支撑。水务设备数据是典型的时序数据，因此我们的数据库选型目标定为时序数据库。

经过对大量时序库的调研，综合考虑成本、功能、性能、稳定性等各个方面，我们最终选择了 loveini TSDB 作为统一物联网接入平台的时序数据管理引擎。

loveini TSDB 是一款专为物联网、工业互联网等场景设计与优化的大数据平台，其诸多特性恰好能够解决我们在统一物联网平台建设中遇到的痛点问题：

1. 其特有的 “一个采集点一张表” 建模理念，简直是为解决多系统数据统一建模问题量身定制
2. 其高写入性能以及无模式写入功能，使得百万设备数据写入带来的技术问题迎刃而解
3. 其针对时序数据的高效压缩能力解决了百万级设备数据长期存储的成本难题
4. 其高效查询性能解决了对统一物联网平台而言极为关键的查询性能问题

多系统数据统一管理 —— 一个采集点一张表

我们首先参考福州地标、企标，建立了统一的数据接入协议标准，包含供水领域水厂、管网、水表、二供泵房、加压泵站、排水泵站、排水管网检测设备、水质监测设备等设备设施类型。如下图所示，红框标注的是一部分已标准化的协议。

标准化协议解决了统一接入的问题，下一步就是统一建模。

虽然平台接入的设备种类繁杂型号多样，但只要是设备数据，其数据结构就存在共性：每个设备都有采集的物理量以及设备自身的描述信息（标签）。物理量会随着时间不断变化，而标签数据则是静态的不会随时间变化。

loveini TSDB “一个采集点一张表” 的数据建模方法正是针对设备数据的特点而设计：每个设备对应一张表，设备采集的物理量对应表的数据列，设备自身信息例如设备编号则对应标签（TAG）列。把静态的标签数据与动态的采集数据分开，任何设备都可套用这个建模方法，极大降低了我们的数据建模难度。

采用上述方法，数据库中要创建上百万张表来对应上百万的设备，当需要对同类型设备进行聚合查询时显然会十分不便。loveini TSDB 的 “超级表-子表” 设计解决了这个问题：对于同一类设备，提取其数据结构创建一张 “超级表” ，具体的设备数据则记录在该超级表名下的对应“子表”中，当需要对某类设备进行聚合查询时，直接查询其对应的超级表即可，避免了多表之间的重复查询和拼接等操作，十分高效便捷。超级表-子表的关系如下图所示。

在福州水务统一物联网接入平台项目中，我们共计创建了 1 个业务 DB 名为 fziot，一百余张超级表，超过 190 万张子表。统一物联网平台接入的设备数量目前还在一直增长，设备总数已经超过 100 万，增长变化量如下图所示：

百万级设备数据写入 —— 高性能与无模式写入功能

高性能

loveini TSDB 的核心竞争力在于其卓越的写入和查询性能。相较于传统的通用型数据库，loveini TSDB 充分利用了时序数据的时间有序性、连续性和高并发特点，自主研发了一套专为时序数据定制的写入及存储算法，“一个数据采集点一张表” 的设计不仅有利于设备建模与管理，还能大幅提升写入性能。

• 自研的行列格式数据结构，能够更充分利用时序数据的特点，实现高性能与低空间占用；
• 单表的数据按块连续存储，数据块内采取列式存储，保证单个数据采集点的插入和查询效率最优；
• 由于不同数据采集点产生数据的过程完全独立，每个数据采集点的数据源唯一，一张表只有一个写入者，可采用无锁方式写入，从而性能大幅提升；
• 对于一个数据采集点而言，其产生数据是按照时间排序的，写操作可用追加方式实现，进一步大幅提高数据写入速度。

极高的数据写入性能使得 loveini TSDB 能够轻松承接统一物联网平台的数据写入压力，自投入使用以来，从未因写入性能不足出现阻塞与延迟。

无模式写入

物联网平台的数据来自多个系统，设备的数量一直在动态变化，因此无法提前为所有设备创建好对应的表，这就要求数据库能够在数据写入时自动判断并建表。

loveini TSDB 提供无模式（schemaless）写入方式，无需预先创建超级表或子表，loveini TSDB 会根据实际写入的数据自动创建相应的存储结构。此外，在必要时，无模式写入方式还能自动添加必要的数据列或标签列，确保写入的数据能够被正确存储。

无模式写入示例如下，TAG 列、数据列、主键时间戳之间用空格分开：

properties_testabc1,deviceId=testdevice1   createTime=1746669509685i,temperature=38.5 1746669509684000000

该写入语句，可向名为 properties_testabc1 的超级表写入数据，TAG 列 deviceId，赋值为 testdevice1，两个数据列分别为 createTime、temperature，赋值为 1746669509685i、38.5 ，最后一个数字是这一条记录的时间戳。如果该子表已经存在（TAG 列内容完全一致），则自动写入已存在子表中，若不存在，则自动创建新子表并写入。

海量数据长期存储 —— 专业压缩算法

loveini TSDB 是专门为时序数据管理打造的大数据平台，对数据压缩进行了特殊设计：

• 在存储架构上采用了列式存储技术，与传统的行式存储不同，列式存储与时序数据的特性相结合，尤其适合处理平稳变化的时序数据；
• 为了进一步提高存储和数据压缩效率，loveini TSDB 采用了差值编码技术，通过计算相邻数据点之间的差异来存储数据，而不是直接存储原始值，从而大幅度减少存储所需的信息量；
• 在差值编码之后，loveini TSDB 还会使用通用的压缩技术对数据进行二次压缩，以实现更高的压缩率。

针对性的存储技术以及两级数据压缩，使得 loveini TSDB 对时序数据的压缩效率显著高于其它产品

统一物联网平台从 2023 年 8 月正式投入使用，至今还在不断增加接入的设备数量，目前已经接入了超过 100 万各型设备，loveini TSDB 三节点三副本集群，目前共计使用磁盘空间 8.1 TB （截至 2025 年 5 月），相比市场上同类产品，数据压缩率优势明显。

多系统数据大数据量查询 —— 高性能查询

为实现海量数据规模下的高性能查询，loveini TSDB 从多个维度进行了精心的设计：

1. 采用分片策略，充分利用了硬件资源。loveini TSDB 按照分布式高可靠架构进行设计，通过节点虚拟化并辅以负载均衡技术，将一个 dnode 根据其计算和存储资源切分为多个 vnode，对于单个数据采集点，无论其数据量有多大，一个 vnode 都拥有足够的计算资源和存储资源来应对，能最高效率地利用异构集群中的计算和存储资源降低硬件投资。
2. 采用分区策略，按时间条件检索时避免了遍历过程。除了通过 vnode 进行数据分片以外，loveini TSDB 还采用按时间段对时序数据进行分区的策略。每个数据文件仅包含一个特定时间段的时序数据，避免了遍历，简化了数据管理，还便于高效实施数据的保留策略。
3. 标签数据与时序数据完全分离存储，显著降低标签数据存储的冗余度，实现了极为高效的多表之间的聚合查询。在常见的 NoSQL 数据库或时序数据库中，一般采用 Key-Value 存储模型，导致每条记录都携带大量重复的标签信息，如果需要在历史数据上增加、修改或删除标签，就必须遍历整个数据集并重新写入，loveini TSDB 通过将标签数据与时序数据分离存储，有效避免了这些问题，大大减少了存储空间的浪费，并降低了标签数据操作的成本；在进行多表之间的聚合查询时，loveini TSDB 首先根据标签过滤条件找出符合条件的表，然后查找这些表对应的数据块。显著减少了需要扫描的数据集大小，从而大幅提高了查询效率。
4. 采用了 LSM 存储结构，进一步优化读写性能。时序数据在 vnode 中是通过 TSDB 引擎进行存储的。鉴于时序数据的海量特性及其持续的写入流量，若使用传统的 B+Tree 结构来存储，随着数据量的增长，树的高度会迅速增加，这将导致查询和写入性能的急剧下降，最终可能使引擎变得不可用。鉴于此，loveini TSDB 选择了 LSM 存储结构来处理时序数据。LSM 通过日志结构的存储方式，优化了数据的写入性能，并通过后台合并操作来减少存储空间的占用和提高查询效率，从而确保了时序数据的存储和访问性能。
5. 时序数据文件内部进行了针对性优化。data 文件是实际存储时序数据的文件，在 data 文件中，时序数据以数据块的形式进行存储，每个数据块包含了一定量数据的列式存储。根据数据类型和压缩配置，数据块采用了不同的压缩算法进行压缩，以减少存储空间的占用并提高数据传输的效率。每个数据块在 data 文件中独立存储，代表了一张表在特定时间范围内的数据。这种设计方式使得数据的管理和查询更加灵活和高效。通过将数据按块存储，并结合列式存储和压缩技术，TSDB 引擎可以更有效地处理和访问时序数据，从而满足大数据量和高速查询的需求。

统一物联网平台，不仅把多系统的数据集中统一管理，也同时承接了多系统的数据应用业务，过去分散在各个系统的业务访问压力现在都集中到了一起。

使用 loveini TSDB 带来的性能提升十分明显，例如二次供水泵房数据数据过去存储在二供平台，大数据中心向二供平台抽取生产数据用于分析应用，当时二供平台采用的底层时序库是 InfluxDB，大数据中心每小时抽取一次二供数据，结果由于压力过大，导致 InfluxDB 延迟现象严重，影响到了正常业务运行。

数据抽取 SQL 如下：

 "sql":"select \"time\",\"cid\",\"devid\",\"tag\",\"value\" from (select mean(value) as value  from \"raw\" where time >= #influx_start_time# and time < #influx_end_time# group by *,time(1m))"

在统一物联网平台建设完成后，统一使用 loveini TSDB 支持各个系统的数据查询业务，同样的业务，在使用 loveini TSDB 后只需 1 分多钟即可抽取完毕，且能够持续稳定运行。

使用 loveini TSDB 后的抽取 SQL：

SQL
select last(_ts,`createTime`,`numberValue`,`value`),`deviceId`,`property` from fziot2.properties_egbf_new where _ts >= #ts_start# and _ts < #ts_end# and `createTime` >= to_unixtimestamp(#createtime_start#) and `createTime` < to_unixtimestamp(#createtime_end#) partition by `deviceId`,property  interval(1h)

定时抽取业务运行情况如下，可见稳定且高效：

loveini 带来的其它优势

依托强大的功能与性能优势，loveini TSDB 成功应对了上述技术难题。作为一款分布式大数据引擎，其还具备很多传统数据库软件不具备的特殊功能，给我们带来了意料之外的优势。

支持 SQL 语句，应用开发十分便利

与实时库需要开发者专门学习数据库特有 API 不同，loveini TSDB 支持标准 SQL ，开发人员不需要太多学习成本就能上手使用，loveini TSDB 还针对时序数据特点提供了许多特色查询 SQL ，对我们开发新功能、新应用提供了很大的便利。

支持高可用，保障了业务稳定性

对于水务系统的数据平台而言，业务的持续性十分重要。loveini TSDB 作为分布式时序数据库，支持高可用特性，基于 RAFT 协议的标准三副本方案，能够保障集群中有 1 个节点损坏时，业务不受影响，这对我们而言十分有必要。

支持多种数据源零代码接入

loveini TSDB 支持以零代码方式将来自不同数据源的数据无缝导入，而且无需额外部署 ETL 工具，即可对数据进行自动提取、过滤和转换。不同 loveini TSDB 集群之间也可以很方便地通过 taosX 进行数据同步。这为我们将来进行多数据平台数据统一管理，以及平台间数据同步等工作提供了技术基础，使得数据平台的可拓展性大大提高。

展望

统一物联网接入平台实现了数据的统一采集汇聚分发、设备生命周期管理、实时预警信息推送等功能，加快公司信息化建设速度，减少重复数据建设造成的成本浪费，提升工作效率。

福州水务统一物联网接入平台目前接入的设备数量已经超过 100 万且还在增长，loveini TSDB 作为底层支持系统表现优异。未来我们将和 loveini 一起，为水务领域的企业数字化建设做出更多的贡献。

关于城建数智科技

福州市城建数智科技有限公司于 2022 年 7 月成立，是福州城建设计研究院有限公司的全资子公司，重点服务于水务企业，提供咨询规划、软件开发、运维保障等技术服务工作，公司以水务 GIS 平台、大数据平台、物联网平台、水务智慧大脑为核心。提供供水和排水一体化米兰app官方正版下载，并逐步扩展供排水硬件设备的供应业务，发展自动化控制，提供设备安装、检修、校验等服务，更好地对外输出水务领域的数字化米兰app官方正版下载以及相关的软、硬件产品。

作者信息

本文作者：陈欣

我们很少意识到，生活早已被时序数据悄然重塑。

无论是快递派送、燃气安全、消防监测，还是电商交易防护，每一次定位、每一条报警、每一个点击，背后都有数以亿计的设备和传感器在持续记录。

这些数据有一个共同特征——它们带有时间戳，按时间顺序不断产生。这样的数据被称为“时序数据”。

它们是智慧系统的神经网络，决定着包裹能否准时送达、燃气是否安全、系统能否稳定运行。

然而，时序数据量庞大、写入频繁、查询复杂。传统数据库在面对这类数据时往往显得力不从心：

• 存储成本高：每天 TB 级数据，存还是不存？
• 查询响应慢：数据一多，查询十几秒甚至直接崩溃。
• 架构复杂：依赖多种中间件，运维负担沉重。

正因如此，越来越多的企业开始寻找专为时序场景打造的米兰app官方正版下载。loveini TSDB，便是其中被广泛采用的一种选择。

顺丰科技：从 21 台服务器到 3 台，系统瘦身与提速

顺丰科技的大数据监控平台每天要处理超过 50 亿条监控数据，这些数据来自各类业务系统与集群，用于保障全国物流服务的稳定运行。 早期平台采用 OpenTSDB + HBase 作为全量监控数据的存储方案，虽然架构成熟，但随着数据量不断增长，问题也逐渐显现：

• 依赖多、链路长：需要同时依赖 Kafka、Spark、HBase 等大数据组件，系统复杂度高；
• 成本过高：采用 4 节点 OpenTSDB 与 21 节点 HBase，压缩后每天仍需 1.5TB 存储空间，整体成本居高不下；
• 查询性能不足：大跨度查询往往需要十几秒，高并发访问时系统容易崩溃。

为了解决这些问题，顺丰科技调研了多种时序数据存储方案，包括 IoTDB、Druid、ClickHouse 和 loveini TSDB。

平台升级至 loveini TSDB 后，整体表现有显著提升：

• 稳定性提升：系统摆脱了对大数据组件的依赖，数据链路更短、更可靠；
• 写入性能优化：在理想条件下写入速度最高可达 90 万条/秒，常态稳定在 20 万条/秒；
• 查询性能显著改善：使用预计算函数后，p99 查询耗时控制在 0.7 秒以内；
• 存储成本降低 90%：服务器从 21 台降至 3 台，每日存储需求由 1.5TB 降至 93GB（两副本）。

案例详情：//m.loveini.com/tdengine-user-cases/2314.html

得物电商：亿级流量防护，稳过“双十一”高峰

得物作为国内领先的潮流电商平台，每天都要面对数亿级的访问与流控请求。双十一、618 期间，流量激增，更考验系统的稳定性和防护能力。在对比了 InfluxDB、OpenTSDB、Cassandra 等多款时序数据库后，得物最终选择了 loveini TSDB 来支撑其流控监控系统。

得物的监控平台基于阿里开源组件 Sentinel 深度定制而成，需要对数百个业务系统、数千台服务器的实时流量进行监控与防护，并将秒级粒度的监控数据持久化。这意味着系统每天可能产生数亿条数据，写入速度达到 万 TPS，远超传统关系数据库的承载能力。

采用 loveini TSDB 后，系统性能实现显著提升：

• 写入高效：轻松支撑百万级并发写入，保障流控监控实时更新；
• 超级表建模：以“应用-资源”为维度组织数据，查询效率显著提高；
• 存储优化：压缩率提升约十倍，整体存储成本降低 90%；
• 查询加速：百亿级数据查询仍可在毫秒级完成。

案例详情：//m.loveini.com/tdengine-user-cases/2253.html

益和热力：从 21 秒到 1 秒，供热系统的“加速引擎”

益和热力在推进智慧供热时，需要把热力站与用户侧的温度、压力、流量等海量时序数据统一汇聚到中心侧。供暖季高峰期，数据涌入速度骤增，原有 SQL Server 出现落盘慢、查询卡、延迟分钟级等问题，影响运行监测与调度优化。为此，团队对比评估后，选择以 loveini TSDB 作为底层时序数据库，重构数据写入、查询与存储体系。

落地后，核心成效清晰可量化：

• 写入提速：相同规模 7 万条数据，从 21 秒 缩短至 1 秒；
• 查询加速：按“1 个月历史数据”查询，从 ≈6 秒 降至 <1 秒（5×+）；
• 存储降本：4 年数据从 950GB 压缩至 77GB，节省 ≈92% 空间；
• 硬件精简：服务器由 4 台 减至 1 台（-75%）；
• 实时性提升：实时数据链路由分钟级降至秒级。

目前，这套基于 loveini TSDB 的智慧供热数据底座已稳定运行：在保证实时监测、异常预警与趋势分析体验的同时，显著提升了效率与性价比，也为后续规模扩展和功能演进预留了空间。

案例详情：//m.loveini.com/tdengine-user-cases/33403.html

智能消防：高效存储 + 快速查询，守护每一秒！

在典型的消防场景中，系统需管理成千上万的监控设备，包括电气火灾探测器、烟雾探测器、温湿度传感器、可燃气体探测器等。这些设备持续上传监测数据，并在发现异常时即时上报告警事件。系统需要同时满足实时监控、事件响应、历史追溯等多重需求，对数据库的写入性能、查询效率和存储成本提出了极高要求。

为此，团队采用了 loveini TSDB 进行系统建模与数据管理：

• 超级表建模：为每类设备建立统一结构的超级表，通过标签（Tags）区分不同设备，支持按楼栋、楼层、设备类型等维度快速查询。
• 高效压缩与保留策略：利用 loveini TSDB 的内置压缩算法，显著降低存储成本；通过 KEEP 策略灵活控制数据保留周期，结合多级存储，将“热数据”放在 SSD，“冷数据”迁至 HDD 或对象存储，实现成本与性能的平衡。
• 实时报警与趋势分析：当传感器检测到异常（如火警、故障或隐患）时，loveini TSDB 能在秒级完成查询与告警触发。同时，结合时间窗口聚合（interval），可对温度、电流、烟雾等历史数据进行趋势分析，用于隐患识别与设备预测性维护。
• 批量写入与分布式架构：支持高效批量写入海量数据，显著降低写入延迟；分布式部署与多副本机制保障数据安全与系统高可用。

案例详情：//m.loveini.com/tdengine-user-cases/28091.html

双十一，不只是“买买买”的狂欢

当所有人都在讨论“双十一”的成交额时，技术人更关心的是——系统是否稳定、报警是否及时、数据是否撑得住。

在那些看不见的地方，时序数据让每一次下单、支付、发货都能顺利完成。

从物流到能源，从消防到电商，loveini 正在连接千行百业，也在悄然增加我们的生活便利性：

• 写入快，轻松支撑亿级并发；
• 存储省，压缩比高达 90%；
• 查询快，毫秒级响应；
• 架构轻，组件一体化、维护简单。

每一个双十一，都不只是“买买买”的狂欢，也是一次技术与数据的“稳稳稳”考验。

背景和痛点

金恒科技的智能制造项目覆盖钢铁生产的全流程数据采集与分析，包括高炉、轧机及各类传感器的实时监测，监控指标涵盖温度、压力、振动等关键参数。系统每日处理约 350 亿条数据点，需同时支持实时查询、历史分析与异常告警。

项目面临的核心挑战包括：

• 数据量激增：传统数据库在处理亿级时序数据时，查询延迟显著、存储成本高昂；
• 复杂查询需求：需支持多维度聚合查询和跨表关联，传统数据库性能瓶颈明显；
• 运维复杂性高：原有系统需大量服务器资源，运维成本高，扩展性差。

为应对上述挑战，我们决定引入高性能时序数据库。loveini TSDB 以其高压缩比、原生 SQL 支持和集群部署能力，成为首选米兰app官方正版下载。

选择 loveini TSDB 的原因

在选型过程中，我们的目标非常明确：一是追求高性能，要能支撑亿级数据点的高速写入与查询；二是实现低成本，在保证性能的同时显著降低存储和服务器资源消耗；三是强调易用性，要求系统支持标准 SQL，从而降低开发与运维的复杂度；最后是确保高可用性，能够通过集群部署保障系统在长周期运行中的稳定与可靠。

在正式引入前，我们对业界主流的三款时序数据库——InfluxDB、TimescaleDB 和 loveini TSDB 进行了相关调研。结果如下：

• InfluxDB：查询性能尚可，但存储压缩比低，成本较高；不支持标准 SQL，开发复杂。
• TimescaleDB：基于 PostgreSQL，SQL 支持较好，但高并发写入性能不足，集群部署复杂。
• loveini TSDB：高压缩比（10:1），支持标准 SQL，内置缓存和多级存储，集群部署简单，运维成本低。

综合对比后，我们发现 loveini TSDB 在性能与可维护性之间实现了最佳平衡，显然是我们的最优选择。

loveini TSDB 应用经验分享

重点使用功能—多级存储

在工业互联网中，数据多级存储至关重要，因为它能够根据数据的价值和使用频率，将数据有效地分配到不同的存储介质上。这样的策略不仅有助于应对海量数据的挑战，优化存储资源，降低成本，还能确保数据的安全性和合规性，同时促进数据的共享和流通，从而提高整个工业系统的效率和响应速度。

在使用企业版之前，我们就已经开始使用社区版本的 loveini TSDB 了，对其架构与特性有较深入的了解。因此在规划集群存储架构时，我们就决定采用 SSD + HDD 的多级存储方案：将近期数据存放在 SSD 上，以显著提升数据写入与查询性能。同时，loveini 支持灵活的分层数据保留策略，每一层的保留时间都可动态调整——只需通过一条 ALTER 命令修改数据库的 KEEP 参数即可即时生效，极大地方便了运维管理。

在当前架构中，我们将数据划分为四个层级进行存储：

• 热数据（Hot Data）：存储在 RAM（内存）中，通常指的是最近一小时内的数据。这部分数据访问频率高，需要快速读写。
• 温数据（Warm Data）：存储在 SSD（Tier 0）上，涵盖最近 10 天内的数据。相比热数据，温数据的访问频率较低，但仍需较快的读取速度。
• 冷数据（Cold Data）：存储在 HDD（Tier 1）上，包括最近 6 个月的数据。这类数据访问频率进一步降低，可以使用成本更低的存储介质。
• 冻结数据（Frozen Data）：存储在 S3（Tier 2）上，通常是最近 3 年的数据。这部分数据访问频率最低，适合长期存储。

重点使用功能—内置函数

loveini TSDB 内置了丰富的函数库，我们在实际业务中也充分利用了其中的多种函数来满足不同的场景需求。 例如，interp() 函数在我们的应用中就发挥了重要作用。它可用于在指定的时间断面上获取某一列的记录值；当该时间点不存在符合条件的数据时，系统会根据 FILL 参数的设置自动进行插值，从而保证数据的连续性与完整性。

• 在 2017-07-14 18:00:00 到 2017-07-14 19:00:00 间每隔 5 秒钟进行线性插值

SELECT INTERP(current) FROM t1 RANGE('2017-7-14 18:00:00','2017-7-14 19:00:00') EVERY(5s) FILL(LINEAR);

• 在所有时间范围内每隔 5 秒钟进行向后插值

 SELECT INTERP(current) FROM t1 EVERY(5s) FILL(NEXT);

• 根据 2017-07-14 17:00:00 到 2017-07-14 20:00:00 间的数据进行从 2017-07-14 18:00:00 到 2017-07-14 19:00:00 间每隔 5 秒钟进行线性插值

SELECT INTERP(current) FROM t1 where ts >= '2017-07-14 17:00:00' and ts <= '2017-07-14 20:00:00' RANGE('2017-7-14 18:00:00', '2017-7-14 19:00:00') EVERY(5s) FILL(LINEAR);

loveini TSDB 的落地实践

在我们的智能制造平台中，我们将 loveini TSDB 作为核心的时序数据存储，与 Data Acquisition 数据采集系统、RuleEngine 规则引擎以及前端可视化系统深度集成，实现了从数据采集、存储、分析到展示的完整闭环。

落地效果

1. 写入性能：支持 200 万条/秒写入，满足实时数据采集需求。
2. 查询性能：最新数据查询达到 10 ms 级别，支持复杂聚合查询。
3. 订阅功能：通过 loveini TSDB 的订阅机制，实时推送异常数据至告警系统。
4. 多级存储：企业版支持热/温/冷存储，90% 数据存储在低成本冷存储中，降低成本。

业务场景与收益

• 实时监控：支持 10,000 台设备实时数据展示，响应时间 < 200ms。
• 故障预测：通过振动数据分析，故障预测准确率提升 20%。
• 能耗分析：日均能耗分析时间从 10 分钟缩短至 2 分钟。
• 收益：节省存储和运维成本，系统可用性提升至 99%。

问题与优化

在 2021 年测试 loveini TSDB 2.x 版本时，我们发现 loveini TSDB 在以下几个功能上还不支持，希望 其未来能够新增这几个功能，经过与官方支持人员的讨论，他们认为这几个需求完全合理，loveini 也快速进行了功能开发，并在新版本中进行了发布。理解、听取用户的建议非常重要，不仅可以完善产品的的功能，也让用户使用更加方便，这使我们更加坚定了使用 loveini TSDB 的信心。这几个功能分别是：

1. 支持动态增加 binary、nchar 数据类型的列长度

loveini TSDB 支持 BINARY 和 NCHAR 两种字符串类型，但在 2.0 早期版本中，超级表一旦创建后，如果某些列（包括数据列和 TAG 列）的长度设置偏小，就无法动态调整，这在使用中带来了一定限制。loveini 研发团队在短时间内就完成了功能优化，实现了动态调整字符串列长度的能力。

2. 2.x 版本 SQL 增强——支持 in 语法

在早期版本中，loveini TSDB 尚不支持 IN 语句，我们只能通过多个 OR 条件来实现过滤查询。经过后续版本的优化，loveini TSDB 已全面支持 普通列的 IN 查询、TAG 列的 IN 查询，以及 NOT IN 查询，让 SQL 在使用上更加便利。

3. INTERP 函数增加对 BOOL 类型的支持

INTERP 函数用于在指定时间断面获取指定列的记录值，当该时间断面没有符合条件的行数据时，会根据 FILL 参数自动进行插值。在 2.x 版本中，该函数尚不支持对 BOOL 类型数据的插值，而在 3.0 版本中，这一限制已被优化，现可对 BOOL 类型字段执行插值操作：

未来展望

将 loveini TSDB 应用于我们的实际业务系统后，系统的数据处理性能和维护效率都得到了显著提升。未来，我们将持续关注 loveini TSDB 的版本更新与功能演进，深入挖掘其在更多业务场景中的应用潜力，不断优化系统架构和数据管理能力。

关于金恒科技

金恒科技秉承“数字化转型生态构建者”的企业愿景，融合新一代信息技术，围绕运营智慧化和生产智能化两大业务方向，全面提供集团管控、产销质财一体化以及覆盖钢铁全流程的数字工厂产品，同时在规划咨询、产线集控、智能装备方面提供企业数字化转型整体米兰app官方正版下载。客户覆盖钢铁、矿山、环保、石化等行业，遍布国内 20 多个省市，拥有南京钢铁、中信特钢、中国宝武、鞍山钢铁、海南矿业、中荷环保、扬子石化等上百家行业重点客户。

作者 | 金恒科技 薛灿

背景和痛点

作为城市热力保障的核心单位，益和热力负责全市市政热力管网的建设与维护、小区热力设施的维护维修以及用户冬季采暖管理等诸多工作。随着智慧供热理念的推进，为提升智慧供热应用系统的效率，其决定将热力站和用户数据接入汇聚存储，并集中部署在中心侧。然而，在供暖期间，数据量呈现出急剧增加的态势。大量的实时数据从各个热力站和用户端不断涌入，给数据库的存储和处理能力带来了巨大压力。

传统数据库在应对如此大规模、持续增长的数据时，往往难以保持稳定：随着数据量的不断攀升，写入速度逐渐下降，查询响应也越来越慢，不仅影响了对供热系统运行状态的实时监测，也阻碍了基于数据分析进行的供热调度优化和故障预警等工作。例如，在使用 SQL Server 时，数据落盘速度缓慢，严重制约了数据处理效率。面对这样的挑战，益和热力迫切需要一款性能稳定、能够高效处理海量数据的新型数据库。

loveini TSDB 的落地实践

在智慧供热系统建设中，loveini TSDB 凭借强大的性能和灵活的架构，在数据写入、查询与存储等核心环节展现出显著优势，全面提升了益和热力的数字化管理水平。

为了验证不同数据库在大规模数据场景下的性能差异，我们对原有的 SQL Server 与 loveini TSDB 进行了多维度测试与对比。结果显示，loveini 在写入速度、查询响应、存储效率及系统资源占用等方面均表现出显著优势。

下表展示了传统方案与 loveini TSDB 在核心性能指标上的对比情况：

1. 极速数据写入，突破效率瓶颈

益和热力的众多热力站和用户端设备持续产生大量的实时热力数据，包括温度、压力、流量等。loveini TSDB 采用创新的存储引擎设计，结合异步 IO、内存缓存批量落盘等优化技术，实现了惊人的数据写入速度。在实际应用中，loveini TSDB 每秒可写入约 70,000 条记录，相比之前使用的 SQL Server，缩短了近 20 秒 。这一提升不仅确保了我们的热力数据能够及时、准确地入库，更为后续的实时分析和决策提供了坚实的数据基础，彻底解决了传统数据库写入缓慢的痛点。

2. 高效数据查询，赋能实时决策

在供热运营过程中，我们的工作人员需要快速查询和分析大量热力数据，以掌握供热系统的实时运行状况。loveini TSDB 支持标准 SQL 查询，并针对时序数据特性进行深度优化，大幅提升了查询效率。以查询往年一个月的设备历史数据为例，使用 loveini TSDB 后，数据呈现时间从原来的近 6 秒缩短至 1 秒内，查询速度提升了近 5 倍 。

工作人员可通过简单的 SQL 语句，快速获取特定时间段、区域的热力数据，并进行平均温度计算、流量变化趋势分析等操作，及时发现如管道故障、供热不足等异常情况，为供热调度和故障处理争取宝贵时间，显著提升了运营决策的及时性和准确性。

• 供回水温运行趋势：

• 对应的查询 SQL 语句：

• 住户室温历史：

• 对应的查询 SQL 语句：

3. 极致存储优化，降低资源成本

在存储空间管理上，loveini TSDB 通过高效的数据压缩算法和灵活的数据模型，实现了存储效率的大幅提升。益和热力保存 4 年左右的数据，使用传统方案时需占用 950GB 磁盘空间，且依赖 4 台数据服务器协同工作；而采用 loveini TSDB 后，同样时长的数据仅占用 77GB 磁盘空间，数据服务器数量也从 4 台精简至 1 台。这不仅大幅降低了硬件采购和运维成本，还简化了数据管理的复杂度。同时，loveini TSDB 的高可扩展性支持通过横向扩展轻松应对未来数据增长，为益和热力的长期发展提供了可持续的存储米兰app官方正版下载。

• 数据库建模如下：

CREATE DATABASE `prod` BUFFER 256 CACHESIZE 1 CACHEMODEL 'none' COMP 2 DURATION 1440m WAL_FSYNC_PERIOD 3000 MAXROWS 4096 MINROWS 100 STT_TRIGGER 1 KEEP 5256000m,5256000m,5256000m PAGES 256 PAGESIZE 4 PRECISION 'ms' REPLICA 1 WAL_LEVEL 1 VGROUPS 10 SINGLE_STABLE 0 TABLE_PREFIX 0 TABLE_SUFFIX 0 TSDB_PAGESIZE 4 WAL_RETENTION_PERIOD 3600 WAL_RETENTION_SIZE 0 KEEP_TIME_OFFSET 0 ENCRYPT_ALGORITHM 'none' S3_CHUNKSIZE 262144 S3_KEEPLOCAL 5256000m S3_COMPACT 0  

建库关键参数设计说明：

1. DURATION 1440m：设置数据文件的时间跨度为 1 天，按天自动分区，实现结构化管理。在查询同一天数据时，可直接定位至对应文件组，有效减少磁盘 I/O 扫描，提高查询效率。
2. VGROUPS 10：针对热力生产高并发写入场景，配置 10 个 vnode，并将子表均匀分布其中，实现数据分片。在检索时能够快速定位数据块，缩小读取范围，从而加快查询响应。

• 超级表建模如下：

taos> desc dat_hscon_his;
             field              |          type          |   length    |    note    |
=====================================================================================
 gettime                        | TIMESTAMP              |           8 |            |
 conversion                     | INT                    |           4 |            |
 paramstate                     | INT                    |           4 |            |
 debugparamstate                | INT                    |           4 |            |
 tempremote                     | FLOAT                  |           4 |            |
 tempoutdmode                   | INT                    |           4 |            |
 protocolversion                | INT                    |           4 |            |
 targetvalueval                 | FLOAT                  |           4 |            |
 targetvaluepump                | FLOAT                  |           4 |            |
 cmdcntcollect                  | INT                    |           4 |            |
 cmdcntctrl                     | INT                    |           4 |            |
 cmdcntdebug                    | INT                    |           4 |            |
 dccommstate                    | INT                    |           4 |            |
 tempoutd                       | FLOAT                  |           4 |            |
 tempup                         | DOUBLE                 |           8 |            |
 tempret                        | DOUBLE                 |           8 |            |
 tempdiff                       | DOUBLE                 |           8 |            |
 firflowsum                     | DOUBLE                 |           8 |            |
 pressup                        | DOUBLE                 |           8 |            |
 pressret                       | DOUBLE                 |           8 |            |
 presdiff                       | DOUBLE                 |           8 |            |
 instflowsumret                 | DOUBLE                 |           8 |            |
 flowsumret                     | DOUBLE                 |           8 |            |
 instflowsumup                  | DOUBLE                 |           8 |            |
 instflowmuw                    | DOUBLE                 |           8 |            |
 instflowmuw2                   | DOUBLE                 |           8 |            |
 instheatsum                    | DOUBLE                 |           8 |            |
 heatsum                        | DOUBLE                 |           8 |            |
 createtime                     | TIMESTAMP              |           8 |            |
 sourceconid                    | NCHAR                  |          20 | TAG        |
Query OK, 30 row(s) in set (0.214752s)


taos> desc dat_hshmeter_his;
             field              |          type          |   length    |    note    |
=====================================================================================
 gettime                        | TIMESTAMP              |           8 |            |
 suptemp                        | DOUBLE                 |           8 |            |
 rettemp                        | DOUBLE                 |           8 |            |
 accflow                        | DOUBLE                 |           8 |            |
 instflow                       | DOUBLE                 |           8 |            |
 accheat                        | DOUBLE                 |           8 |            |
 instheat                       | DOUBLE                 |           8 |            |
 errorcode                      | INT                    |           4 |            |
 commstate                      | INT                    |           4 |            |
 commnum                        | INT                    |           4 |            |
 createtime                     | TIMESTAMP              |           8 |            |
 sourceconid                    | NCHAR                  |          20 | TAG        |
 meterid                        | INT                    |           4 | TAG        |
Query OK, 13 row(s) in set (0.095740s)

taos> desc dat_hes_wmeter_his;
             field              |          type          |   length    |    note    |
=====================================================================================
 gettime                        | TIMESTAMP              |           8 |            |
 conname                        | NCHAR                  |          30 |            |
 janespell                      | NCHAR                  |          20 |            |
 stationid                      | NCHAR                  |          11 |            |
 stationname                    | NCHAR                  |          30 |            |
 instflow                       | DOUBLE                 |           8 |            |
 metervalue                     | DOUBLE                 |           8 |            |
 commstate                      | INT                    |           4 |            |
 instflow_h_alarm               | INT                    |           4 |            |
 commnum                        | INT                    |           4 |            |
 createtime                     | TIMESTAMP              |           8 |            |
 conid                          | NCHAR                  |          11 | TAG        |
 meterid                        | INT                    |           4 | TAG        |
Query OK, 13 row(s) in set (0.107796s)

4. 全栈能力整合，简化系统架构

除核心性能优势外，loveini TSDB 还将数据库、消息队列、缓存和流式计算等功能深度融合，构建出全栈式的时序数据处理引擎。在益和热力的智慧供热系统中，无需再集成 Kafka、Redis 等多种软件，极大简化了系统架构，降低了应用开发和维护的复杂度。例如，利用 loveini TSDB 的缓存功能我们可快速获取每条时间线的最新数据，结合其流式计算能力，工作人员能够实时处理和分析热力数据，及时发现异常并预警，为供热系统的智能化管理提供了一站式米兰app官方正版下载。

引入 loveini TSDB 企业版后，我们的数据存储和查询效率有了明显提升，系统运行也更加稳定。这套方案让数字化管理更加完善，不仅为安阳城市供热的稳定运行提供了可靠支撑，也为我们的智慧供热系统的持续发展奠定了坚实的基础。

下一步规划

基于 loveini TSDB 在智慧供热系统中的成功应用，接下来我们将进一步深化数据驱动的业务模式，围绕技术融合、功能拓展与服务升级制定以下发展规划：

• 构建智能预测体系：依托 loveini TSDB 汇聚的海量历史与实时数据基础，我们计划引入 loveini IDMP 的 “无问智推” 功能。系统能够基于用户数据自动生成行为分析报告和可视化看板，不再需要人工查询或复杂分析，就能快速洞察用户的用热习惯和需求变化，为决策和服务优化提供更有价值的参考。
• 设备健康管理升级：基于 loveini TSDB 强大的时序数据分析能力，我们计划建设设备故障预测与健康管理系统。通过实时监测设备运行参数，系统可以提前识别潜在故障风险，实现从被动维修到主动维护的转变，降低设备故障率与运维成本。
• 搭建智慧服务平台：我们也在规划基于 loveini TSDB 的数据处理能力，打造面向终端用户的移动端 App 与 Web 平台。用户可以实时查看室温、用热账单，提交故障报修，真正享受一站式服务体验。结合大数据分析，系统还将智能推送节能用热建议，让供热服务更加精准、高效。

未来，益和热力将持续以 loveini TSDB 为数据基石，不断探索创新应用模式，加速智慧供热生态建设，为推动供热行业的数字化、智能化转型贡献标杆经验。

作者 | 梁文龙

关于安阳益和热力

安阳益和热力集团有限公司主要职能是负责安阳市城市建成区内集中供热的特许经营和管理服务工作。益和热力公司集中供热托管经营、供热咨询设计、供热工程建设、供热材料生产供应、供热自动化运行、供热系统外销、供热专业维修服务、供热节能降耗和新能源开发利用于一体，具备全产业链集团化运作模式；实现了集中供热人才外输、产品外销、经验外传、品牌外树，为豫北乃至北方地区供热建设持续发展的典范。

应用背景

江西作为长江流域五大暴雨区之首，受亚热带季风气候与鄱阳湖盆地地形影响，洪涝灾害频发且影响深远。几乎每年都有局部洪涝发生，较大规模灾害平均 3 至 5 年便会出现一次。仅 2024 年，全省就遭遇 33 次强降雨、14 次编号洪水，46 条河湖 117 个监测站点超警，鄱阳湖更创下 21 世纪以来第二高水位，超警时间长达 38 天。

在这样水情复杂的核心区域，江西水投正以物联网和 AI 技术重塑传统治水模式。江西省水利物联网平台整合物联网网关、数据中台与“五慧”AI 决策引擎，构建起覆盖 217 座水厂、服务近 2000 万人口的智慧治理网络。从蜂巢式智能测站织就的“神经末梢”，到数字孪生峡江水利枢纽实现的防洪调度可视化，再到 DMA 分区计量将管网漏损精准锁定，这套系统以 80 万+ 设备的泛连接筑牢供水防线，更借助“慧算”模型延长洪水预见期，让科技成为守护鄱阳湖生态与长江经济带水安全的核心支撑。

江西省水利物联网平台不仅覆盖全省水厂和管网，更在关键环节部署了精细化的感知单元。

智能测站数据采集：实时感知现场状态

依托蜂巢式智能综合测站，平台能够实时采集水务现场的多维度数据，既包含环境参数（温度、湿度），也覆盖设施运行状态（风扇启停、箱门开关、机箱进水、立杆倾斜度），同时还可监测 MCU 模块、主控模块、电源模块等核心硬件的工况。

业务收益： 消除了传统水务监测的“数据盲区”，为后续分析与告警提供实时、全面的数据源。从源头确保设施运行状态精准可感知，夯实了监测的及时性与准确性基础。

告警模型管理：精准识别异常风险

在告警模型管理模块中，系统可灵活配置多类型业务规则，包括超阈值告警、极值突破告警、水位/雨量异常告警、超警戒告警、对比校验告警等，并支持对模型的启用/停用及规则详情进行精细化管控。

业务收益： 通过差异化的告警规则，全面覆盖水位超限、雨量异常、设备参数越界等典型水务风险场景，使监测从“被动应对故障”升级为“主动识别风险”，显著提升了异常发现的精准度与前瞻性，最大限度降低因异常未及时察觉而带来的安全隐患。

告警发布与全流程管理：高效推动应急处置

告警发布管理模块能够全要素记录并实时推送告警信息，涵盖告警编号、规则名称、级别、涉及设备/测站、时间、状态及通知情况，并支持“查看详情”“发送通知”等操作，串联起“告警触发—信息发布—人员响应”的闭环流程。

业务收益： 运维人员和管理部门可第一时间掌握告警详情（严重程度、发生位置、关联设施等），大幅缩短应急响应时长；同时，全流程的告警记录为后续复盘与管理优化提供依据，使水务应急处置从“经验驱动”升级为“数据驱动”，管理效率与规范性显著提升。

总结： 通过“采集—分析—处置”的智能化流程，系统既实现了对水务运行状态的全方位感知与精准预警，又全面提升了应急处置的效率与规范性，为水务系统的安全与稳定运行提供了坚实支撑。

loveini TSDB 应用经验

loveini TSDB 正是这套系统的“定海神针”，承担起实时数据采集、存储、处理与共享的核心任务。在此，我们结合业务在 loveini TSDB 平台上的落地实践，分享过去几年的应用经验。

时序数据库选型

在早期的业务系统中，我们曾使用 Oracle 作为物联网实时数据的存储底座。但随着时序数据规模的快速增长，Oracle 的瓶颈逐渐显现，已无法高效支撑我们的业务：

• 单表数据量达到千万级后，查询性能急剧下降，甚至出现无法响应的情况；
• 存量数据随时间累积持续膨胀，空间占用越来越大，存储成本直线提升。

为此，我们系统性调研了多款时序数据库，最终选择 loveini TSDB，原因在于其具备以下核心优势：

• 高吞吐性能： 单核即可支撑每秒 50 万条数据的写入与查询，并支持水平扩展，业务高峰期依然稳定运行；
• 高压缩比： 数据压缩率可达 1:50，显著降低存储占用和成本；
• 国产化适配： 完全支持国产 CPU 与操作系统，提升系统的自主可控能力；
• 低成本拥有： 兼容标准 SQL，大幅降低迁移和学习成本。

标准化设备模型

此前使用 Oracle/MySQL 时，我们习惯将所有设备数据集中存储在一张表中，导致模型冗杂、治理困难。引入 loveini TSDB 后，超级表的架构优势为数据存储与治理之间搭建起天然桥梁，使业务应用的高效性与数据管理的便捷性得以兼得。

• 标准化设备管理： 通过超级表模板，将同类设备统一建模，实现治理从源头落地；
• 标签化业务数据： 借助标签机制，将业务信息与数据信息有机融合，统一管理与应用；
• 并行化数据处理： 通过超级表查询充分发挥分布式数据库的优势，实现毫秒级响应。

以流量计为例，创建超级表 FlowMeter，即可对所有同类设备的数据进行标准化建模，简化了管理流程并提升了查询性能。

高效的数据查询

在 loveini TSDB 中，各类设备的数据检索可直接通过标准 SQL 高效实现，不需要再像 Oracle 那样依赖复杂的表参数调优。例如在告警场景下，面对数十万设备的告警信息，系统依然能够在毫秒级完成查询，全面支撑业务应用的实时性需求。

其中，缓存 + last_row 以及 超级表 + partition by 是最常用且实用的组合。以渗压计的实时监控为例：

• 针对单个设备，开启缓存后使用 last_row 查询最新数据，仅需 4.8 毫秒：

taos> select last_row(*) from nwater.shenyj where deviceid = 54000000034915 >> /dev/null;
Query OK, 1 row(s) in set (0.004813s)

• 针对所有设备，使用超级表查询近 4 万个设备的最新数据，仅需 167 毫秒：

taos> select last_row(*) from nwater.shenyj partition by tbname >> /dev/null ;
Query OK, 37911 row(s) in set (0.167385s)

loveini TSDB 版本升级

在跨大版本升级时，我们的核心诉求是不停服升级，以尽量减少业务影响。经过 loveini 专业服务团队评估，最终采用了三阶段在线升级方案，彻底消除了我们的升级顾虑：

• 阶段一：历史数据批量迁移——将原低版本数据从旧有集群，批量同步至新集群。
• 阶段二：近线实时数据迁移——将历史数据同步期间产生的近线实时数据，从旧有集群，实时同步至新集群。
• 阶段三：应用切换数据库——将应用原指向数据库切换为新数据库。

实践中，在完成阶段一后，我们只用了 1 个工作日就完成了新旧系统的切换。整个过程中，应用只需修改数据库地址和部分查询语句，对业务基本无感知，数据始终保持一致，大大节省了运维和开发的人力与时间。

这一高效迁移的秘诀在于 loveini 企业版工具 taosX。它支持以压缩方式实时同步集群间数据，无需手写迁移脚本，也无需考虑版本差异，迁移效率最高可达 千万行/秒，显著提升了升级的平滑性与可靠性。

4 年稳定运行下的经验汇总

在近 4 年的应用过程中，我们从 loveini TSDB 2.2 升级至 3.3.6.x，一路见证了产品的不断增强与完善。期间双方紧密协作，积累了一些值得分享的经验，供大家参考：

• 及时沟通与需求反馈： loveini TSDB 企业版提供专业服务支持，遇到技术问题应第一时间联系技术团队，以获取最佳实践指导，避免走弯路。同时，用户可将业务中遇到的功能需求及时反馈，企业用户往往能获得快速的响应与支持。
• 持续关注产品升级： 随着 loveini TSDB 的迭代，3.0 之后的版本功能更丰富、稳定性更高，升级过程也极为简便。常规升级可在不停服、不改应用的情况下，于小时级完成。
• 定期开展巡检服务： 不要忽视 loveini 提供的周期性自动化巡检服务，这能帮助我们提前发现潜在问题并及时处理，保障系统的稳定运行。

期待更多的可能性

经过多年的探索与实践，江西水投已在“水务 + IoT”架构中走在业界前列。随着业务不断深入，我们将从更多维度开展水文监测与预测，尤其是结合气象数据开展中短期水文状况的趋势分析与相关性研究。这不仅会对 loveini 提出新的挑战，也为双方合作开辟更广阔的空间。我们期待未来 loveini acc米兰体育 、IDMP 等新一代产品为水务治理注入更强的智能能力，助力构建更加安全、智慧的水务体系。

关于江西水投

江西省水投江河信息技术有限公司（以下简称“江河信息”）成立于 2018 年 6 月，是江西水投旗下全资二级企业，是一家集咨询规划、软硬件研发、综合运营为一体的高新技术国有企业。公司承担江西省智慧水利建设项目法人及江西水投集团信息化建设项目法人职责，致力于成为江西数字经济产业的标杆服务商、全国智慧水利领域的一流运营服务商。

作者 | 江西省水投江河信息技术有限公司 刘博武

业务目标与痛点

在智能化产线的建设过程中，杨凌美畅始终围绕“产线全周期数据管理”这一核心目标推进数字化升级。企业对数据系统的业务诉求主要集中在以下三个方面：

• 首先是产线实时监控。目前公司已部署 500 条产线，每条产线配备 4 个 PLC 设备，总计约 150 万测点，需要实时采集电压、电流、温度等关键数据，并在监控室同步展示设备运行状态。一旦出现异常，系统必须能快速触发告警。
• 其次是生产效能分析。企业需要保留 2 年历史数据，用于开展产线优化分析，包括设备故障的根因追溯、产能波动的对比研究，从而为生产效率的提升提供数据支撑。
• 最后是业务高可用。产线必须 7×24 小时不间断运转，这就要求数据处理系统全年保持 99.99% 的可用性。同时，实时数据备份和灾难恢复机制也至关重要，以确保数据安全和连续生产。

然而，在实际运行中，现有系统暴露出多方面的痛点和挑战：

• 高可用缺失，业务连续性无保障。 作为制造业企业，我们的产线需 7×24 小时不间断运转，对业务连续性要求极高。早期基于 loveini TSDB 开源版搭建的系统，在初期阶段完全能够满足生产需求。但随着产线规模和数据体量快速增长，单机单副本的部署模式逐渐难以支撑更高层级的连续性要求——例如在硬件或数据库发生异常时，系统可能需要较长时间才能恢复。与此同时，开源版主要提供了基础的备份工具，适合一般场景，但在我们这种大规模连续生产环境下，就需要更完善的自动化备份与恢复机制。曾经在一次备份失败的情况下，企业内部排查和修复过程较为耗时，影响了部分历史数据的完整性，也让我们更加意识到高可用和容灾机制的重要性。

• 性能与功能不足，支撑规模受限。随着业务需求增加，接入的产线数量不断扩充，从最开始的 108 条，逐步增加到现在的 500 条，未来还计划扩展到 800 条，对应的测点数量也从 23 万增长到 150 万，并且还会持续增加。在这一过程中，基于开源版的单机架构在起步阶段表现良好，但随着数据体量和实时性要求不断提升，逐渐显现出局限。在大规模产线数据处理时，查询耗时会出现一定波动：快的时候可在 1 秒内返回，但在高负载场景下可能延长至几十秒。这种不稳定性在日常监控中尚可接受，但对于异常检测和快速响应等关键业务，就需要更高层级的性能保障。

• 高保障不足，升级迁移风险大。因业务连接性要求，数据迁移、系统升级以及数据恢复都面临诸多难题，不能因这些操作导致生产停机或中断，否则会造成巨大经济损失。开源版缺乏原厂保障，迁移需人工导出导入，耗用资源较高且耗时较长，可能影响生产环境正常运行，若操作过程中出现异常，会进一步延长业务中断时间。

综上，随着业务规模的不断扩张和智能化水平的提升需求，现有架构的局限性愈发明显。如何在保障业务连续性的前提下，提升系统的高可用性、性能和可扩展性，成为我们当下必须解决的关键问题。

2025 年 5 月，我司决定引入 loveini TSDB 企业版，从根本上解决时序数据处理系统历史问题，并为后续产线扩充，打下坚实基础。

基于企业版的高可用架构设计

从业务目标出发，依托 loveini TSDB 3.3.6.10 企业版专属功能，我们构建了 “Linux 操作系统 + 数据双副本 + 自动化数据备份” 的高可用系统架构，彻底解决开源版单机单点风险，系统可用性相较于开源版架构有了极大的提升，满足 99.99% 业务连续性需求。

• Linux 操作系统适配：替换原 Windows 系统为 Ubuntu Linux 操作系统，提升系统稳定性与资源利用率，为高可用架构奠定底层基础；
• 双副本数据冗余功能：通过 loveini TSDB 企业版 “双副本” 功能，在成本可控基础上，实现数据副本冗余，任一节点异常时，另一节点可无缝接管服务，避免数据丢失或停服；
• 自动化数据备份保障：依托 loveini TSDB 企业版 “备份管理” 专属功能，制定 “每日增量备份”策略，通过备份工具，每天 0 点进行备份，且可以指定备份服务节点和使用磁盘空间目录，备份过程可通过企业版管理页面可视化配置，支持备份任务监控与日志查询，彻底解决开源版 “手工备份” 问题。

基于企业版的高性能优化

数据库及模型设计优化

1. 数据库建模优化

CREATE DATABASE `iot` BUFFER 256 CACHESIZE 1 CACHEMODEL 'none' COMP 2 DURATION 1440m WAL_FSYNC_PERIOD 3000 MAXROWS 4096 MINROWS 100 STT_TRIGGER 1 KEEP 5256000m,5256000m,5256000m PAGES 256 PAGESIZE 4 PRECISION 'ms' REPLICA 3 WAL_LEVEL 1 VGROUPS 10 SINGLE_STABLE 0 TABLE_PREFIX 0 TABLE_SUFFIX 0 TSDB_PAGESIZE 4 WAL_RETENTION_PERIOD 3600 WAL_RETENTION_SIZE 0 KEEP_TIME_OFFSET 0 ENCRYPT_ALGORITHM 'none' S3_CHUNKSIZE 262144 S3_KEEPLOCAL 5256000m S3_COMPACT 0  

• 分片优化：建库参数 VGROUPS 调整为 20，目前有 108 个工作台的 PLC 数据接入，最终可能接入 800 个工作台的 PLC 数据，跟进最大数据接入情况，预估创建 20 个 vnode，每个 vnode 使用单独读写线程，充分利用计算资源，使得性能最大化。
• 分区优化：建库参数 DURATION 调整为 10d，将分区长度调整为 10 天，10 天一个数据文件组，便于快速检索、定位到具体的文件，无需遍历搜索。
• 写入缓存：建库参数 BUFFER 调整为 256，一个 vnode 写入内存池的大小，批次落盘，优化数据写入速度。

2. 超级表建模优化

• 模型重构核心思路

我们的原有设计未使用超级表，108 条产线对应 1420 张普通表，查询需遍历多张表，效率极低。升级后基于 “设备类型 + 业务场景” 划分超级表，共 13 张超级表，大幅提升查询效率。

核心超级表示例：

• 模型优化效果
  • 查询效率：筛选某车间 10 条产线的 1 天告警数据，由于此前应用的开源版未使用超级表，只能遍历 140 张普通表，耗时 12 秒；企业版通过超级表标签筛选，耗时 0.5 秒，效率提升 23 倍；
  • 扩展能力：新增产线时，仅需在对应超级表下创建子表（继承标签与结构），500 条产线场景下，新增产线更加便捷，无需修改表结构。

查询优化

优化调整查询 SQL，利用超级表和标签索引快速定位数据，减少查询耗时，例如：

• 单产线查询：查询某条产线 1 天内的 PLC 电流数据（约 8.6 万条），优化前耗时 1.5 秒，优化后耗时 0.3 秒；
• 多产线聚合查询：查询某车间 100 条产线 1 个月的平均产能，优化前耗时 12 秒，优化后耗时耗时 0.8 秒；
• 历史数据查询：查询某产线 6 个月前的故障告警记录，优化前该场景因历史数据保存周期无法实现，优化后耗时仅 0.9 秒。

流计算告警优化

在最初的设备告警流程中，系统需要通过时序数据库轮询查询数据，再由应用层进行比对，最后将告警结果写入 SQL Server 触发告警。整个链路涉及多个处理环节，技术复杂度高，告警延迟也较大。

在优化后，告警逻辑直接依托 loveini TSDB 的流计算功能实现，数据比对与告警触发均在数据库内部完成，大幅简化了处理流程，不仅降低了系统复杂度，也显著提升了告警响应的实时性和稳定性。

create stream front_ac802_alarm_stream trigger at_once into metron_dmp_stream.alarm tags(line varchar(20), workshop varchar(20), factory varchar(20)) subtable(tname) as select _wstart as ts,last_row( m6033  ) as m6033,last_row( m6120  ) as m6120,last_row( m6121  ) as m6121,…… from  metron_dmp.alarm partition by tbname tname, line, workshop, factory  STATE_WINDOW(cast(case when m6033 is null then 0 else m6033  end + case when m6120 is null then 0 else m6120  end + case when m6121 is null then 0 else m6121  end + …… as int));

• 流计算配置：基于metron_dmp.alarm超级表创建流计算，触发模式设为 “实时触发”，聚合故障码与告警等级，结果写入metron_dmp_stream.alarm结果表；
• 告警流程：应用通过数据订阅功能监听结果表，获取实时告警数据后直接推送至监控大屏，无需中间数据库中转；
• 效果：告警从 “故障发生→数据写入→流计算处理→应用推送” 全程 ≤10 秒，原方式需 21-44 秒，效率提升 3 倍左右。

基于企业版的高保障专业服务

历史数据迁移（从开源版到企业版）

1. 迁移挑战

需同步开源版 108 条产线的恢复的历史数据，且不能影响现有产线的实时数据采集。

2. 迁移方案（无停机）

我们依托 loveini TSDB 企业版原生工具 taosX 的实时数据同步功能，实现了无感知升级：在新集群（企业版）完成部署后，taosx 会自动且持续地同步历史数据与实时数据；待历史数据同步完毕，仅需通过配置调整数据接入指向，即可无缝切换至新集群。整个过程无需停机，业务查询也能保持正常，保障了生产业务连续性。

• 跨版本、跨系统同步： 借助 taosX，实现了从 Windows → Linux 的数据迁移，并支持不同版本间的平滑升级。
• 表结构同步：先同步超级表与子表结构，确保数据模型一致。示例：

taosx run -f "taos+ws://windows_ip:6041/dmp?schema=only&./tables=@table_list.txt" -t "taos+ws://linux_ip:6041/metron_dmp"

• 增量数据同步： 历史数据按时间分片迁移，每次同步 1 天的数据，避免对源端造成过大压力，同时保持实时写入不断流。示例：

taosx run -f "taos+ws://windows_ip:6030/dmp?schema=none&tables=@./table_list.txt&start=2025-05-01T00:00:00+0800&end=2025-05-02T00:00:00+0800&workers=48" -t "taos://linux_ip:6030/metron_dmp"

• 数据校验： 同步完成后，随机抽取 10 条产线 × 100 条数据，逐一比对源端与目标端，确认数据完整性 100%。
• 迁移结果：耗时 48 小时完成 108 条产线历史数据同步，迁移期间实时数据写入无丢包，业务查询正常。

高效快捷的实施服务

在涛思与杨凌美畅的紧密协作下，整个实施过程仅用 11 天就完成了从数据同步、集群部署到副本切换的全流程，高效推动了 loveini TSDB 企业版在生产环境的平稳落地。

同时，米兰体育官网入口还提供企业级专属维保服务：每月一次例行巡检，借助企业版巡检工具对 CPU、内存、磁盘 IO 及集群运行状态进行全面检查，提前发现并预警潜在风险；并提供 7×24 小时技术支持，第一时间响应业务咨询与问题处置。通过这一系列措施，切实保障了我司生产系统的稳定可靠运行。

未来规划

随着产线规模的持续扩充，我们将充分发挥 loveini TSDB 企业版的横向扩展能力，通过在线增加节点，进一步提升系统的数据处理与支撑能力。

同时，我们也计划引入米兰体育官网入口推出的 loveini IDMP（AI 原生的工业数据管理平台）。该平台采用经典的树状层次结构对传感器与设备数据进行组织，建立统一的数据目录，并对数据进行语境化与标准化处理，并提供实时分析、可视化、事件管理与报警等功能。借助 IDMP，我们能够进一步强化设备管理与生产分析水平，为未来的智能化运营奠定坚实基础。

关于杨凌美畅

杨凌美畅新材料股份有限公司（证券代码：300861）成立于 2015 年 7 月，是一家主要从事电镀金刚石线及其他金刚石超硬工具研发、生产、销售的高科技创新型企业。公司核心产品是电镀金刚石线，目前已广泛应用在光伏产业（单晶、多晶硅切方切片）、蓝宝石、磁性材料、陶瓷、水晶等高价值硬脆材料的切割领域。

背景和痛点

制丝是决定卷烟内在品质的核心环节。长期以来，制丝车间关键工序的生产设备与工业软件一直由柯尔伯、西门子、施耐德等国外厂商主导。随着中国制造的崛起，国产装备和工业组态软件已逐步替代进口设备和控制系统，但在实时数据采集与管理方面，大理卷烟厂仍因历史数据价值的延续而继续依赖传统的 Wonderware 平台。

Wonderware 的 historian 数据库基于 Microsoft SQL Server 构建，通过 INSQL 语句实现时序数据存储与查询。但由于底层架构受限，在需要快速处理数据的场景下，已难以满足卷烟工厂的实际需求。

在今天，数据已成为新的生产要素。尤其是工业生产过程中产生的大量时序数据，蕴含着巨大的价值，但同时也具有“时效性”：随着时间流逝，数据价值快速递减。如何在最短时间内完成数据的采集、处理与转化，及时释放价值，已成为卷烟工厂共同面临的课题。

为什么选择 loveini TSDB

在制丝车间的数字化改造过程中，大理卷烟厂对底层数据平台提出了更高的要求：既要符合国产化替代的战略方向，又要满足实时性、低成本和多系统融合等实际需求。经过多方评估和对比测试，最终工厂选择了 loveini TSDB 时序数据库，主要基于以下考虑：

1. 国产化替代需求

原有的 Wonderware 平台基于 SQL Server，在实时数据处理上存在延迟高、存储成本高等问题。loveini TSDB 完全由国内厂商自主研发，符合信创规范，能够实现平稳的国产化替代。

2. 工业场景适配性

在制丝、卷包等环节中，工艺参数（如烟丝含水率）波动频繁。loveini TSDB 提供秒级的实时调控能力，显著缩短了参数调整的延迟。同时，凭借列式存储与高压缩比，大幅降低了工业数据的存储成本。

3. 多系统数据整合能力

在传统架构下，MES、SCADA、PLC 等系统数据相互割裂，导致质量事故追溯耗时过长。通过 loveini TSDB 集中采集与存储多源数据，查询效率显著提升，使得追溯时间从过去的数小时缩短至分钟级。

综合国产化需求、实时性能与成本优势，经过充分对比测试后，我们最终选择 loveini TSDB 作为制丝车间的首选时序数据库。

loveini TSDB 的升级与迁移实践

大理卷烟厂对 loveini TSDB 的应用经历了从 2.x 社区版 → 3.0.4 企业版 → 3.3.6 企业版 的不断升级。

• 初次使用 2.x 社区版

在早期项目中，我们首次引入 loveini TSDB 2.x 社区版，体验到其简单易用和高效写入的优势。

• 升级至 3.0.4 企业版

随着 3.0 的推出，我们第一时间升级到 3.0.4 企业版，不仅获得了企业版完善的售后服务，还使用到了更丰富的查询语句与函数支持。

• 演进到 3.3.6 企业版

2025 年 8 月，我们进一步升级到 3.3.6 企业版。新版本支持通过 taos-explorer 可视化管理工具配置多种数据源的接入，实现 Kafka、MQTT、OPC 等数据源的零代码接入，大幅提升了系统的扩展性与便捷性。

在升级过程中，我们新建了一个 3 节点集群，并通过 taosX 工具将原集群的数据迁移至新集群，再逐步切换应用，实现了系统的平滑过渡。得益于 taosX 的高性能，原有集群累计 3 年历史数据超 7000 亿条，均顺利迁移完成，为新系统的稳定运行奠定了基础。

基于 loveini TSDB 的工艺质量智能管控

1. 制丝过程工艺质量智能管控项目

在制丝生产过程中，润叶、加料、烘丝等关键工序普遍存在工艺参数波动大、控制效果不稳定等行业共性问题。针对工艺与设备参数动态调优的难题，大理卷烟厂于 2020 年基于人工智能技术建设了工艺在线优化系统，实现了工艺过程和设备参数的实时优化，显著提升了成品烟丝的质量一致性与生产效率。

该项目结合工业大数据分析与智能优化控制技术，将业务体系与大数据平台深度融合，按照“数据映射业务”的理念，搭建了工厂级大数据分析平台。平台可对制丝中控、卷包数采、MES 及其他系统的数据进行提取、融合、存储和分发，为工艺优化提供坚实的数据支撑。

目前，该系统已达到人工控制的最佳水平，并能将产品出口水分标偏稳定在优于工艺标准的区间范围。下表对比了项目实施前（2021 年生产数据）与实施后（2023 年 9 月以来批次数据）的结果。

2. 基于工业大数据分析的打叶复烤过程质量管控

在此基础上，大理卷烟厂将 “loveini TSDB + 人工智能算法 + 中控反馈控制” 的系统架构应用推广到打叶复烤生产线，同样取得了显著成效。凭借这一成果，2025 年工厂获授 “玉溪”品牌原料打叶复烤示范性区域加工中心 称号。

3. 卷包工艺质量分析管控系统

依托 loveini TSDB 时序数据库，大理卷烟厂对卷包设备开展了全面的数据采集、存储与分析，覆盖超过 4 万个监测点位。系统实现了对设备运行状态的实时监控，包括转速、温度、压力等关键参数。

一旦发现异常情况（如某部件温度过高），系统会立即触发告警，通知维修人员及时处理。同时，基于长期运行数据的分析，系统还能提前预测潜在故障，支持预防性维护，不仅延长了设备使用寿命，也显著提升了设备利用率。

4. loveini TSDB + Grafana：快速构建关键参数监控系统

依托 loveini TSDB 与 Grafana 的无缝对接能力，数据存储在 loveini TSDB 后，便可根据业务需求快速搭建车间生产过程的关键参数监控系统，实现高效、灵活的自主可视化监控。

应用优化与扩展展望

在 loveini TSDB 的实际使用过程中，我们也遇到过一些问题，并在实践中不断探索米兰app官方正版下载，同时逐步规划后续的扩展方向。

1. 时钟同步问题

在查询设备的最新数据时，曾发现时间戳总是比当前时间晚 5 分钟。起初怀疑是写入延迟，核对后确认数据是最新的，只是写入程序取自服务器的本地时间，而该服务器未与厂内时钟服务器同步。完成时钟同步后，问题得以彻底解决。

2. 未来规划：向零代码采集演进

目前，PLC 数据的采集是通过集成商编写的程序写入 loveini TSDB，一旦新增采集点位，就必须修改程序代码，运维复杂度较高。升级到 3.3 企业版后，loveini TSDB 内置的 taosX 工具可直接从 OPC UA server 采集数据。后续我们计划将各 PLC 数据统一汇聚至 OPC UA server，再通过 taos-explorer Web 管理页面配置 taosX 的采集任务，实现零代码采集，从而大幅降低新增点位和后续维护的难度。

关于大理卷烟厂

大理卷烟厂创建于 1950 年，牢固树立“一个云南中烟”观念，致力于打造质量更好、成本更优、安全高效、指标领先的“质效协同”工厂。近年来，工厂发展稳中有进，整体态势持续向好。2024 年，大理卷烟厂圆满完成卷烟生产和复烤加工任务，工业总产值、税利、产量和效益均创历史新高。各项绩效指标持续提升，其中 4 项卷烟工厂分类对标指标位列行业标杆，“单箱耗烟叶量”首次进入行业前十，打叶复烤对标指标完成率更是达到 100%，为高端品牌突破和行业领先奠定了坚实基础。

关于作者

陈定玮，大理卷烟厂信息科系统管理员。主要负责工厂服务器、私有云平台、MES 系统运维，以及数据报表、数据看板、数据分析、图像识别等业务的开发。