小 T 导读：目前，北今天时曾经在热网监控和能耗剖析零碎上利用了 TDengine，相比于 MySQL，以后在存储和查问上都取得了显著晋升。在其余我的项目中，他们也正在减速 TDengine 对其余数据库产品的代替。本文中北今天时分享了对于 TDengine 的利用实际，以供参考。
企业简介
北今天时能源科技（北京）有限公司（简称北今天时）成立于 2000 年，在 2015 年倒退成为常山北明（股票代码：000158）的全资子公司。其以智慧能源服务为外围，聚焦政府能源监管零碎、公共能源服务行业管控零碎、园区和企业综合能源管控零碎的建设和服务，致力于将云计算、大数据、物联网和人工智能等先进信息技术与业务利用深度交融，为企业和政府提供“智慧、节能、低碳”的全集成解决方案和一体化服务。
我的项目介绍
咱们的智慧供热我的项目最后是应用 MySQL 来存储历史数据，但随着数据量的回升，查问性能越发难以满足业务需要。为了缓解现状，咱们开始钻研 TDengine，在深刻理解后发现它真的是一款适宜物联网的时序数据库，甚至能够间接应用 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 这款优良的开源时序数据库，而 TDengine 也的确没让咱们悲观。今后，北今天时将和 TDengine 一起，为推动城市能源高效利用、清洁能源代替、创立低碳智慧城市继续做奉献。
作者 | 贾苗苗，北今天时能源科技（北京）有限公司研发工程师
想理解更多 TDengine 的具体细节，欢送大家在 GitHub 上查看相干源代码。