从四种时序数据库选型中脱颖而出，TDengine在工控领域边缘侧的应用

从四种时序数据库选型中脱颖而出，TDengine在工控领域边缘侧的应用

作者：冰茹

小 T 导读：和利时始创于 1993 年，业务集中在工业自动化、交通自动化和医疗大健康三大领域，结合自动化与信息化两方面的技术优势，提出了“智能控制、智慧管理、自主可控、安全可信”的战略指导方针。围绕集团三大业务，公司对工业互联网、大数据、5G、信息安全等新兴技术开展更深入的研究和应用示范，打造面向各领域应用的工业互联网平台，进一步促进智能制造解决方案的落地应用。

https://github.com/taosdata/TDengine

在物联网场景下，面对庞大的时序数据处理需求，Oracle、PostgreSQL 等传统关系型数据库越来越吃力。基于此，目前国内外主流工业互联网平台几乎都已经采用时序数据库，来承接海量涌入的工业数据。

究其原因，可以从数据的三个核心需求来解释。我们都知道，企业在选择数据库、文件系统等产品时，最终目的都是为了以最佳性价比来满足数据的三个核心需求：数据写入、数据读取、数据存储。时序数据库完全是按照时序数据的三个需求特征进行设计和开发的，在数据处理上更加具有针对性：

在数据写入上，如果将时间看作一个主坐标轴，时序数据通常是按照时间顺序抵达，抵达的数据几乎总是作为新条目被记录，在数据处理 *** 作上 95%-99%都是写入 *** 作；在数据读取上，随机位置的单个测量读取、删除 *** 作几乎没有，读取和删除都是批量的，从某时间点开始的一段时间内读取的数据可能非常巨大；在数据存储上，时序数据结构简单，价值随时间推移迅速降低，通常都是通过压缩、移动、删除等手段来降低存储成本。

而关系型数据库主要应对的数据特点却大相径庭：

数据写入：大多数 *** 作都是 DML *** 作，插入、更新、删除等数据读取：读取逻辑一般都比较复杂数据存储：很少压缩，一般也不设置数据生命周期管理

因此，从数据本质的角度而言，时序数据库（不变性、唯一性以及可排序性）和关系型数据库的服务需求完全不同。这也是我们一开始就锁定时序数据库来满足工业互联网场景的核心原因。

一、时序数据库选型

我们对包括 InfluxDB、OpenTSDB、HolliTSDB（和利时自研时序数据库）、TDengine 在内的四款时序数据库进行了选型调研及相关测试。测试数据的频率为 1 秒钟，数据集包含 10000 台设备，每台设备有 10000 条记录，每条数据采集记录包含 3 个标签字段、2 个数据字段、1 个时间戳字段。测试对比项包括占用磁盘空间、百万条数据遍历查询、聚合查询（COUNT、AVG、SUM、MAX、MIN）。测试结果如下所示：

占用磁盘空间

百万条数据遍历查询

聚合查询 COUNT

聚合查询 AVG

聚合查询 SUM

聚合查询 MAX

聚合查询 MIN

同等条件下，TDengine 的压缩率最高，数据占用的存储空间最小；在原始数据查询上，OpenTSDB 最慢，TDengine 与 HolliTSDB 在伯仲之间；在聚合查询 *** 作上，TDengine 最快，HolliTSDB 的速度和 InfluxDB 相当，OpenTSDB 最慢。同时，InfluxDB 只能单机部署，集群版本并未开源，且查询性能存在瓶颈，其 QPS 约为 30-50。

从性能测试结果来看，我们选择 TDengine 的原因主要源于以下几点：

TDengine 在查询性能维度上的表现非常优异，满足了我们的业务查询需求集群功能开源，方便横向扩展，更d性在开源热潮之下，支持如 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 字符串最长可以有 16374 字节 ，超过的话需要从逻辑上处理。我们采用的方案是如果长度超过 16374 ，截取该字符串，同一个测点再建新的表，通过 tag 关联。

三、实际效果展示

1. 数据库配置

TDengine 集群 5 个节点，副本数设置为 3。修改配置为：

minTablesPerVnode 10tableIncStepPerVnode 10compressMsgSize 1024rpcForceTcp 1httpMaxThreads 16

各节点机器配置如下：

2. 查询客户端配置

客户端共有三台主机，每台主机上分别运行时序查询及其对应的 AB，各主机上的时序查询独立运行，分别启动一/二/三个时序查询及其对应的 AB 进行性能测试。

3. 数据说明

共 1000 个测点，80000 万条数据，数据频率为每秒钟 1 条。存储分布如下所示，存储压缩率不超过 1/10。

4. 查询结果

在我们的业务查询当中，增加 QPS 的主要方式是增加查询的并发数。AB 从 1 到 2，QPS 增加了 45%，平均响应时间不超过 1000ms，很好满足了客户需求。

5. 资源消耗(统计 3 个查询服务的实例)

TDengine node 节点资源消耗

在查询过程中，数据是相对均匀的分布，但是不同节点的 CPU 消耗仍然有较大的方差。这是由于 TDengine 的 RESTful 的底层是在服务端通过单独的代理线程作为客户端查询，所以会受到请求均匀度的影响。如果 TDengine 在后续可以做代理层面的负载均衡，相信能够缩小这个偏差。

6. 查询服务资源消耗

在查询段的节点资源消耗还是相当大的，因为需要对查询请求和结果进行处理。在具体业务中，可以考虑使用 RPC 接口来降低查询服务的 CPU 消耗。

四、写在最后

TDengine 在本项目中展现出的性能效果非常显著，推动本次项目快速且高质量落地，实现降本增效的目标。接下来，希望 TDengine 能够在以下两个方向上有更大的进步，也祝愿我们的合作能够越来越紧密：

希望可以通过触发器或协处理器等方式，在服务端做数据过滤再返回，解决网络压力过大的问题希望能够进一步改善长度限制的问题

---

点击查看活动详情，领走你的iPhone 13 Pro吧！