乐趣区

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

jiezi

作者：冰茹

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

在物联网场景下，面对宏大的时序数据处理需要，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 在查问性能维度上的体现十分优异，满足了咱们的业务查问需要
  • 集群性能开源，不便横向扩大，更弹性
  • 在开源热潮之下，反对如 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 10
  • tableIncStepPerVnode 10
  • compressMsgSize 1024
  • rpcForceTcp 1
  • httpMaxThreads 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 等你带回家！

退出移动版