其他分享
首页 > 其他分享> > 从 InfluxDB 到 TDengine,阳光氢能为什么会做出这个选择?

从 InfluxDB 到 TDengine,阳光氢能为什么会做出这个选择?

作者:互联网

小 T 导读:为了更好地支持阳光氢能 PEM 绿电制氢系统,本文作者所在的部门需要寻找一套满足业务和性能需求、而且具有国产知识产权的时序数据库,来替代原本使用的 InfluxDB。本文分享了他们将 InfluxDB 替换为 TDengine 的具体原因,以及相关的实践思路。

企业简介

阳光电源成立于 1997 年,专注于逆变器的自主研发与制造。经过二十多年的技术积累,集团逐渐确立在光伏逆变器领域的龙头地位,打造了风、光、储、氢的新能源完整格局,做到传统业务和创新业务双管齐下、协同发展。

项目介绍

在碳中和这个大背景下,氢能是新能源领域中与油气行业现有业务结合最紧密的一类,也是帮助油气行业早日实现碳达峰、碳中和的最佳路径之一。2022 年 7 月 16 日,阳光氢能 200Nm³/h PEM 绿电制氢系统启运发货。该套系统采用国内领先的 PEM 电解水制氢技术和 IGBT 制氢电源,工艺复杂,涉及多项国内专利技术。为了更好地监测整体生产流程数据,我们需要寻找一套满足业务和性能需求,而且具有国产知识产权的时序数据库(Time Series Database),以响应国家信创号召。图片

时序数据库选型之 InfluxDB vs TDengine

在 InfluxDB 和 TDengine 之间,之所以选择 TDengine ,其实我很早之前就写过一篇文章,题目是《从 InfluxDB 到 TDengine,我们为什么会做出这个选择》,在其中表述的比较清楚了。这里可以再简单总结一下:

第一,TDengine 超级表和普通表的概念非常契合我们项目的业务场景。此前我们的项目是一个站点一个单元对应多个测点,现在利用超级表-普通表的模型,业务模型会更加清晰。

第二,查询更具有优势。在使用老版 InfluxDB 的历史数据查询功能时,只要操作稍微频繁一点(比如选择一个时间段之后,曲线很久还没有渲染出来,又去换了一个时间段),就会导致页面卡死,取不到数据,这时候需要重启浏览器,极度影响客户体验。

TDengine Database

但是在使用 TDengine 之后,不论是大批量拉取范围数据,还是使用函数计算,查询再也没有出现过浏览器卡死的情况。TDengine 拉取单设备大范围时间数据查询的 SQL 以及耗时情况,如以下截图如下:

TDengine Database   TDengine Database

不得不说,这些查询的性能都十分出色,完全满足我们的应用场景。

第三,搭建集群的成本更低廉。众所周知,InfluxDB 集群功能是闭源的,如果后续业务发展需要用到集群时会带来很大的不便。然而 TDengine 的集群功能是开源的,且扩展方便,因此可以显著降低运维成本。

最后,从用户支持的角度来说,选用国外的 Database 有很大的不确定性,但在使用 TDengine 时如果需要支持,就可以直接通过微信/邮箱等工具随时和技术人员进行交流,更加有效方便。如果对产品性能功能、业务保障要求高的话,就可以随时升级到企业级的服务。

TDengine 落地实践

在我们的这套系统中应用的 TDengine 版本为 2.4.0.0,主要用于存储大量设备产生的时序数据,我们整个项目的智能化都是基于这些数据展开。采集设备主要为碱液循环泵、脱氧塔、纯水机、电解槽等制氢设备。

该套制氢系统除 PEM 制氢优势外,还具有智能化程度高的特点,采用的智能控制算法与可再生能源波动、间歇性特点相契合,兼具高效、经济、安全、智能等优势,适用于制、储、加一体化制氢项目。在这个过程中,我们会对 TDengine 存储的设备数据进行分析计算,最后通过大屏展示以达到实时监控、分析等需求。

TDengine Database

整个业务架构大致如下:以我们自己编写的 mosbusTCP 驱动,结合数采硬件设备采集设备数据,然后通过 JDBC-RESTful 的方式将数据写入 TDengine。数据采集点总共有 9000 多个,频率为大概每秒写入一次。

TDengine Database

目前单列模型下,最大的超级表已经保留了几百亿行的的数据,当前磁盘占用 55GB 左右的空间,压缩比大概在 10-15% 之间。

TDengine Database   TDengine Database

经验分享

值得一提的是,TDengine 是根据表来做数据分片的,vnode 就是最小单位,在这种情况下,保证数据量均衡的前提是写入量均匀,否则如果某些设备过热,某些设备过冷,就会出现某个 vnode 极大,某个 vnode 极小的情况。

这一点在建表之初是需要考虑的,防止时间过久后,数据过于倾斜。具体调整方式可以参考这篇文章。比如,如果初期的设备热度比较高的话,就可以调小 minTablesPerVnode,在第一波建表时便把表均匀开到不同 vnode 里,这样可以针对性地利用起每个 vnode 有独立写入线程的特点,充分利用计算资源。(上文中的 vnode 截图并不是我的写入不均匀,只是单纯的新建表不久还没有写入太多数据。)

此外,在我们的使用过程中,也有遇到过一些问题。比如使用超级表的 select * 查询时,时间跨度比较久的数据返回会有些慢,这跟当前版本的架构有关,一个该类查询会生成多个子查询,每个 vnode 的子查询是在服务端串形处理的,即在一个 vnode 中检索查询完毕后再查下一个,最后汇总。解决方案是把时间段拆开成多段,使用多线程来查询。根据 TDengine 的规划,在后续的 3.x 版本中,此类查询将会和聚合查询一样变成并行处理,查询效率会大大提升。而其他问题多为配置部署相关,仔细阅读文档,都可以得到很好的解决。

对于 TDengine 在现有业务体系下的表现,我们还比较满意,后面也会尝试探索更多的合作可能,不断为客户创造价值,以技术驱动绿氢产业发展。

 


想了解更多 TDengine Database的具体细节,欢迎大家在GitHub上查看相关源代码。

 

 

   

 

标签:制氢,TDengine,InfluxDB,vnode,氢能,查询,数据
来源: https://www.cnblogs.com/taosdata/p/16612414.html