Amazon OpenSearch实例类型性能基准测试深度解析

本文详细对比了Amazon OpenSearch专用OM2实例与通用M7g实例的性能差异,涵盖索引吞吐量、查询延迟和资源利用率等关键指标,为优化搜索工作负载提供数据驱动的决策依据。

Amazon OpenSearch工作负载实例类型基准测试

选择适合的Amazon OpenSearch集群实例类型对于平衡性能和成本至关重要。AWS同时提供OpenSearch专用OM2实例和更新的通用M7g实例,组织面临重要决策。虽然OM2实例针对OpenSearch进行了优化,具有高内存与vCPU比率,但M7g实例采用最新技术,承诺提供增强的整体性能。最佳选择取决于您特定的工作负载特征和要求。

本文提供了这些实例类型之间的全面基准比较,为DevOps团队和架构师提供可操作的见解,以做出明智的基础设施决策。我们将检查实际性能指标和成本影响,帮助您优化OpenSearch部署。

OpenSearch优化中的基准测试理解

OpenSearch中的基准测试是在受控条件下评估集群性能的系统过程,测量关键指标如查询延迟、吞吐量和资源利用率。对于像OpenSearch这样的分布式搜索引擎,基准测试超越了简单的性能测试——它是关于理解您的集群在特定工作负载模式下的行为方式。它为做出关于基础设施、配置和扩展策略的明智决策提供定量数据。

通过模拟真实世界工作负载并在受控条件下测量系统行为,团队可以有效地优化其OpenSearch部署。

OpenSearch基准测试的四个基本支柱如下:

  • 性能优化:专注于测量和改进查询响应时间、吞吐量和整体集群效率。这有助于团队验证配置更改并理解不同工作负载模式的影响。
  • 容量规划:使团队能够做出关于集群大小、分片分配和扩展策略的数据驱动决策。它有助于预测未来增长的资源需求,并确保在峰值负载期间的可靠性能。
  • 成本管理:提供资源利用率的见解,并帮助优化基础设施支出。通过理解每美元性能指标,团队可以做出关于实例类型和集群配置的明智决策。
  • 瓶颈识别:帮助精确定位跨CPU、内存、网络和存储的性能约束。早期识别瓶颈允许团队在问题影响生产工作负载之前解决问题。

理解这些支柱对于进行有意义的基准测试至关重要,这些测试可以推动OpenSearch部署的改进。

基准设置和方法论

OpenSearch Benchmark是OpenSearch项目提供的工具,全面收集OpenSearch集群的性能指标,包括索引吞吐量和搜索延迟。无论您是跟踪整体集群性能、通知升级决策,还是评估工作流更改的影响,此实用程序都证明非常宝贵。

我们比较了两个集群的性能:一个由OpenSearch专用OM2实例提供支持,另一个由更新的通用M7g实例提供支持。数据集包含1998年世界杯网站的HTTP服务器日志,通常用于摄取繁重和搜索密集型场景,使其成为在此类任务中比较实例性能的理想选择。使用OpenSearch Benchmark工具,我们进行实验以评估各种性能指标,如索引吞吐量、搜索延迟和整体集群效率。我们的目标是确定最适合我们特定工作负载要求的配置。

您可以直接在运行Linux或macOS的主机上安装OpenSearch Benchmark,或者在任何兼容主机上的Docker容器中运行OpenSearch Benchmark。OpenSearch Benchmark包含一组工作负载,可用于对集群性能进行基准测试。工作负载包含一个或多个基准测试场景的描述,这些场景使用特定的文档语料库对集群执行基准测试。文档语料库包含工作流运行时调用的索引、数据文件和操作。

在评估集群性能时,建议使用与集群用例类似的工作负载,这可以节省您的时间和精力。考虑以下标准以确定最适合对集群进行基准测试的工作负载:

  • 用例:选择反映集群真实世界用例的工作负载对于准确的基准测试至关重要。通过模拟集群典型的繁重搜索或索引任务,您可以精确定位性能问题并有效优化设置。这种方法确保基准测试结果与实际性能期望紧密匹配,从而产生更可靠的优化决策,这些决策针对您的特定工作负载需求量身定制。
  • 数据:使用与生产工作负载类似的数据结构。OpenSearch Benchmark在每个工作负载内提供文档示例,以理解映射并与您自己的数据映射和结构进行比较。每个基准测试工作负载由以下目录和文件组成,供您比较数据类型和索引映射。
  • 查询类型:理解查询模式对于检测集群内最频繁的搜索查询类型至关重要。在基准测试实验中使用类似的查询模式是必要的。

OpenSearch基准测试过程遵循系统工作流,包括以下五个关键步骤:

1. 环境设置

配置与生产设置密切匹配的测试环境。确保硬件满足最低要求(例如,CPU、RAM、SSD存储),并设置OpenSearch集群或域进行基准测试。选择实例时,您还应考虑要运行哪些工作负载。作为一般规则,确保OpenSearch Benchmark主机有足够的可用存储空间来存储压缩数据和完全解压缩的数据语料库,一旦OpenSearch Benchmark安装完成。

硬件要求

  • CPU:推荐8+核心
  • RAM:最低16GB,推荐32GB+
  • 存储:SSD,至少为测试数据集大小的3倍 – 500GB

软件要求

  • Python 3.8或更高版本。python3 --version
  • 已安装Pip。pip --version
  • Git 1.9或更高版本。git --version

在Linux上安装

所需软件安装后,使用以下命令安装OpenSearch Benchmark:pip install opensearch-benchmark

使用以下命令验证安装:opensearch-benchmark -h

有关使用Docker安装OpenSearch Benchmark,请参阅文档。

2. 选择和配置工作负载

选择与您的用例匹配的工作负载(例如,http_logs、geonames)。工作负载定义数据集、查询和操作以模拟真实世界场景。如果需要,自定义工作负载参数,例如目标吞吐量或并发性。

工作负载名称 文档数量 压缩大小 未压缩大小
http_logs 247,249,096 1.2 GB 31.1 GB

要查看默认基准测试工作负载列表,请访问GitHub上的opensearch-benchmark-workloads存储库。

3. 数据摄取

将工作负载数据集加载到目标OpenSearch集群中。此步骤准备索引并确保数据准备好进行基准测试操作。

4. 运行基准测试

使用OpenSearch Benchmark执行基准测试。测试模拟索引、查询和聚合等操作,同时收集延迟、吞吐量和系统资源使用情况等指标。

此示例运行具有http_logs工作负载和禁用证书验证的基准测试:

1
2
3
4
5
opensearch-benchmark execute-test \
--target-hosts=https://opensearch-cluster-dns-name:9200 \
--pipeline=benchmark-only \
--workload=http_logs \
--client-options=basic_auth_user:*****,basic_auth_password:******,certs:false

5. 分析结果

查看收集的指标以评估集群性能。使用见解识别瓶颈、优化配置或比较不同设置以进行改进。OpenSearch Benchmark摘要报告提供与集群性能相关的指标;您如何比较和使用这些指标取决于您的用例。

OpenSearch Benchmark结果存储在内存或外部存储中,结果可以在/.benchmark/benchmarks/test_executions/<test_execution_id>目录中找到。结果根据最近工作负载测试的test_execution_id命名。

性能基准分析:Amazon OpenSearch的OM2与M7g

在本文中,我们对OpenSearch服务的两种不同配置进行了性能比较:

  • 配置1 – OpenSearch专用OM2实例的集群管理器节点和两个数据节点
  • 配置2 – 更新的通用M7g实例的集群管理器节点和两个数据节点

在两种配置中,我们使用相同数量和类型的集群管理器节点:三个c6g.xlarge。您可以在OpenSearch服务中设置具有支持实例类型的不同配置以运行性能基准测试。

下表总结了我们的OpenSearch服务配置详细信息。

组件 OM2集群 M7G集群
集群管理器节点
实例类型 c6g.large c6g.large
数量 3 3
数据节点
实例类型 OM2.2xlarge M7g.2xlarge
数量 2 2
每个节点的vCPU 8 8
每个节点的内存 32 GiB 32 GiB
存储配置
卷类型 gp3 gp3
大小 500 GB 500 GB
IOPS 3000 3000
OPENSEARCH配置
版本 2.19 2.19
每个索引的分片 5 5
副本 1 1
JVM堆 8GB 8GB
监控
CloudWatch指标 启用 启用
指标频率 1分钟 1分钟

现在让我们检查两种配置之间的性能细节。

性能基准比较

http_logs数据集包含1998年4月30日至1998年7月26日期间1998年世界杯网站的HTTP服务器日志。每个请求由时间戳字段、客户端ID、对象ID、请求大小、方法、状态等组成。数据集的未压缩大小为31.1 GB,包含2.47亿个JSON文档。发送到两个域配置的负载量是相同的。下表显示了在我们的两种配置上运行OpenSearch工作负载的各个方面所花费的时间。

以下是具有用例/场景的全面比较:

指标类型 指标 描述 用例 M7G OM2 %变化 胜者
索引性能
索引时间 主分片 跨主分片文档索引的总时间 日志摄取,文档处理 87.03分钟 65.68分钟 -24.54% OM2 ✅
刷新时间 主分片 将索引数据持久化到磁盘的时间 大型批量更新,数据迁移 8.57分钟 5.06分钟 -41.03% OM2 ✅
GC时间 年轻代 最近对象的垃圾收集时间 内存密集型操作 16.50秒 7.29秒 -55.83% OM2 ✅
查询性能
批量索引 p99延迟 99%批量索引操作的时间 ETL过程,数据导入 300.02毫秒 773.71毫秒 +157.87% M7g ✅
查询吞吐量 平均值 每秒处理的查询数 高流量搜索应用 16.33操作/秒 0.025操作/秒 -99.85% M7g ✅
匹配所有 p99延迟 全索引扫描的响应时间 系统健康检查,分析 34.25毫秒 31.87毫秒 -6.95% OM2 ✅
术语查询 p99延迟 精确匹配查询响应时间 产品目录搜索,用户查找 35.14毫秒 29.32毫秒 -16.56% OM2 ✅
范围查询 p99延迟 基于范围的查询响应时间 时间序列数据,价格过滤器 50.66毫秒 33.46毫秒 -33.95% OM2 ✅
每小时聚合 p99延迟 每小时数据分组的响应时间 指标仪表板,使用报告 72.77毫秒 49.46毫秒 -32.02% OM2 ✅
多术语聚合 p99延迟 复杂聚合响应时间 业务分析,复杂报告 2468.37毫秒 2200.92毫秒 -10.83% OM2 ✅

M7g和OM2实例之间的性能比较揭示了不同用例的明显优势。OM2在复杂查询操作中表现出色,具有更好的范围查询、聚合和术语搜索延迟,以及卓越的内存管理。然而,M7g在批量操作和吞吐量密集型任务中显示出更强的性能。

这表明对于需要一致低延迟查询性能的生产环境使用OM2,而M7g可能更适合开发环境、批处理和成本敏感的工作负载,其中原始吞吐量优先于查询复杂性。

结论

总之,我们对OpenSearch集群中OM2和M7g实例的基准测试分析揭示了明确性能模式,以指导基础设施决策。OM2实例在复杂查询操作、内存管理和一致低延迟响应方面表现出卓越性能,使其成为具有要求苛刻的搜索和分析工作负载的生产环境的理想选择。M7g实例在批量操作和高吞吐量场景中表现出色,为开发环境和批处理任务提供成本效益高的解决方案。

跨指标的显著性能变化强调了将实例选择与特定工作负载要求对齐的重要性。组织应仔细评估其用例,考虑查询复杂性、吞吐量需求和成本约束等因素,以选择最合适的实例类型或考虑混合方法以获得最佳性能。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计