写入性能:TDengine 最高达到 InfluxDB 的 10.3 倍,TimeScaleDB 的 6.74 倍

news2024/12/24 8:10:49

上周三,TDengine 正式发布了基于 TSBS 的时序数据库(Time Series Database,TSDB)性能基准测试报告,该报告采用 TSBS 平台中针对 DevOps 的场景作为基础数据集,在相同的 AWS 云环境下对 TDengine 3.0、TimescaleDB 2.6 和 InfluxDB 1.8 进行了对比分析。为了便于大家更好地阅读和理解,基于报告内容,我们将从写入、查询及测试过程如何复现等几大维度输出系列文章。本篇文章将为大家解读三大时序数据库在写入性能上的差异点。

在《TSBS 是什么?为什么 TDengine 会选择它作为性能对比测试平台?》一文中,我们对测试场景和基本配置已经进行了详细介绍,本篇文章便不再赘述,还没有了解过的小伙伴可以点击上文链接查看。

五大场景下,TDengine 写入性能实现全面超越

不同场景下写入性能的对比(metrics/sec. 数值越大越好)

如上图所示,我们可以看到在全部五个场景中,TDengine 的写入性能全面超越了 TimescaleDB 和 InfluxDB。在场景二中 TDengine 写入性能最大达到了 TimescaleDB 的 6.74 倍,在差距最小的场景五中,TDengine 也是 TimescaleDB 的 1.52 倍。相比 InfluxDB,TDengine 在场景五中写入性能达到 InfluxDB 的 10.63 倍,在差距最小的场景一中也有 3.01 倍,具体的倍率关系请参见下表。

TDengine/InfluxDB

TDengine/TimescaleDB

100 devices × 10 metrics

301.41%

585.63%

4,000 devices × 10 metrics

489.69%

674.12%

100,000 devices × 10 metrics

451.25%

554.07%

1,000,000 devices × 10 metrics

735.38%

286.46%

10,000,000 devices × 10 metrics

1063.46%

152.16%

TDengine 与 InfluxDB、TimescaleDB 的写入性能对比

此外,我们还注意到,随着设备数规模的增加,所有系统写入基本上呈现下降趋势。TimescaleDB 在小规模数据情况下写入性能不及 InfluxDB,但是随着设备数量的增加,其写入性能超过了 InfluxDB。

在数据完全落盘后,我们又比较了一下三个系统在不同场景下的磁盘空间占用情况。

磁盘空间占用(数值越小越优)

可以看到,TimescaleDB 在所有的场景下数据规模均显著地大于 InfluxDB 和 TDengine,并且这种差距随着数据规模增加快速变大——TimescaleDB 在场景四和场景五中占用磁盘空间是 TDengine 的 25 倍。在前面三个场景中,InfluxDB 落盘后数据文件规模与 TDengine 非常接近(在场景二中,TDengine 的数据落盘规模比 InfluxDB 大了 1%),但是在场景四/五两个场景中,InfluxDB 落盘后文件占用的磁盘空间却达到了 TDengine 的 4 倍以上。

写入过程资源消耗对比,InfluxDB>TimescaleDB>TDengine

仅凭数据写入速度,并不能全面地反映出三个系统在不同场景下数据写入的整体表现。为此我们以 1,000,000 devices × 10 metrics(场景四)为数据模板,检查三大数据库在数据写入过程中服务器和客户端的整体负载状况,并以此来对比它们在写入过程中服务器/客户端节点的资源占用情况。这里的资源占用主要包括服务器端的 CPU 开销/磁盘 IO 开销和客户端 CPU 开销。

服务端 CPU 开销

写入过程中服务器 CPU 开销

上图直观地展示出了三大系统在场景四写入过程中的服务器端 CPU 负载状况,在图中我们使用虚线标识出了服务端给客户端确认写入完成的时刻。可以看到,三个系统在返回给客户端写入完成消息以后,都还继续使用服务器资源进行相应的处理工作,这点上,TimescaleDB 尤为明显——TimescaleDB 在 7x 秒时即反馈客户端写入完成,但是其服务器端仍然再调用 CPU 资源进行数据压缩和整理工作,当然整个工作带来的 CPU 负载相对而言并不高,只有其峰值 CPU 开销的一半左右,但是持续时间相当长,接近净写入时间的 4 倍。

InfluxDB 则在写入过程中使用了相当多的 CPU 资源,瞬时峰值甚至使用了全部的 CPU 资源,其写入负载较高,并且持续时间比 TimescaleDB 更长,当然也远长于 TDengine。三个系统对比,TDengine 对服务器的 CPU 需求最小,峰值也仅使用了 17% 左右的服务器 CPU 资源。由此可见,TDengine 独特的数据模型不仅体现在时序数据写入的性能上,在整体的资源开销上优势也极为明显。

磁盘 I/O 对比

写入过程中服务器 IO 开销

图五展示了场景四下数据写入过程中服务器端磁盘 IO 趋势。可以看到,结合着服务器端 CPU 的开销表现,三大系统的 IO 动作与 CPU 呈现同步的活跃状态。写入相同规模的数据集下,TDengine 在写入过程中对于磁盘写入能力的占用远小于 TimescaleDB 和 InfluxDB,写入过程只占用了部分磁盘写入能力(125MiB/Sec. 3000IOPS)。从图上能看到,数据写入过程中磁盘的 IO 瓶颈是确实存在的——InfluxDB 运行中有相当长一段时间将全部的磁盘写入能力消耗殆尽,TimescaleDB 对于写入能力的消耗相对 InfluxDB 来说要更具优势,但是仍然远超过了 TDengine。

客户端 CPU 开销

写入过程中客户端 CPU 开销

从上图可以看到,三个系统在服务器确认写入完成以后客户端均不再有 CPU 开销。客户端上 TDengine 对 CPU 的需求大于 TimescaleDB 和 InfluxDB,而 InfluxDB 在整个写入过程中,客户端负载整体上来说是三个系统中计算资源占用最低的,对客户端压力也是三者中最小的,其写入的压力基本上完全集中在服务端,这种模式很容易导致服务端发生瓶颈。

再看 TimescaleDB,对于客户端压力比 InfluxDB 要更大,CPU 峰值达到 17% 左右。而 TDengine 在客户端的开销最大,峰值瞬间达到了 56%,然后快速回落。虽然 TDengine 在客户端的开销相比于 TimescaleDB 多了 1 倍,但其写入持续时间更短,综合服务器与客户端的资源开销来看,在系统整体 CPU 开销上 TDengine 仍然具有相当大的优势。

写入性能基准评估扩展部分

为了更全面地评估 TDengine 在默认参数下的写入性能,我们在下面的性能评估中对可能会影响写入性能的多个参数进行了调整,以便开展更全面的评估工作。

虚拟节点(vnodes)数量

我们调整数据库中虚拟节点数量(默认是 6)为 6、8、12、24,并衡量不同 vnode 数量情况下 TDengine 的写入性能。

虚拟节点数量

6

8

12

24

100 devices × 10 metrics

13,694,875

13,780,359

13,569,666

13,429,903

(vnodes = 6) / (vnodes = #p)

100.00%

100.62%

99.09%

98.07%

4,000 devices × 10 metrics

11,604,459

11,592,558

11,565,546

11,637,392

(vnodes = 6) / (vnodes = #p)

100.00%

99.90%

99.66%

100.28%

100,000 devices × 10 metrics

5,339,835

5,296,044

5,296,268

5,397,590

(vnodes = 6) / (vnodes = #p)

100.00%

99.18%

99.18%

101.08%

1,000,000 devices × 10 metrics

3,367,111

3,351,568

3,360,974

3,334,824

(vnodes = 6) / (vnodes = #p)

100.00%

99.54%

99.82%

99.04%

10,000,000 devices × 10 metrics

2,349,628

3,031,325

3,135,838

3,268,176

(vnodes = 6) / (vnodes = #p)

100.00%

129.01%

133.46%

139.09%

不同虚拟节点数据量情况写入性能变化

从上表可以看到,在设备数最小的场景一中,随着虚拟节点数的增加,写入变化趋势不明显。在较多设备的场景(场景五)中,增加 vnodes 的数量 ,写入性能获得了显著的提升。可见在不同规模的场景中,通过调整 TDengine 虚拟节点的数量可以获得更好的写入性能,大规模场景中尤甚。

fsync 对写入性能的影响

TDengine写入速度(metrics/sec.)

scale=100

scale=4000

scale=100000

scale=1000000

scale=10000000

fysnc=0ms

12,530,045

12,176,290

7,566,922

4,199,325

2,588,922

fsync=200ms

12,842,668

12,477,106

7,681,030

4,264,758

1,974,915

fsync=3000ms

12,505,486

12,406,330

7,385,493

4,123,547

1,968,498

不同 fsync 配置下写入性能趋势

我们使用 fsync 参数控制写入到预写日志(write ahead log, WAL)文件中的数据调用 fsync 的频率,以确保数据可靠落盘。一般来说,调用 fsync 会消耗较多的 IO 资源,并会对写入过程造成一定的影响。但从上表可以看到,fsync 的配置调整对 TDengine 写入性能影响很小。

在前四个场景中,fsync 配置为实时同步刷入磁盘(fsync 为 0)的情况下,写入性能并没有出现显著降低。这是由于写入过程采用了大批量的写入模式,降低了每次刷入磁盘的次数需求,所以对性能影响并不明显,反之写入性能将降低。因此,我们可以获得一个信息,在此种情况下应用 TDengine,增加每批次写入数据量,可以有效缓解 fsync 配置写入的影响

设备记录数量

TDengine 的“一个设备一张表”数据模型使得其在进行数据写入时要先创建表,建表操作对每个设备只执行一次,但这会让 TDengine 在数据写入的准备阶段耗时较多。当单个表中数据量增加以后,数据准备(建表)的开销会被分摊到数据写入的整体开销中,所以应该有更好的数据写入性能。

以场景四为例,单个设备的数据量仅有 18 条。当我们调整参数,将单个设备记录数据增加到 36、72、144 条时,整体写入时间也变得更长,即建表开销被分摊到更多的数据写入过程中,建表的开销相对于数据写入的耗时占比越来越小,相应的整体写入速度也就越来越快。因此可以看到,随着设备记录数量增加,TDengine 表现出了更加明显的写入优势。

设备记录数增加时数据写入性能对比(数值越大越好)

随后我们调整了 vnodes 的数量配置,并同时测试两个不同 vnodes 数量情况下的写入性能指标。如上图所示,随着表中记录数的增加,单表记录增加到 72 时,TDengine 设置为 6 vnodes 的写入性能出现了下降,但是在 24 vnodes 的情况下,写入性能呈现出持续增加的趋势,并且在全部场景下写入性能均优于 6 vnodes 的写入性能。

当设备记录数达到 576 行(此时数据集规模为 1,000,000 × 576 = 5.76 亿行数据记录)时,写入性能达到 6,605,515 metrics/sec. 。在单设备记录达到 576 行时,默认 6 vnodes 配置下 TDengine 写入性能是 TimescaleDB 和 InfluxDB 的 7 倍多,当设置为 24 vnodes 时,性能更是大幅领先于 TimescaleDB 与 InfluxDB,最高达到了 TimescaleDB 和 InfluxDB 的 13 倍多。

TimescaleDB 写入性能在单表记录数量大于 72 行时就出现了下降趋势,在单表记录数 144 行以后出现了快速衰减。InfluxDB 在单设备记录增加过程中,写入性能有衰减,但衰减趋势比较缓慢。

写在最后

由此可见,TDengine 在五个测试场景中,写入性能均超过了 TimescaleDB 和 InfluxDB。且在整个写入过程中,TDengine 不仅提供了更高的写入能力,还保证了最小的资源消耗,不论是服务器的 CPU 还是 IO,TDengine 均远优于 TimescaleDB 和 InfluxDB。即使加上客户端的开销统计,TDengine 在写入开销上也远优于 TimescaleDB 和 InfluxDB。

在后面的拓展部分,通过调整不同的参数,以及设置不同的数据规模、调整 fsync 参数等方式,我们在更多的方面评估了 TDengine 在 TSBS 基准数据集上的写入性能。通过这一系列深入的对比可以看到,针对更大规模数据集,TDengine 可以通过简单调整虚拟节点数量的方式获得更高的写入性能,并且 TDengine 在针对大数据集写入场景下展现出了更大的性能优势。

TDengine 高效的写入性能在企业实践中也得到了验证,此前在机器人骨干企业拓斯达的工厂整体解决方案项目案例中,就阐述了应用 TDengine 后的改造结果——一个设备一天最多能写入近十万条数据,近千个设备同时写入也完全没有问题,相较于之前,写入速度提升了数十倍。


如果你也面临着数据处理难题或想要进行数据架构升级,欢迎添加小T vx:tdengine1,加入 TDengine 用户交流群,和更多志同道合的开发者一起攻克难关。

了解更多 TDengine Database的具体细节,可在GitHub上查看相关源代码。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/386517.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

如何让小型双轮差速底盘实现视觉循迹功能

1. 任务描述 在机器人小车(R023d)上搭载摄像头,摄像头采集图像信息并通过WiFi将信息传递给PC端,然后PC端使用OpenCV对摄像头读取到的视频进行灰度化、高斯滤波、腐蚀、膨胀等处理,使图像分为黑白两色。PC端进行图像信息…

【设计模式】策略模式和责任链模式

策略模式 任何程序都离不开算法,我们需要通过算法去解决特定的问题 策略模式将算法的实现分别封装起来,让他们之间可以方便的进行替换,而不需要去改动代码。属于行为型模式。 举个例子:拼多多现在有促销活动,其优惠策略可能是拼…

2023 年 Java 面试正确姿势(1000+ 面试题附答案解析)

几年前,你只需要简单的 ssm 框架,就能轻松找到一份 Java 的工作,但现在不一样了,随着涌入这个行业的人越来越多,同一个岗位需要筛选掉更多人,要求自然水涨船高,这也就是现在越来越多 Java 程序员…

若依学习——BaseController类(PageHelper)

若依的许多controller都继承了BaseController类,学习一下里面的几个方法。1、initBinder()方法查了一下,好像是用来解决前端出传来的属性与后端绑定的,不常用,知道个大概就行,详情;(…

基于自抗扰控制ADRC的主动悬架控制

目录 前言 1. 悬架系统 2.ADRC流程图 3.仿真分析 3.1 性能指标和观测效果对比 3.2控制输入对比 3.3 性能指标均方根对比 4.总结 前言 之前通过4篇文章介绍了ADRC,并且在最后一篇文章中进行了总结和应用,本篇文章继续将其应用于悬架对象上&am…

Mysql高级之索引结构详解

Mysql的索引详解1.索引定义2.索引结构2.1数据结构分析2.1.1熟知的数据结构2.1.2分析为什么这么多的数据结构不全适用于索引结构2.2Hash结构2.3B tree结构3.索引分类3.1聚集索引(聚簇索引)3.2非聚集索引(稀疏索引)3.3联合索引3.4主…

用于健康医疗的AI计算机视觉:使提供者能够增强患者护理

通过模仿和充当人力的力量,人工智能驱动的计算机视觉技术正在帮助医疗保健行业的医生、护士和企业更好地满足患者的需求。例如通过实时视频分析新见解可帮助他们节省时间、金钱和生命,同时为从患者入院到手术室等各个方面开发更安全、更高效的流程。用于…

java面试八股文之------Redis夺命连环25问

java面试八股文之------Redis夺命连环25问👨‍🎓1.为什么redis这么快👨‍🎓2.redis的应用场景,为什么要用👨‍🎓3.redis6.0之前为什么一直不使用多线程,6.0为甚么又使用多线程了&…

Spring Cloud融合Nacos实现服务配置中心 | Spring Cloud 7

一、服务配置中心 先我们来看一下,微服务架构下关于配置文件的一些问题: 配置文件相对分散。在一个微服务架构下,配置文件会随着微服务的增多变的越来越多,而且分散在各个微服务中,不好统一配置和管理。 配置文件无法区分环境&a…

jQuery和ajax案例练习

jQuery和ajax案例练习1.使用jquery修改div元素的背景色(随意颜色)2.使用jquery修改div的子元素p的内容为"我是子元素"3.使用jquery修改第二个p元素的背景色为"orange"4.使用jQuery添加文本的方式将“添加的文本”追加到p标签的后方5.删除列表元素中最后一个…

理解依赖注入(DI – Dependency Injection)

文章目录依赖注入1.provide(提供)1.1 在选项式 API 中,可通过provide选项为后代提供数据1.2 如果想访问到组件的实例this,provide必须采用函数的方式(不能用箭头函数),为保证注入方和供给方之间的响应性链接&#xff0…

K8s:开源安全平台 kubescape 实现 Pod 的安全合规检查/镜像漏洞扫描

写在前面 生产环境中的 k8s 集群安全不可忽略,即使是内网环境容器化的应用部署虽然本质上没有变化,始终是机器上的一个进程但是提高了安全问题的处理的复杂性分享一个开源的 k8s 集群安全合规检查/漏洞扫描 工具 kubescape博文内容涉及: kube…

工控机如何安装Python

钡铼技术BL302基于arm架构工控机,采用NXP的高性能处理器I.MX6ULL 运行速度高达800MHz,并配有8GFlash空间和512M RAM,硬件接口有2个网口、2个串口、1个USB口、1个SD卡卡槽、1个HDMI显示接口,可运行LINUX、Ubuntu、Debian等OS&#…

项目管理:如何做到项目信息透明?

项目管理中,管理者最担心的问题是什么?方项目进度不透明,项目的进展不明确,使用项目管理工具让项目进度一目了然。 1、项目管理必须目标明确。 明确的目标能够更好地指导接下来的一系列项目管理工作。 2、项目管理必须资源配置…

Redis缓存一致

背景介绍: redis是一个key-value存储系统。它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash(哈希类型)。这些数据类型都支持push/pop、add/remove及取交集并集和差…

2023 工业互联网平台:智慧制硅厂 Web SCADA 生产线

我国目前是全球最大的工业硅生产国、消费国和贸易国,且未来该产业的主要增量也将来源于我国。绿色低碳发展已成为全球大趋势和国际社会的共识,随着我国“双碳”目标的推进,光伏产业链快速发展,在光伏装机需求的带动下,…

干货分享!PCBA元器件间距的可焊性设计

“ SMT贴片加工逐步往高密度、细间距的设计发展,元器件的最小间距设计需考虑smt厂家的经验程度和工艺是否完善。元器件最小间距的设计除了保证smt焊盘间不易短接的安全间距外,还应考虑元器件的可维护性。 ” 元器件布局为什么要保证安全间距&#xff…

喜讯!华秋电子荣获第六届“高新杯”十大优秀企业奖

2月22日,由中科为集团与广东高科技产业商会联合举办的“第六届‘高新杯’十大优秀高新企业颁奖典礼暨2023年高新企业高质量发展春茗会”,在深圳隆重举行。 中科为集团自2014年举办首届“高新杯”以来,已主办了5届,共计600多家企业…

如何在CSDN上赚钱:CSDN收益渠道分析

文章目录说明哪些人,哪些资源赚到了钱?上传付费资源的策略一些经验说明 在CSDN平台上要想获得回报,主要的渠道: 付费资源付费专栏文章打赏 这三个都有门槛,上传付费资源需要原力等级达到Lv5,粉丝数500&a…

微信怎么发文字朋友圈?简单快捷的方法,只需1分钟

微信是一个非常受欢迎的聊天工具,也是一个交友,分享生活的平台。其中,朋友圈是最受欢迎的功能之一,让我们可以与好友分享自己的生活点滴,也能够关注他人的动态。那么微信怎么发文字朋友圈呢?下面跟着小编一…