选择亚马逊 OpenSearch 集群的最佳实例类型对于平衡性能和成本至关重要。AWS 提供了专门的 OpenSearch OM2 实例和较新的通用 M7g 实例，组织面临重要决策。

• OM2 实例针对 OpenSearch 进行了定制，具有高内存与 vCPU 比，M7g 实例带来了最新技术，有望提升整体性能，最佳选择取决于特定工作负载特征和需求。
• 本文介绍了这些实例类型之间的综合基准比较，为 DevOps 团队和架构师提供了做出明智基础设施决策的实用见解，通过研究实际性能指标和成本影响来优化 OpenSearch 部署。

理解 OpenSearch 优化中的基准测试

• OpenSearch 中的基准测试是在受控条件下评估集群性能的系统过程，测量关键指标如查询延迟、吞吐量和资源利用率，对于分布式搜索引擎，基准测试不仅是简单的性能测试，还涉及了解集群在特定工作负载模式下的行为，为基础设施、配置和扩展策略的决策提供定量数据。

• OpenSearch 基准测试的四个基本支柱：

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

基准设置和方法

• OpenSearch Benchmark 是由 OpenSearch 项目提供的工具，可全面收集 OpenSearch 集群的性能指标，包括索引吞吐量和搜索延迟，可用于跟踪整体集群性能、为升级决策提供信息或评估工作流更改的影响。
• 比较两个集群的性能：一个由 OpenSearch 专用 OM2 实例驱动，另一个由较新的通用 M7g 实例驱动，数据集包含 1998 年世界杯网站的 HTTP 服务器日志，适用于比较实例在此类任务中的性能。
• 可以直接在运行 Linux 或 macOS 的主机上安装 OpenSearch Benchmark，也可以在任何兼容主机上的 Docker 容器中运行，它包括一组工作负载，可用于基准测试集群性能。
• 进行基准测试时，建议使用与集群用例相似的工作负载，考虑用例、数据和查询类型等标准。
• OpenSearch 基准测试过程包括环境设置、选择和配置工作负载、数据摄取、运行基准测试和分析结果五个关键步骤。

性能基准分析：OM2 与 M7g 用于亚马逊 OpenSearch

• 比较两种不同配置的 OpenSearch Service：

  • 配置 1：OpenSearch 专用 OM2 实例的集群管理器节点和两个数据节点。
  • 配置 2：较新的通用 M7g 实例的集群管理器节点和两个数据节点。
• 两种配置使用相同数量和类型的集群管理器节点：三个 c6g.xlarge。

• 以下是 OpenSearch Service 配置细节的总结：

  COMPONENT	OM2 CLUSTER	M7G CLUSTER
  CLUSTER MANAGER NODES
  Instance Type	c6g.large	c6g.large
  Count	3	3
  DATA NODES
  Instance Type	OM2.2xlarge	M7g.2xlarge
  Count	2	2
  vCPUs per node	8	8
  Memory per node	32 GiB	32 GiB
  Storage Configuration
  Volume Type	gp3	gp3
  Size	500 GB	500 GB
  IOPS	3000	3000
  OPENSEARCH CONFIGURATION
  Version	2.19	2.19
  Shards per index	5	5
  Replicas	1	1
  JVM Heap	8GB	8GB
  MONITORING
  CloudWatch Metrics	Enabled	Enabled
  Metric Frequency	1 minute	1 minute

• 性能比较结果：

  METRIC TYPE	METRIC	DESCRIPTION	USE CASE	M7G	OM2	%CHANGE	WINNER
  Indexing Performance
  Indexing Time	Primary shards	主分片的文档索引总时间	日志摄入、文档处理	87.03 min	65.68 min	-24.54%	OM2
  Flush Time	Primary shards	将索引数据持久化到磁盘的时间	大型批量更新、数据迁移	8.57 min	5.06 min	-41.03%	OM2
  GC Time	Young Gen	近期对象的垃圾收集时间	内存密集型操作	16.50 sec	7.29 sec	-55.83%	OM2
  Query Performance
  Bulk Index	p99 latency	99%的批量索引操作时间	ETL 流程、数据导入	300.02 ms	773.71 ms	+157.87%	M7g
  Query Throughput	Mean	每秒处理的查询数	高流量搜索应用程序	16.33 ops/s	0.025 ops/s	-99.85%	M7g
  Match All	p99 latency	全索引扫描的响应时间	系统健康检查、分析	34.25 ms	31.87 ms	-6.95%	OM2
  Term Query	p99 latency	精确匹配查询响应时间	产品目录搜索、用户查找	35.14 ms	29.32 ms	-16.56%	OM2
  Range Query	p99 latency	基于范围的查询响应时间	时间序列数据、价格过滤器	50.66 ms	33.46 ms	-33.95%	OM2
  Hourly Aggregation	p99 latency	每小时数据分组的响应时间	指标仪表板、使用报告	72.77 ms	49.46 ms	-32.02%	OM2
  Multi-term Aggregation	p99 latency	复杂聚合的响应时间	业务分析、复杂报告	2468.37 ms	2200.92 ms	-10.83%	OM2

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

结论

• 基准测试分析表明，OM2 实例在复杂查询操作、内存管理和一致的低延迟响应方面表现出色，适合具有高要求搜索和分析工作负载的生产环境，M7g 实例在批量操作和高吞吐量场景中表现出色，为开发环境和批处理任务提供了具有成本效益的解决方案。
• 不同指标的性能差异强调了根据特定工作负载要求选择实例的重要性，组织应仔细评估其用例，考虑查询复杂性、吞吐量需求和成本约束，以选择最合适的实例类型或考虑混合方法以实现最佳性能。