关于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 之后，不论是大批量拉取范畴数据，还是应用函数计算，查问再也没有呈现过浏览器卡死的状况。TDengine 拉取单设施大范畴工夫数据查问的 SQL 以及耗时状况，如以下截图如下：

不得不说，这些查问的性能都非常杰出，齐全满足咱们的利用场景。

第三，搭建集群的老本更低廉。家喻户晓，InfluxDB 集群性能是闭源的，如果后续业务倒退须要用到集群时会带来很大的不便。然而 TDengine 的集群性能是开源的，且扩大不便，因而能够显著升高运维老本。

最初，从用户反对的角度来说，选用国外的 Database 有很大的不确定性，但在应用 TDengine 时如果须要反对，就能够间接通过微信/邮箱等工具随时和技术人员进行交换，更加无效不便。如果对产品性能性能、业务保障要求高的话，就能够随时降级到企业级的服务。

TDengine 落地实际

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

该套制氢零碎除 PEM 制氢劣势外，还具备智能化水平高的特点，采纳的智能控制算法与可再生能源稳定、间歇性特点相符合，兼具高效、经济、平安、智能等劣势，实用于制、储、加一体化制氢我的项目。在这个过程中，咱们会对 TDengine 存储的设施数据进行剖析计算，最初通过大屏展现以达到实时监控、剖析等需要。

整个业务架构大抵如下：以咱们本人编写的 mosbusTCP 驱动，联合数采硬件设施采集设施数据，而后通过 JDBC-RESTful 的形式将数据写入 TDengine。数据采集点总共有 9000 多个，频率为大略每秒写入一次。

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

教训分享

值得一提的是，TDengine 是依据表来做数据分片的，vnode 就是最小单位，在这种状况下，保障数据量平衡的前提是写入量平均，否则如果某些设施过热，某些设施过冷，就会呈现某个 vnode 极大，某个 vnode 极小的状况。

这一点在建表之初是须要思考的，避免工夫过久后，数据过于歪斜。具体调整形式能够参考这篇文章。比方，如果初期的设施热度比拟高的话，就能够调小 minTablesPerVnode，在第一波建表时便把表平均开到不同 vnode 里，这样能够针对性地利用起每个 vnode 有独立写入线程的特点，充分利用计算资源。（上文中的 vnode 截图并不是我的写入不平均，只是单纯的新建表不久还没有写入太多数据。）

此外，在咱们的应用过程中，也有遇到过一些问题。比方应用超级表的 select * 查问时，时间跨度比拟久的数据返回会有些慢，这跟以后版本的架构无关，一个该类查问会生成多个子查问，每个 vnode 的子查问是在服务端串形解决的，即在一个 vnode 中检索查问结束后再查下一个，最初汇总。解决方案是把时间段拆开成多段，应用多线程来查问。依据 TDengine 的布局，在后续的 3.x 版本中，此类查问将会和聚合查问一样变成并行处理，查问效率会大大晋升。而其余问题多为配置部署相干，仔细阅读文档，都能够失去很好的解决。

对于 TDengine 在现有业务体系下的体现，咱们还比较满意，前面也会尝试摸索更多的单干可能，一直为客户发明价值，以技术驱动绿氢产业倒退。

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