时序数据库在桥梁监测领域中的应用

时序数据库在桥梁监测领域中的应用

众所周知，桥梁结构健康监测的重要性不言而喻，中国是基建大国，为了提升人们的出行便利度，近年来，我们可以看到各种新建的高架桥、轻轨桥等。我们可以说，大型的桥梁建筑已经遍布于中国各个角落。我国现有公路桥 5000 余座，总长 130 万公里，1/3 以上的桥梁都存在结构性缺陷、不同程度的损伤和功能性失效的隐患。因此，为了人民群众的安全，对桥梁安全状况的了然于胸是非常必要的。在不同的气候、交通以及运营条件下，通过对变形(沉降、位移、倾斜)、应力、动力特性、温度、外观等数据的持续采集与测量，桥梁自身其实可以提供给我们很多信息，以此作为预警信号，这也是我们提供维修与保障的重要依据。同时，也便于我们及时采取措施达到防止桥梁坍塌、局部破坏，保障和延长桥梁的使用寿命的目的。

传统存储方案的问题

桥梁结构监测的数据存储传统上一直采用关系型数据库进行，其需要为监控、统计、分析、告警、管理等模块提供数据访问服务，不过关系型数据库在桥梁监测场景上也带来两大主要问题。第一，需要海量存储设备，存储成本节节攀升。要想精准地反映桥梁结构振动，采样频率一般要远高于 50 Hz。我们仅以使用频率为 50 Hz 的加速度传感器为例，每天有 432 万条数据，单索引的情况下占用存储约为 4 GB，存储 1 年则需要约 2TB 的磁盘空间。通过这个例子，我们不难发现，由于数据增长对磁盘空间的需求呈指数增长，普通的磁盘阵列的容量无法满足海量数据的存储需求。第二，数据检索查询效率不足，我们无法在秒级甚至毫秒级获取所需要的数据断面。传统关系型数据库采用分区、索引等方式增强检索效率，但随着存储容量指数级增长，其效率也会逐步下降。因此，针对高密度监测数据的实时访问需求愈发凸显。

时序数据库解决痛点

我们先来看下桥梁监控系统得总体架构情况，其主要由 4 部分构成：其一，是 ETL 工具，它为传感器数据提供实时监控服务，使用 ETL 处理实时数据，按照桥梁监测规范监测传感器数据。第二，为了将告警消息及时传给用户，使用分布式消息系统 Kafka 将告警数据传给在线用户。第三，就是我们所讲的时序数据库，ETL 可以重复在时序数据库中运行查询，然后在查询结果上分析数据，其会将分析结果发送给时序数据库进行存储。最后，就是传统得关系型数据库，比如 MySQL 还是由其来存储大量得一般业务数据,，架构图如下所示.

在此架构中时序数据库处于核心得位置，因为其能针对传感器数据中时间标签的唯一性，存储高频变化的海量数据，同时还能实现对海量数据的快速访问。本次得案例中，我们就是采用了 CnosDB 作为时序数据存储引擎，其内置 HTTP API，方便存储和检索，数据可以被标记，允许非常灵活的查询。数据应用服务主要包括实时数据服务、历史数据服务、故障诊断预警服务、设备管理服务、巡检管理服务、用户管理服务。其中，实时、历史数据由 CnosDB 提供数据支持，故障诊断预警服务通过 ETL 进行分析诊断，分布式消息系统 Kafka 负责数据消息分发。

时序数据库解决了一直以来传统存储方案下采集信息不全、采集频率低等问题，其可以大为改变依赖管理者和技术人员经验的模式，通过对桥梁状况的实时全面了解，从而抓住最佳的维修和养护时机。

质量安全永远是工程建设最重要的主题，桥梁工程也不例外。我们要确保桥梁能够长时间使用，就必须坚持“建养并重”，前期建设和后期养护工作二者缺一不可，同等重要。伴随着 TSDB 技术的兴起，相信越来越多的工程建设企业可以利用 TSDB 产品的性能优势来保障桥梁“高寿命”运营。

本文参考了《现代电子技术》期刊中由韩艺坤等所著的《基于InfluxDB的桥梁监测系统设计与实现》一文。

参与CnosDB社区交流群：

扫描下方二维码，加入CC进入CnosDB社区进入社区交流，CC也会在群内分享直播链接哒