小 T 导读：目前，北明天时已经在热网监控和能源数据系统上应用了 TDengine Database，相比于 MySQL，当前在存储和查询上都获得了显著提升。在其他项目中，他们也正在加速 TDengine 对其他数据库产品的替代。本文中北明天时分享了关于 TDengine 的应用实践，以供参考。
企业简介
北明天时能源科技（北京）有限公司（简称北明天时）成立于 2000 年，在 2015 年发展成为常山北明（股票代码：000158）的全资子公司。其以智慧能源服务为核心，聚焦政府能源监管系统、公共能源服务行业管控系统、园区和企业综合能源管控系统的建设和服务，致力于将云计算、大数据、物联网和人工智能等先进信息技术与业务应用深度融合，为企业和政府提供 “智慧、节能、低碳” 的全集成解决方案和一体化服务。
项目介绍
我们的智慧供热项目最初是使用 MySQL 来存储历史数据，但随着数据量的上升，查询性能越发难以满足业务需求。为了缓解现状，我们开始研究 TDengine Database，在深入了解后发现它真的是一款适合物联网的时序数据库，甚至可以直接使用 SQL 语句。于是在经过一段时间的测试后，我们果断选择将 TDengine 接入项目。
目前，我们已经在热网监控和能耗分析系统上应用了 TDengine，具体的应用场景如下图标红处所示。
- 热网监控系统
热网监控系统目前包括热源监测和热力站监控，用于实时远程监控热源、热力站等的运行状态，将供热数据进行可视化展示，便于运行管理人员掌握整个供热系统的运行状况。
- 能耗分析系统
用于实时统计、计算和监测系统能耗，建立分级能耗评价体系，通过数据的同比、环比和指标完成度评价，实现对系统能耗情况的全面分析。同时通过能耗排名找出能源浪费的关键点，有针对性地进行改善与优化控制，从而减少能源浪费，实现真正意义上的节能。
在分析之后可以发现，这两个系统都有一个相同的特点，即对数据的实时查询展示有很高的需求，比如实时管理供热系统、能耗趋势实时呈现等。
对于这种由设备产生的高频时序数据的处理，TDengine 无疑是很合适的选择。鉴于其显著的改善效果，在其他项目中我们也正在加速 TDengine 对其他数据库产品的替代。
当然在落地的过程中我们也遇到过一些小问题：比如，旧版本 TDengine 不支持对时间戳的 group by，经过升级后解决。再比如查询时不同客户端得到的表结构并不一样，这是因为客户端的各自缓存的元数据不一致，通过 reset query cache 命令得到了解决。还有一些日常的小问题，我们都在 TDengine 的技术交流群中得到了官方或社区网友的及时反馈和帮助。
一、效果分析
我们以 TDengine 2.2.2.0 版本落地了一个三节点三副本的集群，机器配置为 16C + 32G + 1T 的机械硬盘。具体到实际路径上，我们的设备数据是先经过实时采集写入 Kafka 后，再通过 Python 连接器消费入库的。
在当前环境下，我们共创建了 5,500 多张子表，存储了大概九千万行左右的数据，最大一张超级表的数据接近 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 年北明天时开始积极开拓智慧能源服务新市场，开发包含供热、供冷、供电、供气等能源综合管控系统和智慧水务监管平台。一年之后我们便正式引入了 TDengine 这款优秀的开源时序数据库（Time-Series Database），而 TDengine 也确实没让我们失望。今后，北明天时将和 TDengine 一起，为推动城市能源高效利用、清洁能源替代、创建低碳智慧城市持续做贡献。
作者 | 贾苗苗，北明天时能源科技（北京）有限公司研发工程师
