：目前，北明天已应用于热网监控和能耗分析系统 TDengine，相比于 MySQL，目前，存储和查询都有了显著的改进。在其他项目中，他们也在加速 TDengine 替代其他数据库产品。本文分享了北方明天的情况 TDengine 应用实践，供参考。
北明天时能源科技(北京)有限公司(以下简称北明天时)成立 2000 年，在 2015 成为常山北明(股票代码:000158)的全资子公司。以智能能源服务为核心，重点建设和服务政府能源监督系统、公共能源服务行业控制系统、园区和企业综合能源控制系统，致力于云计算、大数据、物联网、人工智能等先进信息技术和业务应用，为企业和政府提供服务 智慧、节能、低碳 的全集成解决方案和一体化服务。
项目介绍
我们的智能供热项目最初是使用的 MySQL 存储历史数据，但随着数据量的增加，查询性能越来越难以满足业务需求。为了缓解现状，我们开始研究 TDengine Database，在深入了解后发现它真的是一款适合物联网的时序数据库，甚至可以直接使用 SQL 语句。所以经过一段时间的测试，我们果断地选择了 TDengine 接入项目。
目前，我们已经应用于热网监控和能耗分析系统 TDengine Database，具体应用场景如下图标红处所示。
目前，热网监控系统包括热源监控和热站监控，实时远程监控热源和热站的运行状态，可视化显示供热数据，方便运行管理人员掌握整个供热系统的运行状态。
用于实时统计、计算和监控系统能耗，建立分级能耗评价体系，通过数据同比、环比、指标完成度评价，全面分析系统能耗。同时，通过能耗排名找出能源浪费的关键点，改进和优化控制，减少能源浪费，实现真正的节能。
经过分析，我们可以发现这两个系统都有相同的特点，即对实时数据查询显示的需求很高，如实时管理供热系统、实时能耗趋势等。
处理设备生成的高频时序数据，TDengine 这无疑是一个非常合适的选择。鉴于其显著的改进效果，我们也在加速其他项目 TDengine 替代其他数据库产品。
当然，我们在着陆过程中也遇到了一些小问题：例如，旧版本 TDengine 不支持时间戳 group by，升级后解决。另一个例子是，不同客户端在查询过程中获得的表结构不同，因为客户端缓存的元数据不一致。 reset query cache 解决了命令。还有一些日常小问题，我们都在 TDengine 官方或社区网民及时反馈并帮助了技术交流群。
一、效果分析
我们以 TDengine 2.2.2.0 版本着陆了一个三节点三副本的集群，机器配置为 16C 32G 1T 机械硬盘。在实际路径上，我们的设备数据是实时收集并写入的 Kafka 后，再通过 Python 消费入库的连接器。
我们共同创造了当前的环境 5,500 多张子表存储约9000万行数据，最大超级表数据接近 7,300 万行，单行大概 180 字节。。
：
select sum(Ep) as Ep,sum(HM_HT) as HM_HT ... interval(1d);
SELECT AVG(heatsourcepg) AS heatsourcepg,AVG(heatsourcetg) AS heatsourcetg,AVG(heatsourcef_mtrg) AS heatsourcef_mtrg ... FROM iot_device.source_minute WHERE ts >="2022-04-06 12:00:00" AND ts <"2022-04-06 13:00:00.000" GROUP BY groupid,level
写在最后
2019 2008年明天，我们开始积极开拓智能能源服务新市场，开发供热、冷却、供电、供气等综合能源控制系统和智能水监督平台。一年后，我们正式介绍了它 TDengine 这个优秀的开源时序数据库（Time-Series Database），而 TDengine 我们真的没有失望。未来，北明天将和 TDengine 共同为促进城市能源的高效利用、清洁能源的替代和低碳智能城市的建设做出贡献。
作者 | 北明天时能源科技(北京)研发工程师贾苗苗
想了解更多TDengine欢迎来到具体细节GitHub上查看相关源代码。