benchANT (Time Series: Devops) 榜单数据解读
近日,国际权威数据库性能测试榜单 benchANT 更新了 Time Series: Devops(时序数据库)场景排名,KaiwuDB 数据库在 xsmall 和 small 两类规格下的时序数据写入吞吐、查询吞吐、查询延迟、成本效益等多项指标刷新榜单原有数据纪录 ,位居全球时序数据库性能测试榜单第一。今天,我就为大家详细解读榜单数据,随小编一探究竟。
为什么选择 benchANT?
时序能力:KaiwuDB 的一大核心
KaiwuDB 分布式多模数据库从物联网 场景真实需求出发,针对性设计多模架构。物联网场景中时序数据处理能力始终是一大核心点 ,KaiwuDB 根据此需求在系统优化上重点关注海量时序数据的高性能读写、低成本存储、灵活生命周期管理及系统的水平拓展能力。
benchANT:权威、全面、精准的时序数据库能力测评
benchANT 是总部位于德国的权威云基础设施与数据库性能测试机构,其发布的 benchANT Database Ranking(以下简称 benchANT 榜单)已成为全球范围内广泛认可的数据库性能评估标准。
该榜单涵盖了三大主流工作负载场景------CRUD: General Purpose、OLTP: Mix 和 Time Series: DevOps。
其中,Time Series: DevOps 场景是针对时序数据库的测试,以 Time Series Benchmark Suite (TSBS) 测试工具为基础,从写入吞吐量、查询性能、成本效益等多个维度对数据库的性能进行测试,全面评估数据库在实际生产环境中的表现。InfluxDB、TimescaleDB、VictoriaMetrics、Apache IoTDB 等各大全球知名的时序数据库产品参与了该场景的测评。
同时,为了确保测试结果的公正性和可复现性,benchANT 榜单采用了严格的测试方法:所有数据库均在统一规格的 AWS 云环境中进行部署,有效避免了因硬件差异带来的测试偏差。
测试流程介绍
导入性能测试
benchANT 的测试采用了 TSBS 的 DevOps 场景,该场景模拟服务器运行时的监控数据。每台设备会采集 cpu、diskio、disk、kernel、mem、net、nginx、postgresl 和 redis 等 9 类监控指标,每类指标下又包含多个测量值。
例如,在 cpu 指标中,记录了 10 项测量值,包括 usage_user、usage_system、usage_idle、usage_nice、usage_iowait、usage_irq、usage_softirq、usage_steal、usage_guest 和 usage_guest_nice。总体来看,这 9 类监控指标共记录了 101 项测量值。
在测试中,benchANT 基于上述 DevOps 场景生成了一份包含 1000 台设备(服务器)的数据数据集,时间范围为 3 天,数据采集间隔为每 10 秒一次。因此,整个数据集中共有 2,617,920,000 个数据点。benchANT 榜单中的写入吞吐量指标,是通过导入数据点的量除以导入所需的时间计算得出的。
查询性能测试
在完成数据导入后,benchANT 会对查询性能进行测试。查询测试用例仍由 TSBS 工具生成,benchANT 选用时序场景代表性的 single-groupby-1-1-1 查询类型进行评测。single-groupby-1-1-1 查询类型的含义是:选取 1 个设备的 1 个测量值,在随机的 1 小时内以 1 分钟为间隔进行分段聚合计算。
在 benchANT 的测试中,共生成了 10 万条此类型的查询语句,通过执行 100,000 次查询,统计整个查询阶段的查询吞吐量和查询延迟数据。
测试规格说明
benchANT 的 Time Series: DevOps 场景包含两种数据库部署的测试规格,如下表:
这样的测试环境不仅能够对时序数据库在小资源、高并发下的极限性能进行测试,也更加贴近时序数据库在部分真实生产环境中的部署环境和使用要求。
测试结果及对比
写入吞吐量
时序数据库通常需要应对百万乃至千万级终端设备的并发实时数据写入,因此写入吞吐量是衡量其性能的重要指标。KaiwuDB 在 xSmall 和 Small 两种规格下的写入吞吐分别达到2,194,386 测点/秒 和6,720,972 测点/秒 ,分别为原榜单同规格最高写入吞吐的1.5 倍 和1.8 倍。
查询吞吐与查询延迟
benchANT 榜单通过查询吞吐和查询延迟两项测试综合评估时序数据库的查询能力。KaiwuDB 借助其创新的就地计算技术,能够快速定位和高效存取海量时序数据。
在 xSmall 和 Small 规格下,KaiwuDB 查询吞吐量分别达到32,402 和56,790 ,分别是原榜单同规格最高查询吞吐的3.9 倍 和4.9 倍。
同时,KaiwuDB 以仅1.38 毫秒(xSmall)和 1.37 毫秒(Small)的平均查询延迟刷新了榜单纪录,为保证业务程序性能、增强用户体验提供了关键支撑。
成本效益
成本效益指标衡量了在统一云环境成本条件下各数据库的查询处理能力。KaiwuDB 凭借其具备高速数据查询和分析能力,其成本效益排名稳居榜首。测试过程中,KaiwuDB 分别在不同规格的机器上均展现出稳定高效的写入与查询性能。
KaiwuDB 在 xSmall 和 Small 规格下,其成本效益分别为341.07ops/$和319.04ops/$ ,高达原榜单同规格成本收益的3.9 倍 和4.9 倍。
而且,随着部署环境硬件规格的提升,KaiwuDB 的性能增长幅度尤为显著,全面超越其他时序数据库。这就充分证明了 KaiwuDB 的性能与技术实力能为用户在高性能时序数据管理方面提供可靠选择。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
前端性能调试实战:一次内存泄漏的排查与解决
"老王,我们的后台系统用着用着就变卡了,而且内存占用越来越大,是不是被攻击了?"上周四下午,运维小张一脸焦虑地找到我。作为项目的前端负责人,我立即打开了系统开始排查。 说实话,这个问题确实让我有点意外。我们的后台系统用 React 开发,平时运行都挺正常的,怎么突然就出现性能问题了?带着这个疑问,我开始了一场"破案"之旅。 问题的发现 首先,我让小张演示了一下具体的操作步骤。很快,我就发现了一些蛛丝马迹: 系统运行一段时间后,切换页面明显变慢 浏览器任务管理器显示内存占用持续上升 关闭标签页重新打开后,问题暂时消失 这些现象都指向一个可能:内存泄漏。但问题出在哪里呢? 调试工具的准备 我打开了 Chrome DevTools,开始系统性地排查: // 首先在代码中埋点,记录关键组件的生命周期 class SuspectComponent extends React.Component { componentDidMount() { console.time('ComponentLifetime') this._mountTime = performance.now() } compon...
- 下一篇
将自定义 AWS S3 快照存储库连接到 Elastic Cloud
作者:来自 ElasticAnnie Hansen, Stef Nestor 在本博客中,我们将介绍如何通过 Elasticsearch 的快照将我们已提交的集群数据备份到 AWS S3 存储桶中。在 Elastic Cloud(企业版)中,Elastic 在其 found-snapshots 存储库下提供内置备份服务。Elasticsearch 还支持云(Cloud)和本地设置的自定义存储库,连接到所有平台类型的数据存储(如 AWS S3、GCP 和 Azure)以及本地文件系统。这些内置和自定义快照存储库为数据备份提供了很好的选择;自定义存储库用于长期存储和开关备份;找到快照用于持续的、最近的备份。用户经常将这两种方法集成到他们的生产集群中。 (连接自定义 AWS S3 快照存储库 Elastic Cloud 支持故障排除视频:https://www.bilibili.com/video/BV15ZB9Y7Eh7?t=45.8) 创建 AWS S3 存储桶 首先,我们将按照 AWS 指南设置一个 AWS S3 存储桶来存储我们的数据。 在Create bucket下,填写Bucke...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Mario游戏-低调大师作品
- CentOS7安装Docker,走上虚拟化容器引擎之路