社区的小伙伴们是否关注了 2022 年 05 月 11 日,CCF-CnosDB 论坛里土木工程教授汇报了时序数据在桥梁监测的运用,本期我们就延续话题,继续和大家来聊聊时序数据库在桥梁监测领域中的应用。
本文仅代表个人观点,如有偏颇之处,还请海涵~
众所周知,桥梁结构健康监测的重要性不言而喻,中国是基建大国,为了提升人们的出行便利度,近年来,我们可以看到各种新建的高架桥、轻轨桥等。我们可以说,大型的桥梁建筑已经遍布于中国各个角落。我国现有公路桥 5000 余座,总长 130 万公里,1/3 以上的桥梁都存在结构性缺陷、不同程度的损伤和功能性失效的隐患。因此,为了人民群众的安全,对桥梁安全状况的了然于胸是非常必要的。在不同的气候、交通以及运营条件下,通过对变形(沉降、位移、倾斜)、应力、动力特性、温度、外观等数据的持续采集与测量,桥梁自身其实可以提供给我们很多信息,以此作为预警信号,这也是我们提供维修与保障的重要依据。同时,也便于我们及时采取措施达到防止桥梁坍塌、局部破坏,保障和延长桥梁的使用寿命的目的。
传统存储方案的问题
桥梁结构监测的数据存储传统上一直采用关系型数据库进行,其需要为监控、统计、分析、告警、管理等模块提供数据访问服务,不过关系型数据库在桥梁监测场景上也带来两大主要问题。第一,需要海量存储设备,存储成本节节攀升。要想精准地反映桥梁结构振动,采样频率一般要远高于 50 Hz。我们仅以使用频率为 50 Hz 的加速度传感器为例,每天有 432 万条数据,单索引的情况下占用存储约为 4 GB,存储 1 年则需要约 2TB 的磁盘空间。通过这个例子,我们不难发现,由于数据增长对磁盘空间的需求呈指数增长,普通的磁盘阵列的容量无法满足海量数据的存储需求。第二,数据检索查询效率不足,我们无法在秒级甚至毫秒级获取所需要的数据断面。传统关系型数据库采用分区、索引等方式增强检索效率,但随着存储容量指数级增长,其效率也会逐步下降。因此,针对高密度监测数据的实时访问需求愈发凸显。
时序数据库解决痛点
我们先来看下桥梁监控系统得总体架构情况,其主要由 4 部分构成:其一,是 ETL 工具,它为传感器数据提供实时监控服务,使用 ETL 处理实时数据,按照桥梁监测规范监测传感器数据。第二,为了将告警消息及时传给用户,使用分布式消息系统 Kafka 将告警数据传给在线用户。第三,就是我们所讲的时序数据库,ETL 可以重复在时序数据库中运行查询,然后在查询结果上分析数据,其会将分析结果发送给时序数据库进行存储。最后,就是传统得关系型数据库,比如 MySQL 还是由其来存储大量得一般业务数据,,架构图如下所示.
![](https://i-blog.csdnimg.cn/blog_migrate/d3e7447e8dcae245cb928c75d57788f9.png)
在此架构中时序数据库处于核心得位置,因为其能针对传感器数据中时间标签的唯一性,存储高频变化的海量数据,同时还能实现对海量数据的快速访问。本次得案例中,我们就是采用了 CnosDB 作为时序数据存储引擎,其内置 HTTP API,方便存储和检索,数据可以被标记,允许非常灵活的查询。数据应用服务主要包括实时数据服务、历史数据服务、故障诊断预警服务、设备管理服务、巡检管理服务、用户管理服务。其中,实时、历史数据由 CnosDB 提供数据支持,故障诊断预警服务通过 ETL 进行分析诊断,分布式消息系统 Kafka 负责数据消息分发。
时序数据库解决了一直以来传统存储方案下采集信息不全、采集频率低等问题,其可以大为改变依赖管理者和技术人员经验的模式,通过对桥梁状况的实时全面了解,从而抓住最佳的维修和养护时机。
质量安全永远是工程建设最重要的主题,桥梁工程也不例外。我们要确保桥梁能够长时间使用,就必须坚持“建养并重”,前期建设和后期养护工作二者缺一不可,同等重要。伴随着 TSDB 技术的兴起,相信越来越多的工程建设企业可以利用 TSDB 产品的性能优势来保障桥梁“高寿命”运营。
本文参考了《现代电子技术》期刊中由韩艺坤等所著的《基于InfluxDB的桥梁监测系统设计与实现》一文。
CnosDB 简介
CnosDB 是一款高性能、高易用性的开源分布式时序数据库,现已正式发布及全部开源。
欢迎关注我们的代码仓库,一键三连🙇🙇🙇:https://github.com/cnosdb/cnosdb