小 T 导读:在元智信息的智慧矿山项目中,需要一款数据库能支撑起生产交互管控系统的采运排环节所有过程设备的采集、存储、计算和监控功能。在 MySQL、InfluxDB、TDengine 的数据库选型调研中,TDengine 脱颖而出。本文讲述了他们的选型思路、建模思路以及方案创新点,作为经验参考分享给有需要的读者。
公司简介
元智信息是国内领先的露天矿业项目管理咨询和技术方案提供商。元智公司为全国范围内的工矿企业提供一站式的技术支持服务, 包括可行性研究分析、矿山规划与调度、生产评估、生产优化、业务系统整合、系统集成和软件开发等专项服务。
一.
行业背景
智慧矿山是以矿山数字化、信息化为前提和基础,对矿山生产、职业健康与安全、技术支持与后勤保障等各方面进行主动感知、自动分析和快速处理。建设智慧矿山,首先以建设和实现矿山在生产、安全、经营与管理等环节的信息化为前提,最终实现'矿山一张图'的系统管理目标,开启矿山“透明 智能 管控”的安全生产新模式。
二.
使用场景介绍
数据类型
数据量级
一般大规模的矿山车辆数量,往往超过 800 台。如果是整个集团级别的应用,卡车数量可达 3000 ~ 7000 台。
以目前的安全生产要求,卡车的采集频率是 5 ~ 10 秒,在有更高要求的场景中,需要采用更高的频率,采集的数据内容包括卡车 GPS 定位数据、油耗数据、胎压数据以及卡车的速度信息。
以 800 台设备估算,采集频率 5 秒,一天 24 小时会产出大概 1000 多万条数据。这个数据量相对于传统的数据存储是个比较大的量级。
数据应用
在实际的应用场景中,对车辆的数据应用,其中一个主要维度就是车辆轨迹,特别是车辆的实时位置必须满足矿山生产的车辆调度实时需求。
三.
选型对比
MySQL
MySQL 是我们团队在各种应用开发领域使用最多的数据库,从复用技术经验的角度上考虑,最初考虑过 MySQL 的可行性。但是在经过分析和验证后,我们就排除了使用关系型数据库的方案。主要原因如下:
InfluxDB
其次,我们进行了 InfluxDB 的调研。验证的初级阶段,从查询效率的 QPS 维度看,InfluxDB 的查询问题不大,效率可以满足。但是,在测试智慧矿山的物联网模型查询时,很快遇到了 InfluxDB 对于此类查询实时效率低下的问题,而且设计复杂度也很高。在 1000 台设备的情况下,需要查所有设备的平均速度,查询实时性要求高。
但 InfluxDB 没有明确的基于设备的建表方式,如果用一张表存所有设备数据,数据量就会很大,查询性能也会下降。比较明显的是,在百万数据量级以内,这种建表方式查询时间在 1 秒左右,而当数据到了千万量级的时候,查询效率下降十分明显。
在我们真实的智慧矿山中、所有设备产生的数据量级条件下,这个查询效率的下降是明显不符合我们要求的。
TDengine
性能表现
我们以智慧矿山业务中的 5000 设备、每天 1000 万采集点的数据量级下,在以车建模和以位置建模结合的数据模型下,TDengine 的性能远没有达到极限,目前系统对于车和位置的查询速度都在毫秒级。
四.
方案落地
建模思路
以车建模:这种建模以车为目标统计,可以很好地解决系统中涉及车和各种设备的运行情况的统计查询问题。
以位置建模:采用了基于固定位置建模的方式。以工艺和流程位置建模,可以解决设备经过某些点的统计问题,查询效率明显提高。
方案创新
在涛思数据的工程师的建议下,我们在 MySQL 数据库里把所有的设备表的名字(TDengine 中的 tbname)进行了存储。我们在去 TDengine 中进行设备查询的时候,子表名从关系数据库中直接读取,然后在 TDengine 中针对子表进行查询。这个设计,在系统中针对单个设备进行快速数据回放的时候,也明显提高了查询效率。
技术架构图
最终效果展示
目前,像我们的智慧矿山系统中,TDengine 的应用查询用于监控性能指标,主要查询内容:
五.
写在最后
对 TDengine 的长远规划
环保监测:矿山对环保的要求越来越高,主要集中在环保监测这部分业务。一般情况下,整个矿山基本上是 30 台到 50 台环保监测设备。这部分数据数据更新频率不是太大,采集频率 20 秒即可,数据量很适合用 TDengine 来进行处理。
生产集控设备:TDengine 的数据模型比较适合做这部分业务。传统意义上,在整个生产集控设备上,控制设备都是使用实时数据库来存储的。时间序列属性也比较适合时序数据的特征——查询为主,更新和删除很少。TDengine 对时序数据的查询优势,可以在卡车调度系统中更快的对设备进行调度。我们正在调研 TDengine 中的数据订阅,这种方式应该可以很好地适配这些场景。
联系客服