作者:冰茹
小 T 导读:和利时始创于 1993 年,业务集中在工业自动化、交通自动化和医疗大健康三大领域,结合自动化与信息化两方面的技术优势,提出了“智能控制、智慧管理、自主可控、安全可信”的战略指导方针。围绕集团三大业务,公司对工业互联网、大数据、5G、信息安全等新兴技术开展更深入的研究和应用示范,打造面向各领域应用的工业互联网平台,进一步促进智能制造解决方案的落地应用。
https://github.com/taosdata/TDengine
在物联网场景下,面对庞大的时序数据处理需求,Oracle、PostgreSQL 等传统关系型数据库越来越吃力。基于此,目前国内外主流工业互联网平台几乎都已经采用时序数据库,来承接海量涌入的工业数据。
究其原因,可以从数据的三个核心需求来解释。我们都知道,企业在选择数据库、文件系统等产品时,最终目的都是为了以最佳性价比来满足数据的三个核心需求:数据写入、数据读取、数据存储。时序数据库完全是按照时序数据的三个需求特征进行设计和开发的,在数据处理上更加具有针对性:
而关系型数据库主要应对的数据特点却大相径庭:
因此,从数据本质的角度而言,时序数据库(不变性、唯一性以及可排序性)和关系型数据库的服务需求完全不同。这也是我们一开始就锁定时序数据库来满足工业互联网场景的核心原因。
我们对包括 InfluxDB、OpenTSDB、HolliTSDB(和利时自研时序数据库)、TDengine 在内的四款时序数据库进行了选型调研及相关测试。测试数据的频率为 1 秒钟,数据集包含 10000 台设备,每台设备有 10000 条记录,每条数据采集记录包含 3 个标签字段、2 个数据字段、1 个时间戳字段。测试对比项包括占用磁盘空间、百万条数据遍历查询、聚合查询(COUNT、AVG、SUM、MAX、MIN)。测试结果如下所示:
同等条件下,TDengine 的压缩率最高,数据占用的存储空间最小;在原始数据查询上,OpenTSDB 最慢,TDengine 与 HolliTSDB 在伯仲之间;在聚合查询操作上,TDengine 最快,HolliTSDB 的速度和 InfluxDB 相当,OpenTSDB 最慢。同时,InfluxDB 只能单机部署,集群版本并未开源,且查询性能存在瓶颈,其 QPS 约为 30-50。
从性能测试结果来看,我们选择 TDengine 的原因主要源于以下几点:
最终我们决定接入 TDengine,以享受更多元的本地化支持和响应。
目前 TDengine 作为边缘版时序数据库在搭建使用,具体的技术架构如下图所示:
基于 TDengine 进行建库建表思路如下:
CREATE STABLE IF NOT EXISTS ts_super
(time TIMESTAMP, s BIGINT, vl BIGINT,vf DOUBLE,vb BOOL,vs BINARY(16349))
TAGS
(innerId BIGINT, namespace BINARY(256), id BINARY(256), type BINARY(1), seq int);
在构建列时,包含元素为 time(时间,主键)、s(数据质量)、vl(整形类型数据 L)、vf(浮点型数据 F)、vb(布尔型数据 B)、vs(字符串数据 S),其中 time、s 是必填的列,剩余列则要根据测点类型填写,比如测点上报的是整形数据,就只需要设置 time、s、vl 这三列,vf、vb、vs 这三列为 null。
在构建 tag 时,要包括 innerId(测点内部编码)、id(测点 id)、type(测点类型,L/F/B/S)、seq (序号,L/F/B 类型数据设置为 0,S 类型测点的 seq 可能为 0,1,2,3...)
同时,在建库建表的操作中我们也碰到了一些小问题,放在这里给大家做下参考:
TDengine 集群 5 个节点,副本数设置为 3。修改配置为:
各节点机器配置如下:
客户端共有三台主机,每台主机上分别运行时序查询及其对应的 AB,各主机上的时序查询独立运行,分别启动一/二/三个时序查询及其对应的 AB 进行性能测试。
共 1000 个测点,80000 万条数据,数据频率为每秒钟 1 条。存储分布如下所示,存储压缩率不超过 1/10。
在我们的业务查询当中,增加 QPS 的主要方式是增加查询的并发数。AB 从 1 到 2,QPS 增加了 45%,平均响应时间不超过 1000ms,很好满足了客户需求。
在查询过程中,数据是相对均匀的分布,但是不同节点的 CPU 消耗仍然有较大的方差。这是由于 TDengine 的 RESTful 的底层是在服务端通过单独的代理线程作为客户端查询,所以会受到请求均匀度的影响。如果 TDengine 在后续可以做代理层面的负载均衡,相信能够缩小这个偏差。
在查询段的节点资源消耗还是相当大的,因为需要对查询请求和结果进行处理。在具体业务中,可以考虑使用 RPC 接口来降低查询服务的 CPU 消耗。
TDengine 在本项目中展现出的性能效果非常显著,推动本次项目快速且高质量落地,实现降本增效的目标。接下来,希望 TDengine 能够在以下两个方向上有更大的进步,也祝愿我们的合作能够越来越紧密:
点击查看活动详情,领走你的iPhone 13 Pro吧!