助力数字孪生,TDengine在叁零肆零仿真平台中的实践

2021年11月22日 阅读数:1
这篇文章主要向大家介绍助力数字孪生,TDengine在叁零肆零仿真平台中的实践,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

 

做者:黄培健,陈驰 |叁零肆零科技有限公司node

 

小 T 导读:上海叁零肆零科技有限公司致力于能源(气和热)的数字化转型,以现阶段压力和流量监测物联为切入,结合企业已有的信息化数据,利用物联技术解决能源企业的安全运行痛点,助力其提高智慧运营效率。git

 

依托数字孪生和人工智能算法模型,咱们构建了实时反映管网实际运营工况的瞬态的仿真平台。该平台致力于为能源企业提供包括客户认知、需求负荷分析、管网状态监控和优化、多工况计算、气(热)源匹配、通路寻优等一系列数据服务。下图为平台实际运做场景画面。算法

 

在此项目中,构建数字孪生的主要数据来源于如下两个地方:数据库

 

  1. 物联数据:物联设备每5分钟上报一次物联数据;安全

  2. 仿真数据:依托于大量物联设备的接入,将工况数据进行实时对齐上传作仿真求解以此获得仿真数据。服务器

 

在项目即将投入研发测试之际,咱们却发现了一些会影响到项目正常运做的问题——两种数据类型都很是庞大,此前经常使用的数据库难以支撑如此庞大数据量的存储查询等操做。带着这个问题,咱们将目光转移到当前市面上的数据库产品上,试图从中筛选到最适合本项目的数据库。微信

 

波折重重的数据库选型

 

从项目涉及到的数据类型来看,物联数据具备典型的时序数据特色,量大但不会变化,仿真数据的计算结果量一样很大。这两类数据都须要快速的存储、实时的查询响应,但相比于存储来说,查询并不会过于复杂。架构

 

基于以上背景需求,咱们开始进行数据库产品选型。运维

 

首先尝试使用的是非关系数据库MongoDB,在通用数据库中MongoDB已是佼佼者了,可是查询和存储效率仍然都没有达到咱们的预期。在思考事后,咱们从数据类型出发缩小数据库选型范围,最终决定从时序数据库中进行选择。性能

 

咱们率先将目光锁定在当前市面比较流行的时序数据库InfluxDB上,一套测试下来发现,尽管业务需求将将可以知足,但InfluxDB的运维成本过高,并且其集群版并未开源,使用成本不低,所以InfluxDB也排除在咱们的选型范围以外。

 

一次偶然的机会,咱们了解到了时序数据库TDengine,发现这一款数据库性能胜于InfluxDB的同时,甚至把集群也作了开源,方便进行水平扩展,且在成本管控上也达到了最优的状态,轻量化、类SQL的结构设定大幅下降运维和学习成本。在众多优势的推进下,咱们便尝试将TDengine投入测试使用。

 

很是高兴的是,期间咱们在TDengine的官方社群中得到了及时专业的技术支持,最终顺利地把开源版TDengine应用到了项目开发中。而TDengine也没有让咱们失望,成功上线后其在运行上十分高效稳定。

 

具体场景与配置

 

目前咱们选用的TDengine版本是2.2.0.1,单机版暂时毫无压力,但出于业务扩展的需求,同时也在筹备单机横向拓展为集群的工做。

 

在实际操做中,当前服务器配置是“24G内存 + 12核3.60GHzCPU +机械硬盘”。以下图所示,库中共有子表20000+,超级表6张,其中经常使用的有4张表。数据保留日期为10年,数据周增幅大概为1000余万行。

根据涛思数据提供的资料,咱们经过合理的配置参数让数据库的Vnode数量刚好等于计算机的CPU核数,从而能够充分利用计算机性能,顺利完成环境搭建。

 

千万级别数据量的查询效果

 

超级表computing_result保存了全部仿真计算的结果,单表总计21列,单行长度1.8k,当前数据量为千万级别,是咱们的主要查询对象——

 

针对以上的查询数据,具体的查询效果以下:

 

1.查询某些设备的全部仿真计算结果为0.09秒,代码示例以下:

select * from slsl_digital_twin.computing_result r where r.batch_no in ( 'c080018_20211029080000' ) and r.device_id in ( '347444''73593''18146''235652''350382' );

 

2.查询某些设备在必定时间范围内的,最新的压力数据耗时7.8毫秒。

 

3.根据区域id分组,查询该区域下不一样设备的最新数据,耗时9毫秒(因为2.1版本增长了嵌套查询功能,咱们得以更好地实现相对复杂的逻辑去获得查询结果)。代码示例以下:

select sum(pressure) as pressure, sum(flow) as flow, sum(temperature) as temperature,last(on_off) as onOff,gis_id from (select last(pressure) as pressure, last(flow) as flow, last(temperature) as temperature,last(on_off) as on_off  from slsl_digital_twin.enn_iot where in_out_flag = 'OUT' and gis_id in'347444''73593''18146''235652''350382'group by device_id,gis_id ) group by gis_id;

值得一提的是,在实现高效的存储查询性能下,TDengine占用的存储空间不足500MB。但事实上,仅仅computing_result单张超级表的实际数据量理论上就应为(8*2+(40+125+31+225)*4+8*11+2+4*2+10)字节*12409408行数,即21GB左右,更不用提把静态数据抽取出来作成内存里的标签大幅度减小了原数据量。

 

但因为nchar类数据中有部分null值,在本文中咱们没法精准计算压缩率。即使如此,TDengine的表现也已经令咱们足够惊艳了。

 

写在最后

 

将来,随着咱们接入更多城市的管网仿真、爆炸辐射、泄漏预警等计算模型,产生的数据量将会达到10亿+,子表数量也会达到数千万级。TDengine即将上线的3.0版本能够轻松支持亿级别的表数量,这一点让咱们更加期待将来和TDengine的深度合做,同时也对TDengine抱以更大的信心。在合做的过程当中,咱们也会继续探索如何将TDengine应用于更多的业务场景,以更好地知足咱们的各种仿真计算环节的业务需求。

 

关于做者

 

黄培健,叁零肆零架构师。目前负责公司数字孪生项目和公司总体技术架构。

陈驰,叁零肆零高级工程师。目前负责公司数字孪生项目总体开发。

 


 

📣 另外,不要忘记参与今晚⏰20:00TDengine视频号的直播哦!涛思数据研发工程师杨志宇将以 TDengine 为例,和你们一块儿聊聊 JDBC 链接器的设计与实践。

⬆️点击上方视频号进行预定,参与直播。欢迎你们在评论区提问、实时互动,分享嘉宾将会在 QA 环节挑选问题进行回复哦。

 

 


👇点击 阅读原文 ,体验TDengine!

本文分享自微信公众号 - TDengine(taosdata_news)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。