关于tdengine:TDengine-在智慧矿山系统中的应用

小 T 导读：在元智信息的智慧矿山我的项目中，须要一款数据库能撑持起生产交互管控零碎的采运排环节所有过程设施的采集、存储、计算和监控性能。在 MySQL、InfluxDB、TDengine 的数据库选型调研中，TDengine 怀才不遇。本文讲述了他们的选型思路、建模思路以及计划翻新点，作为教训参考分享给有须要的读者。

公司简介

元智信息是国内当先的露天矿业项目管理征询和技术计划提供商。元智公司为全国范畴内的工矿企业提供一站式的技术支持服务， 包含可行性研究剖析、矿山布局与调度、生产评估、生产优化、业务零碎整合、系统集成和软件开发等专项服务。

一、行业背景

智慧矿山是以矿山数字化、信息化为前提和根底，对矿山生产、职业衰弱与平安、技术支持与后勤保障等各方面进行被动感知、主动剖析和疾速解决。建设智慧矿山，首先以建设和实现矿山在生产、平安、经营与治理等环节的信息化为前提，最终实现”矿山一张图”的系统管理指标，开启矿山“通明+智能+管控”的平安生产新模式。

二、应用场景介绍

在整个矿山生产交互管控零碎的采运排环节，须要对所有过程设施进行采集、存储、计算和监控。这些数据涵盖范围广，包含挖机、卡车的采集数据、调度治理数据、设施 GPS 信息、以及每一个固定地位工序的采集数据等。

数据类型

• 采：露天矿山采掘设施，超大型电铲与液压铲。矿山中利用采掘设施进行矿产资源以及覆盖物的开掘工作，在理论利用中，须要采集和监控各个采掘设施的信息，如设施运行参数（像电压和电流等）和地位信息。
• 运：次要是运输环节。在采煤的过程中，须要对大量的剥离物（如表土和岩石）进行排弃，将原煤运输到煤仓、破碎站以及选煤厂。在此过程中，须要通过平安正当的调度来实现矿产附属物及矿品的运输。因而，咱们会实时采集卡车运输设备地位信息、胎压、油耗等信息，以保障平安调度。
• 排：排土工作系指从露天采场将剥离笼罩在矿床上部及其四周的大量表土和岩石，运送到专门设置的场地如（排土场）。次要通过卡车运输来实现。即煤炭开采剥离过程中产生的渣土剥离后通过运输系统排出生产作业区，排土过程中正当布局以达到露天煤矿生态环保过程中的环保作业要求。

数据量级

• 个别大规模的矿山车辆数量，往往超过 800 台。如果是整个团体级别的利用，卡车数量可达 3000 ～ 7000 台。
• 以目前的平安生产要求，卡车的采集频率是 5 ～ 10 秒，在有更高要求的场景中，须要采纳更高的频率，采集的数据内容包含卡车 GPS 定位数据、油耗数据、胎压数据以及卡车的速度信息。
• 以 800 台设施估算，采集频率 5 秒，一天 24 小时会产出大略 1000 多万条数据。这个数据量绝对于传统的数据存储是个比拟大的量级。

数据利用

在理论的利用场景中，对车辆的数据利用，其中一个次要维度就是车辆轨迹，特地是车辆的实时地位必须满足矿山生产的车辆调度实时需要。

三、选型比照

MySQL

MySQL 是咱们团队在各种利用开发畛域应用最多的数据库，从复用技术教训的角度上思考，最后思考过 MySQL 的可行性。然而在通过剖析和验证后，咱们就排除了应用关系型数据库的计划。次要起因如下：

• 存储压力：在最后应用 MySQL 的论证剖析中，因为在 MySQL 中的 InnoDB 存储引擎最小存储单元页的大小是 16 kb 左右， 而 MySQL 以页为根底的查问数据加载时，数据的加载量会带来极大的零碎累赘。并且，MySQL 作为关系型数据库，采纳的是 B+ 树存储构造，初步估算，深度为 3 的 B+ 树预计能撑持 2000 万条左右的数据，这个数据量级是远远满足不了咱们的业务场景的。
• 性能存在瓶颈：在理论验证中，随同着数据量的减少，MySQL 性能急剧下降。

InfluxDB

其次，咱们进行了 InfluxDB 的调研。验证的初级阶段，从查问效率的 QPS 维度看，InfluxDB 的查问问题不大，效率能够满足。然而，在测试智慧矿山的物联网模型查问时，很快遇到了 InfluxDB 对于此类查问实时效率低下的问题，而且设计复杂度也很高。 在 1000 台设施的状况下，须要查所有设施的平均速度，查问实时性要求高。 但 InfluxDB 没有明确的基于设施的建表形式，如果用一张表存所有设施数据，数据量就会很大，查问性能也会降落。比拟显著的是，在百万数据量级以内，这种建表形式查问工夫在 1 秒左右，而当数据到了千万量级的时候，查问效率降落非常显著。 在咱们实在的智慧矿山中、所有设施产生的数据量级条件下，这个查问效率的降落是显著不合乎咱们要求的。

TDengine

最初，咱们调研了 TDengine，这也成了咱们最终选型采纳的计划。其劣势体现如下：

• 技术成本低：网上学习材料多，而且 TDengine 具备装置不便、对运维要求低、反对 SQL 所以学习成本低等个性，极大缩短了我的项目研发周期和开发难度。
• 数据模型符合：TDengine 与智慧矿山比拟符合的是， TDengine 有一个超级表概念，其超级表相似于物联网的物模型，子表相似于具体设施。这一数据模型与智慧矿山的业务零碎也比拟吻合。
• 国产化：目前在矿山利用方面，对国产化要求是很高的。让咱们比拟欣慰的是，即便在非国产化产品的比照中，TDengine 的读写速度和压缩率也是比拟当先的。

性能体现

咱们以智慧矿山业务中的 5000 设施、每天 1000 万采集点的数据量级下，在以车建模和以地位建模联合的数据模型下，TDengine 的性能远没有达到极限，目前零碎对于车和地位的查问速度都在毫秒级。

四、计划落地

建模思路

在智慧矿山的理论利用场景中，模型是一个要害设计，在咱们应用 TDengine 的查问场景中，数据模型的设计跟查问是关联在一起的。 比方在咱们的零碎中，在更关注单体设施的查问的场景中，咱们采纳“一个设施一张表”的建模形式；而在智慧矿山的“电子围栏”业务中，咱们则采纳了以地位建模的形式，这样不便零碎基于地位进行统计和查问，具体建模思路参考如下：

• 以车建模：这种建模以车为指标统计，能够很好地解决零碎中波及车和各种设施的运行状况的统计查问问题。
• 以地位建模：采纳了基于固定地位建模的形式。以工艺和流程地位建模，能够解决设施通过某些点的统计问题，查问效率明显提高。
  

计划翻新

在涛思数据的工程师的倡议下，咱们能够在 MySQL 数据库里，把所有的设施表的名字（TDengine 中的 tbname）进行了存储。咱们在去 TDengine 中进行设施查问的时候，子表名从关系数据库中间接读取，而后在 TDengine 中针对子表进行查问。这个设计，在零碎中针对单个设施进行疾速数据回放的时候，也明显提高了查问效率。

技术架构图

最终成果展现

目前，像咱们的智慧矿山零碎中，TDengine 的利用查问用于监控性能指标，次要查问内容：

• 地位信息：地位信息包含零碎中每一个车辆，或者对每一个现场的坐标地位，以及现场的电子围栏的地位信息等。
• 车辆速度：矿山的平安生产作业对卡车驾驶速度作出限度，速度不能超过 40 km/h，超速数据须要实时揭示，对超速车辆进行确认并响应。

基于下面的数据管理，咱们的矿山一张图零碎，就是把车、铲等时序的数据，以及相干调度的信息，对立治理起来。简略说就是车、铲怎么样达到最优化的配比。 查问后果如下：

五、写在最初

对 TDengine 的长远规划

本次在内蒙古露天矿山卡车调度中首次应用 TDengine，咱们在构建智慧矿山零碎中有了很多新的思路，更让咱们对它的简略易用以及令人惊叹的高性能产生了更多期待。基于目前对 TDengine 的了解和应用教训，咱们打算在如下场景中进一步应用它来欠缺咱们的零碎：

• 环保监测：矿山对环保的要求越来越高，次要集中在环保监测这部分业务。个别状况下，整个矿山基本上是 30 台到 50 台环保监测设施。这部分数据数据更新频率不是太大，采集频率 20 秒即可，数据量很适宜用 TDengine 来进行解决。
• 生产集控设施：TDengine 的数据模型比拟适宜做这部分业务。传统意义上，在整个生产集控设施上，管制设施都是应用实时数据库来存储的。工夫序列属性也比拟适宜时序数据的特色——查问为主，更新和删除很少。TDengine 对时序数据的查问劣势，能够在卡车调度零碎中更快的对设施进行调度。咱们正在调研 TDengine 中的数据订阅，这种形式应该能够很好地适配这些场景。

想理解更多TDengine的具体细节，欢送大家在GitHub上查看相干源代码。