作者：黄培健，陈驰|叁零肆零科技倒退有限公司
小 T 导读：上海叁零肆零科技有限公司致力于能源（气和热）的数字化转型，以现阶段压力和流量监测物联为切入，联合企业已有的信息化数据，利用物联技术解决能源企业的平安运行痛点，助力其晋升智慧经营效率。
依靠数字孪生和人工智能算法模型，咱们构建了实时反映管网理论经营工况的瞬态的仿真平台。该平台致力于为能源企业提供包含客户认知、需要负荷剖析、管网状态监控和优化、多工况计算、气 (热) 源匹配、通路寻优等一系列数据服务。下图为平台理论运作场景画面。
在此我的项目中，构建数字孪生的次要数据来源于以下两个中央：
- 物联数据：物联设施每 5 分钟上报一次物联数据；
- 仿真数据：依靠于大量物联设施的接入，将工况数据进行实时对齐上传做仿真求解以此失去仿真数据。
在我的项目行将投入研发测试之际，咱们却发现了一些会影响到我的项目失常运作的问题——两种数据类型都十分宏大，此前罕用的数据库难以撑持如此宏大数据量的存储查问等操作。带着这个问题，咱们将眼光转移到以后市面上的数据库产品上，试图从中筛选到最适宜本我的项目的数据库。
挫折重重的数据库选型
从我的项目波及到的数据类型来看，物联数据具备典型的时序数据特点，量大但不会变动，仿真数据的计算结果量同样很大。这两类数据都须要疾速的存储、实时的查问响应，但相比于存储来讲，查问并不会过于简单。
基于以上背景需要，咱们开始进行数据库产品选型。
首先尝试应用的是非关系数据库 MongoDB，在通用数据库中 MongoDB 曾经是佼佼者了，然而查问和存储效率依然都没有达到咱们的预期。在思考过后，咱们从数据类型登程放大数据库选型范畴，最终决定从时序数据库中进行抉择。
咱们率先将眼光锁定在以后市面比拟风行的时序数据库 InfluxDB 上，一套测试下来发现，只管业务需要将将可能满足，但 InfluxDB 的运维老本太高，而且其集群版并未开源，应用老本不低，因而 InfluxDB 也排除在咱们的选型范畴之外。
一次偶尔的机会，咱们理解到了时序数据库 TDengine，发现这一款数据库性能胜于 InfluxDB 的同时，甚至把集群也做了开源，不便进行程度扩大，且在老本管控上也达到了最优的状态，轻量化、类 SQL 的构造设定大幅升高运维和学习老本。在泛滥长处的推动下，咱们便尝试将 TDengine 投入测试应用。
非常高兴的是，期间咱们在 TDengine 的官网社群中取得了及时业余的技术支持，最终顺利地把开源版 TDengine 利用到了我的项目开发中。而 TDengine 也没有让咱们悲观，胜利上线后其在运行上非常高效稳固。
具体场景与配置
目前咱们选用的 TDengine 版本是 2.2.0.1，单机版临时毫无压力，但出于业务扩大的需要，同时也在筹备单机横向拓展为集群的工作。
在实际操作中，以后服务器配置是“24G 内存 + 12 核 3.60GHzCPU + 机械硬盘”。如下图所示，库中共有子表 20000+，超级表 6 张，其中罕用的有 4 张表。数据保留日期为 10 年，数据周增幅大略为 1000 余万行。
依据涛思数据提供的材料，咱们通过正当的配置参数让数据库的 Vnode 数量恰好等于计算机的 CPU 核数，从而能够充沛利用计算机性能，顺利完成环境搭建。
千万级别数据量的查问成果
超级表 computing_result 保留了所有仿真计算的后果，单表总计 21 列，单行长度 1.8k，以后数据量为千万级别，是咱们的次要查问对象——
针对以上的查问数据，具体的查问成果如下：
1. 查问某些设施的所有仿真计算结果为 0.09 秒，代码示例如下：
select * from slsl_digital_twin.computing_result r where r.batch_no in ('c080018_20211029080000') and r.device_id in ('347444', '73593', '18146', '235652', '350382');
2. 查问某些设施在肯定工夫范畴内的，最新的压力数据耗时 7.8 毫秒。
3. 依据区域 id 分组，查问该区域下不同设施的最新数据，耗时 9 毫秒（因为 2.1 版本减少了嵌套查问性能，咱们得以更好地实现绝对简单的逻辑去失去查问后果）。代码示例如下：
select sum(pressure) as pressure, sum(flow) as flow, sum(temperature) as temperature,last(on_off) as onOff,gis_id from (select last(pressure) as pressure, last(flow) as flow, last(temperature) as temperature,last(on_off) as on_off from slsl_digital_twin.enn_iot where in_out_flag = 'OUT' and gis_id in('347444', '73593', '18146', '235652', '350382') group by device_id,gis_id ) group by gis_id;
值得一提的是，在实现高效的存储查问性能下，TDengine 占用的存储空间有余 500MB。但事实上，仅仅 computing_result 单张超级表的理论数据量实践上就应为（82+（40+125+31+225）4+811+2+42+10）字节 *12409408 行数，即 21GB 左右，更不必提把静态数据抽取进去做成内存里的标签大幅度缩小了原数据量。
但因为 nchar 类数据中有局部 null 值，在本文中咱们无奈精准计算压缩率。即便如此，TDengine 的体现也曾经令咱们足够惊艳了。
写在最初
将来，随着咱们接入更多城市的管网仿真、爆炸辐射、透露预警等计算模型，产生的数据量将会达到 10 亿 +，子表数量也会达到数千万级。TDengine 行将上线的 3.0 版本能够轻松反对亿级别的表数量，这一点让咱们更加期待将来和 TDengine 的深度单干，同时也对 TDengine 抱以更大的信念。在单干的过程中，咱们也会持续摸索如何将 TDengine 利用于更多的业务场景，以更好地满足咱们的各类仿真计算环节的业务需要。
对于作者
黄培健，叁零肆零架构师。目前负责公司数字孪生我的项目和公司整体技术架构。
陈驰，叁零肆零高级工程师。目前负责公司数字孪生我的项目整体开发。
✨想理解更多 TDengine 的具体细节，欢送大家在 GitHub 上查看相干源代码哦。✨