Elastic Cloud Serverless:深入探讨大规模自动扩展和性能压力测试

news2024/12/26 20:21:34

作者:来自 Elastic David Brimley, Jason Bryan, Gareth Ellis 及 Stewart Miles

深入了解 Elasticsearch Cloud Serverless 如何动态扩展以处理海量数据和复杂查询。我们探索其在实际条件下的性能,深入了解其可靠性、效率和可扩展性。

简介

Elastic Cloud Serverless 的出现重塑了企业如何利用 Elasticsearch 的强大功能,而无需管理集群、节点或资源扩展。Elastic Cloud Serverless 的一项关键创新是其自动扩展功能,该功能可实时适应工作负载和流量的变化。本文探讨了自动扩展背后的技术细节、Elastic Cloud Serverless 在负载下的性能以及大量压力测试的结果。

什么是 Elastic Cloud Serverless?

Elastic Cloud Serverless 提供自动化、托管版本的 Elasticsearch,可根据需求进行扩展。与传统的 Elasticsearch 部署(用户必须配置和管理硬件或云实例)不同,Elastic Cloud Serverless 可管理基础设施扩展和资源分配。这对于工作负载多变的组织尤其有益,因为手动扩展和缩减基础设施可能很麻烦且容易出错。该系统的内置自动扩展功能可适应繁重的提取任务、搜索查询和其他操作,无需人工干预。

Elastic Cloud Serverless 有两个不同的层级,即搜索层(search tier索引层(indexing tier,每个层级都针对特定工作负载进行了优化。搜索层专用于处理查询执行,确保快速高效地响应搜索请求。同时,索引层负责提取和处理数据、管理写入操作以及确保数据正确存储和可搜索。通过解耦这些问题,Elastic Cloud Serverless 允许每个层根据工作负载需求独立扩展。这种分离提高了资源效率,因为索引的计算和存储需求(例如,处理高吞吐量提取)不会干扰搜索操作期间的查询性能。同样,搜索层资源可以扩展以处理复杂查询或流量高峰,而不会影响提取过程。这种架构可确保最佳性能、成本效益和弹性,使 Elastic Cloud Serverless 能够动态适应波动的工作负载,同时保持一致的用户体验。

你可以在以下博客文章中阅读有关 Elastic Cloud Serverless 架构的更多信息。

压力测试 Elastic Cloud Serverless

全面的压力测试评估了 Elastic Cloud Serverless 处理大量波动工作负载的能力。这些测试旨在衡量系统提取数据、处理搜索查询以及在极端条件下保持性能的能力。需要注意的是,系统的性能可能超出我们在此处介绍的范围,具体取决于客户端数量和批量索引大小等因素。在这里,我们将介绍这些测试的方法和结果。

测试范围和方法

我们压力测试的主要目标是回答关键问题:

  • Elastic Cloud Serverless 如何处理大量并发客户端的大规模提取和搜索查询?
  • 它能否动态扩展以适应工作负载的突然激增?
  • 系统是否在较长时间内保持稳定性?

对搜索用例进行压力测试。

在 Elastic Cloud Serverless 中,你可以从三种项目类型中进行选择:Elasticsearch、可观察性和安全性。我们使用 Github Archive 数据集并模拟可能的摄取和搜索行为,开始了对 Elasticsearch 搜索用例的压力测试之旅。在测试之前,我们通过摄取 186GB/4300 万个文档的基础语料库来准备系统。然后,我们在十分钟内逐渐添加客户端,以便 Elasticsearch 有时间适当扩展。数据是通过 Bulk API 使用 Datastreams 摄取的。

对索引层进行压力测试。

首先,让我们谈谈索引数据(摄取)。Elastic Cloud Serverless 中的摄取自动扩展会动态调整资源以满足数据摄取需求,从而确保最佳性能和成本效益。系统持续监控摄取吞吐量、资源利用率(CPU、内存和网络)和响应延迟等指标。当这些指标超过预定义的阈值时,自动扩缩器会按比例提供额外的容量来处理当前和预期的需求,同时为意外峰值保留缓冲。数据管道的复杂性和系统施加的资源限制也会影响扩展决策。通过动态添加或删除容量,摄取自动扩缩可确保无缝扩展而无需人工干预。

在 Elastic Cloud Serverless 等资源效率得到优化的自动扩缩系统中,可能会出现工作负载突然大幅增加超出系统立即扩展的能力的情况。在这种情况下,客户端可能会收到 HTTP 429 状态代码,表示系统不堪重负。为了处理这些情况,客户端应实施指数退避策略,以逐渐延长的间隔重试请求。在压力测试期间,我们会主动跟踪 429 响应,以评估系统在高需求下的反应,从而提供有关自动扩缩有效性的宝贵见解。你可以在此处阅读有关我们如何自动扩缩索引的更深入的博客文章。现在,让我们看看我们在索引层的压力测试中遇到的一些结果。

在扩大规模的同时建立索引:

CorpusBulk SizeActual VolumeIndexing Period (minutes)Volume / hrMedian Throughput (docs/s)90th PCT Indexing latency (seconds)Avg. % Error Rate (429s, other)
1TB25001117.43 GB631064.22 GB70,256.967.0950.05%
2TB25002162.02 GB1221063.29 GB68,365.238.1480.05%
5TB25005254.84 GB2721159.16 GB74,770.277.460

对于 1TB 和 2TB 语料库的初始测试,我们分别实现了 1064 GB/小时和 1063 GB/小时的吞吐量。对于 5TB,我们实现了更高的 1160 GB/小时的摄取速度,因为我们观察到摄取层继续扩大,从而提供了更好的吞吐量。

在完全扩展的情况下进行索引:

ClientsBulk SizeActual VolumeDurationVolume / hrMedian Throughput (docs/s)99th PCT Indexing latency (seconds)Avg. % Error Rate (429s, other)
3,0002,0001 TB8 minutes7.5 TB499,00033.50.0%

使用最大规模的索引层时,ECS 在 8 分钟内提取了 1TB 的数据,每秒索引的速率约为 499K 文档/秒。这相当于每天 180TB 的推断容量。

从最小规模到最大规模的索引:

ClientsBulk SizeActual VolumeDurationVolume / hrMedian Throughput (docs/s)99th PCT Indexing latency (seconds)Avg. % Error Rate (429s, other)
2,0481,00013 TB6 hours2.1 TB146,47855.51.55%

在对 2TB 数据进行测试时,我们逐渐扩展到 2048 个客户端,并设法以每秒 146K 文档的速度提取数据,在 1 小时内完成 2TB 的数据。推算下来,每天的数据量为 48TB。

72 小时稳定性测试:

ClientsBulk SizeActual VolumeIndexing Period (hours)Volume / hrMedian Throughput (docs/s)99th PCT Indexing latency (seconds)Avg. % Error Rate (429s, other)
12850061 TB72~868.6 GB51,7007.7<0.05%

在 72 小时的稳定性测试中,我们使用 128 个客户端提取了 60TB 的数据。Elasticsearch 在扩展索引和搜索层的同时,保持了令人印象深刻的 870GB/小时的吞吐量,错误率极低。这证明了 Elasticsearch 能够在较长时间内保持高吞吐量,同时保持较低的故障率。

对搜索层进行压力测试。

Elastic Cloud Serverless 中的搜索层自动扩展功能会根据数据集大小和搜索负载动态调整资源,以保持最佳性能。系统将数据分为两类:增强型非增强型。增强型数据包括用户定义的增强窗口内的基于时间的文档(带有 @timestamp 字段的文档)和所有非基于时间的文档,而非增强型数据则不在此窗口内。用户可以设置增强窗口来定义增强数据的时间范围,并选择搜索能力级别(按需、高性能或高吞吐量)来控制资源分配。你可以在此处阅读有关配置搜索能力和搜索增强窗口的更多信息。

自动扩展器监控查询延迟、资源利用率(CPU 和内存)和查询队列长度等指标。当这些指标表明需求增加时,系统会相应地扩展资源。此扩展是按项目执行的,对最终用户是透明的。

负载下的搜索稳定性:

CorpusActual Volume (from corpus tab)DurationAverage Search Rate (req/s)Max Search Rate (req/s)Response Time (P50)Response Time (P99)
5TB5254.84 GB120 minutes8913,15836 ms316 ms

使用 5TB 的数据,我们测试了一组运行超过 2 小时的 8 次搜索,包括复杂查询、聚合和 ES|QL。每次搜索的客户端数量从 4 个增加到 64 个。总共有 32 到 512 个客户端执行搜索。随着客户端数量从 32 个增加到 512 个,性能保持稳定。当使用 512 个客户端运行时,我们观察到搜索请求率为每秒 3,158 个查询,P50 响应时间为 36 毫秒。在整个测试过程中,我们观察到搜索层扩展符合预期,可以满足需求。

24 小时搜索稳定性测试:

CorpusActual VolumeDurationAverage Search Rate (req/s)Max Search Rate (req/s)Response Time (P50)Response Time (P99)
40TB60 TB24 hours183250192 ms520 ms

一组 7 次搜索、聚合和一个 ES|QL 查询用于查询 40TB(主要是)增强数据。客户端数量从每次搜索 1 个增加到 12 个,总共 7 个到 84 个搜索客户端。在将搜索能力设置为平衡的情况下,我们观察到 192 毫秒(P50)的响应时间。你可以在此处阅读有关配置搜索能力和搜索增强窗口的更多信息。

并发索引和搜索

在同时运行索引和搜索的测试中,我们的目标是以 6 个“chunks/块”的形式提取 5TB。我们将提取数据的客户端从 24 个增加到 480 个,批量大小为 2500 个文档。对于搜索,客户端从每次搜索 2 个增加到 40 个。总共有 16 到 320 个客户端执行搜索。

我们观察到两个层级都自动扩展,并且搜索延迟始终保持在 24 毫秒(p50)和 1359 毫秒(p99)左右。系统在保持性能的同时进行索引和搜索的能力对于许多用例至关重要。

结论

上面讨论的压力测试侧重于 Elasticsearch 项目中的搜索用例,该项目设计为具有特定字段类型、字段数量、客户端和批量大小的配置。这些参数经过量身定制,以在与用例相关的明确条件下评估 Elastic Cloud Serverless,从而提供有关其性能的宝贵见解。但是,需要注意的是,结果可能无法直接反映你的工作负载,因为性能取决于各种因素,例如查询复杂性、数据结构和索引策略。

这些基准作为基准,但实际结果将根据你的独特用例和要求而有所不同。还应注意,这些结果并不代表性能上限。

我们压力测试的关键结论是 Elastic Cloud Serverless 表现出非凡的稳健性。它每天可以提取数百 TB 的数据,同时保持强大的搜索性能。这使其成为大规模搜索工作负载的强大解决方案,可确保高数据量下的可靠性和效率。在即将发布的文章中,我们将进一步探索对 Elastic Cloud Serverless 进行压力测试,以实现可观察性和安全性用例,重点介绍其在不同应用领域的多功能性,并深入了解其功能。

了解有关 Elastic Cloud Serverless 的更多信息,并开始 14 天免费试用,亲自测试一下。

原文:Elastic Cloud Serverless: A Deep Dive into Autoscaling and Performance Stress Testing at Scale - Search Labs

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

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

相关文章

基于SpringBoot的旅游管理系统设计与实现

标题&#xff1a; 《基于SpringBoot的旅游管理系统设计与实现》 摘要&#xff1a; 本研究的主要目标是设计与实现基于Spring Boot的现代化旅游管理系统&#xff0c;旨在有效解决传统系统存在的多项问题&#xff0c;如用户体验不佳、功能不完善以及安全性方面的隐患。随着互联网…

LeetCode 热题100(十五)【动态规划】(3)

15.7最长递增子序列&#xff08;中等&#xff09; 题目描述&#xff1a;leetcode链接 300. 最长递增子序列 给你一个整数数组 nums &#xff0c;找到其中最长严格递增子序列的长度。 子序列 是由数组派生而来的序列&#xff0c;删除&#xff08;或不删除&#xff09;数组中的元…

精华帖分享|书中自有黄金屋系列2——格雷厄姆估值因子

本文来源于量化小论坛股票量化板块精华帖&#xff0c;作者为Benlyn&#xff0c;发布于2024年2月2日。 以下为精华帖正文&#xff1a; 01 前言 巴菲特一直强调“以合理的估值买入好公司”的投资理念&#xff0c;因此今天想给大家介绍一下与估值相关的内容。买股票买好公司固然…

干部谈话考察系统如何实现灵活定制和精准考评?

在当今社会&#xff0c;干部选拔与任用已成为各类组织内部管理的关键环节。为了确保选拔出的干部具备高素质和卓越能力&#xff0c;干部谈话考察系统应运而生。这一系统以其灵活定制和精准考评的特点&#xff0c;为组织提供了科学、高效的干部考察手段。 干部谈话考察系统通过集…

云渲染特效广告一秒费用预估是多少?

在计算云渲染特效广告每秒钟的费用时&#xff0c;我们需要综合考虑多个关键因素&#xff0c;包括特效的复杂性、所需的渲染计算能力以及对渲染质量的具体要求。通常情况下&#xff0c;影视特效级别的广告因其场景极其复杂&#xff0c;每帧渲染所需时间较长&#xff0c;从而导致…

利用docker-compose来搭建flink集群

1.前期准备 &#xff08;1&#xff09;把docker&#xff0c;docker-compose&#xff0c;kafka集群安装配置好 参考文章&#xff1a; 利用docker搭建kafka集群并且进行相应的实践-CSDN博客 这篇文章里面有另外两篇文章的链接&#xff0c;点进去就能够看到 &#xff08;2&…

2024年认证杯SPSSPRO杯数学建模C题(第一阶段)云中的海盐解题全过程文档及程序

2024年认证杯SPSSPRO杯数学建模 C题 云中的海盐 原题再现&#xff1a; 巴黎气候协定提出的目标是&#xff1a;在2100年前&#xff0c;把全球平均气温相对于工业革命以前的气温升幅控制在不超过2摄氏度的水平&#xff0c;并为1.5摄氏度而努力。但事实上&#xff0c;许多之前的…

初识树(二叉树,堆,并查集)

本篇博客将涉及到一些专业名词&#xff1a;结点、深度、根、二叉树、满二叉树、完全二叉树、堆、并查集等。 概要 树型结构是一类重要的非线性数据结构。其中以树和二叉树最…

2024年中国光伏产业研究报告(附产业链图谱)

光伏产业是指利用太阳能电池将太阳光转换为电能的产业&#xff0c;它涉及到太阳能电池、组件、系统及相关配套产品的研发、生产、销售和服务。光伏产业是新能源领域的重要组成部分&#xff0c;已成为我国少数具有国际竞争优势的战略性新兴产业之一。国家多个部门联合印发了《智…

Linux:Ext系列文件系统

提示&#xff1a;文章写完后&#xff0c;目录可以自动生成&#xff0c;如何生成可参考右边的帮助文档 文章目录 前言一、理解硬件磁盘1.1 磁盘物理结构1.2 磁盘的存储结构1.3 磁盘的逻辑结构 二、文件系统2.1 引⼊"分区”概念和“块"概念2.2 inode(重要)2.3 文件与in…

Alogrithm:巴斯卡三角形

巴斯卡三角形&#xff08;Pascals Triangle&#xff09;是一个由数字排列成的三角形&#xff0c;每一行的数字是由前一行的两个相邻数字相加得到的。巴斯卡三角形的每一行对应着二项式展开式的系数。具体如下图所示&#xff1a; 巴斯卡三角形的性质 第 0 行只有一个数字 1。第 …

项目资源管理

点击系统侧边栏里的项目图标 &#xff0c;会在系统资源列表里显示当前任擎服务器上所有项目的各种资源列表&#xff0c;包括数据模型、后台服务、前端文件、数据表单和微信小程序等。 项目资源管理器用来对开发者自己开发的软件项目进行管理&#xff0c;这里的“项目”是指仅…

WEB开发: Node.js路由之由浅入深(一) - 全栈工程师入门

作为一个使用Node.js多年的开发者&#xff0c;我已经习惯于用Node.js写一些web应用来为工作服务&#xff0c;因为实现快速、部署简单、自定义强。今天我们一起来学习一个全栈工程师必备技能&#xff1a;web路由。&#xff08;观看此文的前提是默认你已经装好nonde.js了&#xf…

大模型分类3—按功能特性

版权声明 本文原创作者:谷哥的小弟作者博客地址:http://blog.csdn.net/lfdfhl根据功能特性,大模型可分为生成式、分析式和交互式大模型。 1. 大模型分类概述 1.1 生成式大模型 生成式大模型的核心能力在于其创造性,能够独立生成新的数据样本,如文本、图像和音频等。这类…

VUE拖拽对象到另一个区域

最近有个需求是需要在web端定制手机的界面UI&#xff08;具体实现比较复杂&#xff0c;此处不做阐述&#xff0c;此文章只说明拖拽效果实现&#xff09;&#xff0c;为了方便用户操作&#xff0c;就想实现这种效果&#xff1a;从右侧的图标列表中拖拽图标到左侧模拟的手机界面上…

iOS平台接入Facebook登录

1、FB开发者后台注册账户 2、完善App信息 3、git clone库文件代码接入 4、印尼手机卡开热点调试 备注&#xff1a; 可能遇到的问题&#xff1a; 1、Cocos2dx新建的项目要更改xcode的git设置&#xff0c;不然卡在clone&#xff0c;无法在线获取FBSDK 2、动态库链接 需要在…

传输层TCP_三次握手四次挥手的过程

三次握手四次挥手 三次握手 三次握手

小迪笔记 第四十五天 sql 注入进阶 :二次注入,堆叠注入,数据读取(load_file)加外带

二次注入 概念&#xff1a;就是我们注入的语句&#xff08;刚注入时 不会产生影响&#xff09;但是我们的恶意代码会进入数据库 他在被二次利用的时候就会进行执行 这个就是二次注入 这个的典型案例就是账号密码的修改 &#xff1a; 大家应该也知道 账号注册一般是禁止你使…

【SNIP】《An Analysis of Scale Invariance in Object Detection – SNIP》

CVPR-2018 Singh B, Davis L S. An analysis of scale invariance in object detection snip[C]//Proceedings of the IEEE conference on computer vision and pattern recognition. 2018: 3578-3587. https://github.com/bharatsingh430/snip?tabreadme-ov-file 文章目录 …

【C++|Linux|计网】构建Boost站内搜索引擎的技术实践与探索

目录 1、项目的相关背景 2.搜索引擎的相关宏观原理 3.搜索引擎技术栈和项目环境 4.正排索引vs倒排索引-搜索引擎具体原理 5.编写数据去标签与数据清洗的模块 Parser 5.1.去标签 目标&#xff1a; 5.2.代码的整体框架&#xff1a; EnumFile函数的实现&#xff1a; Enu…