MySQL 无法满足查询性能？北明天时选择 TDengine 实现热网监控和能源分析

小 T 导读：目前，北明天已应用于热网监控和能耗分析系统 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 字节。即使在三个副本中，当前磁盘空间也只占用 10.2G，再加上数据过期删除的机制，我们基本上不需要担心磁盘存储的成本。

而内存和 CPU 日常使用率也分别维持 1.9% 和 0.3% 左右，可以说没有压力。

下图是我们的热网监控平台查询业务对应的 SQL，常用的查询基本上是毫秒返回数据：

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