小 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上查看相关源代码。
