如何理解Elasticsearch Benchmarks：深入解读性能测试背后的秘密

字数 4798，阅读大约需 24 分钟

引言

在构建和维护Elasticsearch集群时，性能是一个永恒的话题。无论是选择合适的硬件配置、调整集群参数，还是决定是否升级到新版本，我们都需要可靠的性能数据作为决策依据。Elasticsearch官方提供的Elasticsearch Benchmarks平台正是为此而生，它通过标准化的测试环境和方法，为我们提供了宝贵的性能参考数据。

然而，对于许多用户来说，理解这些基准测试结果并不容易。仪表板上各种曲线、不同的测试环境、各种car配置以及众多的指标，都可能让人感到困惑。本文旨在深入浅出地解释Elasticsearch Benchmarks的核心概念，帮助你理解这些测试结果背后的含义，从而更好地应用于实际工作中。

Elasticsearch Benchmarks概述

什么是Elasticsearch Benchmarks？

Elasticsearch Benchmarks是Elastic官方维护的性能基准测试平台，它基于Rally工具，对Elasticsearch的各个版本在标准化环境下进行性能测试。这些测试结果被公开发布，供社区参考。

为什么需要Elasticsearch Benchmarks？

1. 性能基线参考：提供标准化的性能数据，作为评估自身集群性能的参考
2. 版本间比较：帮助用户了解不同版本间的性能变化，辅助升级决策
3. 配置优化指导：通过不同配置的性能对比，指导用户进行集群优化
4. 性能回归检测：帮助Elasticsearch开发团队及时发现并修复性能回归问题

Elasticsearch Benchmarks的核心组件

1. Rally：Elasticsearch的专用基准测试工具
2. Track：测试数据集和操作序列，如geonames、http_logs等
3. Challenge：特定的测试场景，如索引、搜索等
4. Car：Elasticsearch的配置方案，如堆内存大小、节点数等
5. Environment：测试环境，如nightly、serverless等

测试环境详解

硬件配置

Elasticsearch Benchmarks的测试环境主要为裸金属服务器，具体配置如下：

• CPU：Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz，这是一款4核8线程的处理器
• 内存：32GB RAM
• 存储：Micron_1100_MTFDDAK512TBN SSD
• 网络：专用10GBit交换网络
• 操作系统：Linux，内核版本5.4.0-65

值得注意的是，这些服务器配置了特定的系统参数以优化性能：

• /sys/kernel/mm/transparent_hugepage/enabled = always
• /sys/kernel/mm/transparent_hugepage/defrag = always
• /sys/devices/system/cpu/intel_pstate/no_turbo = 1

测试架构

测试架构由4台服务器组成：

• 1台运行Rally（基准测试驱动程序）
• 3台运行Elasticsearch节点（每台一个节点）

这种架构设计旨在模拟小型到中型的Elasticsearch集群，而非大规模部署。正如官方文档所述，这些测试"不是可扩展性测试，而是展示Elasticsearch从一个节点到最多三个节点的性能特征"。

解答读者关心的问题

1. 机型规格

问题：Elasticsearch Benchmarks中使用的服务器硬件配置是怎样的？

在Elasticsearch Benchmarks中，主要测试环境使用的是Intel i7-7700 CPU，这是一款4核8线程的处理器。这一点需要特别注意，因为在解读性能数据时，需要考虑到这一硬件规格。

对于特定的测试场景，如ARM架构的测试，会使用不同的硬件。例如，"NYC taxis (ARM)"测试使用的是AWS Graviton 2处理器的m6gd.metal实例。

在每次运行 Benchmarks 时，对应服务器的资源会全部用于计算，也就是Intel i7-7700 CPU的计算能力（所有 CPU 核）会在索引，处理，搜索，聚合的每个阶段都会全部使用。

2. 不同car的含义

问题：下面不同的car是什么意思？add-4g-3nodes、add-defaults、add-4g、add-sorted-4g、update-4g

在Elasticsearch Benchmarks中，"car"代表Elasticsearch的配置方案。不同的car反映了不同的Elasticsearch配置，主要包括堆内存大小、节点数量、特殊设置等。让我们逐一解析这些car的含义：

• add-4g-3nodes：使用4GB堆内存的Elasticsearch配置，部署在3个节点上。"add"表示这是一个追加（append）操作的测试场景。
• add-defaults：使用默认配置（通常是1GB堆内存）的Elasticsearch。"add"同样表示追加操作。
• add-4g：使用4GB堆内存的Elasticsearch配置，通常是单节点部署。
• add-sorted-4g：使用4GB堆内存，并且数据是有序追加的（sorted append），这对索引性能有显著影响。
• update-4g：使用4GB堆内存，测试场景是更新（update）操作而非追加。

此外，还有一些其他常见的car配置：

• no-src-4g：禁用_source字段存储，使用4GB堆内存
• no-src-4g-grok：禁用_source字段存储，使用4GB堆内存，并使用grok处理管道
• security-4g：启用安全功能，使用4GB堆内存

car的命名通常遵循一定的模式：[操作类型]-[特殊配置]-[堆内存大小]-[节点数量(可选)]。

你可以通过esrally list cars命令，查看默认的 cars:

    ____        ____
   / __ \____ _/ / /_  __
  / /_/ / __ `/ / / / / /
 / _, _/ /_/ / / / /_/ /
/_/ |_|\__,_/_/_/\__, /
                /____/

Name                     Type    Description
-----------------------  ------  ----------------------------------
16gheap                  car     Sets the Java heap to 16GB
1gheap                   car     Sets the Java heap to 1GB
2gheap                   car     Sets the Java heap to 2GB
4gheap                   car     Sets the Java heap to 4GB
8gheap                   car     Sets the Java heap to 8GB
defaults                 car     Sets the Java heap to 1GB
ea                       mixin   Enables Java assertions
fp                       mixin   Preserves frame pointers
x-pack-ml                mixin   X-Pack Machine Learning
x-pack-monitoring-http   mixin   X-Pack Monitoring (HTTP exporter)
x-pack-monitoring-local  mixin   X-Pack Monitoring (local exporter)
x-pack-security          mixin   X-Pack Security

3. 不同environment的含义

问题：下面不同的environment是什么意思？serverless-nightly、adhoc、arm、nightly

在Elasticsearch Benchmarks中，"environment"表示测试的运行环境和目的。不同的environment代表不同的测试上下文：

• nightly：标准的每日测试环境，使用x86架构的裸金属服务器，这是最常见的测试环境，用于监控主分支的性能。
• arm：使用ARM架构处理器的测试环境，通常运行在AWS的Graviton实例上，用于监控Elasticsearch在ARM架构上的性能。
• serverless-nightly：针对Elastic Serverless（Elastic Cloud的无服务器产品）的每日测试，用于评估和监控无服务器部署模式下的性能。
• adhoc：临时性测试环境，通常用于特定目的的一次性测试，如验证某个特性或修复。

其他可能遇到的environment还有：

• baseline：作为基准比较的环境
• release：针对正式发布版本的测试
• snapshot：针对快照版本的测试

environment的设置允许将不同上下文的测试结果分开存储和比较，避免混淆。

如何解读仪表板中的曲线

Elasticsearch Benchmarks仪表板中的曲线是理解性能测试结果的关键。这些曲线通常展示了随时间变化的性能指标，让我们来详细解析如何阅读和理解这些数据。

常见指标类型

1. 吞吐量（Throughput）：
   • 单位通常是ops/s（每秒操作数）或docs/s（每秒文档数）
   • 曲线越高表示性能越好
   • 波动通常反映了系统的稳定性
2. 延迟（Latency）：
   • 单位通常是ms（毫秒）
   • 曲线越低表示性能越好
   • 包括平均延迟、中位数延迟、90/99百分位延迟等
3. 资源使用：
   • CPU使用率
   • 内存使用
   • 磁盘I/O
   • 网络流量

曲线解读示例

以PMC track的nightly测试为例：

1. 索引吞吐量（Indexing Throughput）：
   • 不同颜色的曲线代表不同的car配置
   • 纵轴是每秒索引的文档数（docs/s）
   • 横轴是时间（日期）
   • 如果看到某条曲线突然下降，可能表示该版本存在性能回归
2. 查询延迟（Query Latency）：
   • 多条曲线代表不同类型的查询或不同的car配置
   • 纵轴是查询响应时间（ms）
   • 横轴是时间（日期）
   • 稳定的曲线表示查询性能稳定，突然的峰值可能表示性能问题
3. 合并时间（Merge Times）：
   • 展示了索引合并所需的时间
   • 对于理解索引性能至关重要
   • 通常与索引大小和分段数量相关

如何比较不同配置

当仪表板上显示多条曲线时，我们可以通过以下方式进行比较：

1. 基线比较：
   • 选择一条曲线作为基线（通常是默认配置）
   • 观察其他配置相对于基线的性能差异
   • 例如，比较"add-4g"和"add-defaults"可以了解增加堆内存对性能的影响
2. 趋势分析：
   • 关注曲线的长期趋势而非短期波动
   • 上升趋势表示性能改进，下降趋势表示性能退化
   • 周期性波动可能与测试环境或数据变化有关
3. 异常检测：
   • 寻找曲线中的异常点或突变
   • 这些通常表示版本更新、配置变更或环境变化
   • 在官方文档中，通常会记录这些变化点

Race、Car、Environment和Hardware Source之间的关系

理解Elasticsearch Benchmarks中各组件之间的关系，对于正确解读测试结果至关重要。下面我们详细解析Race、Car、Environment和Hardware Source之间的层次关系和相互作用。

组件层次结构

1. Environment（环境层）：
   • 定义了测试的整体环境和目的
   • 决定了使用的硬件平台（x86或ARM）
   • 例如：nightly、arm、serverless-nightly
2. Hardware Source（硬件层）：
   • 具体的硬件配置，如CPU型号、内存大小、存储类型
   • 在同一Environment中可能有不同的Hardware Source
   • 例如：Intel i7-7700 + 32GB RAM + SSD存储
3. Car（软件配置层）：
   • Elasticsearch的具体配置方案
   • 包括堆内存大小、节点数量、特殊设置等
   • 例如：4gheap、defaults、4gheap+security
4. Race（测试执行层）：
   • 单次测试执行的实例
   • 包含特定的Track、Challenge和Car组合
   • 生成具体的性能指标数据

组件间的关系

当Rally执行一次Race时，这些组件的关系如下：

1. Environment确定测试上下文：
   • 选择适当的测试环境（如nightly）
   • 决定测试的目的和范围
2. Hardware Source提供物理资源：
   • 基于Environment选择合适的硬件
   • 为测试提供计算、存储和网络资源
3. Car配置Elasticsearch实例：
   • 在选定的硬件上部署特定配置的Elasticsearch
   • 例如，在3台服务器上部署使用4GB堆内存的Elasticsearch节点
4. Race执行具体测试：
   • 运行特定的Track和Challenge
   • 收集并记录性能指标
   • 生成可视化结果

实例分析

以"PMC track的nightly测试"为例：

1. Environment = nightly：
   • 使用标准的每日测试环境
   • 在x86架构的裸金属服务器上运行
2. Hardware Source = Intel i7-7700 + 32GB RAM：
   • 4核8线程处理器
   • 32GB系统内存
   • Micron SSD存储
3. Car = add-4g：
   • 单节点Elasticsearch部署
   • 4GB Java堆内存
   • 用于追加操作的测试
4. Race = PMC track + append-no-conflicts challenge + add-4g car：
   • 使用PMC数据集（医学文献）
   • 执行无冲突的追加操作
   • 收集索引吞吐量、查询延迟等指标

通过这种层次结构，Elasticsearch Benchmarks能够系统地测试不同配置和环境下的性能，为用户提供全面的参考数据。

如何应用Benchmark结果到实际工作中

理解了Elasticsearch Benchmarks的原理和指标含义后，关键问题是如何将这些知识应用到实际工作中。以下是一些实用的应用方法和建议。

版本升级决策

在考虑是否升级Elasticsearch版本时，可以通过以下步骤利用Benchmark结果：

1. 找到与你环境最接近的测试配置：
   • 选择类似的car配置（如堆内存大小）
   • 选择与你的用例相似的track（如全文搜索、日志分析等）
2. 比较版本间的性能差异：
   • 观察关键指标（如吞吐量、延迟）在不同版本间的变化
   • 特别关注你最关心的操作类型（如索引、搜索、聚合）
3. 评估升级收益与风险：
   • 如果新版本在benchmark中显示明显的性能提升，升级可能值得考虑
   • 如果性能变化不大或有所下降，需要权衡新功能与性能之间的取舍

硬件规划和容量估算

Benchmark结果可以帮助你进行硬件规划和容量估算：

1. 性能与硬件关系分析：
   • 比较不同节点数量的性能差异（如add-4g vs add-4g-3nodes）
   • 了解增加内存对性能的影响（如add-defaults vs add-4g）
2. 容量估算：
   • 基于benchmark的吞吐量数据，估算处理特定数据量所需的资源
   • 考虑到benchmark环境与生产环境的差异，通常需要添加安全系数
3. 瓶颈识别：
   • 分析不同资源指标（CPU、内存、I/O）的使用情况
   • 识别潜在的性能瓶颈，指导硬件配置决策

配置优化

Benchmark结果可以为Elasticsearch配置优化提供指导：

1. 参数调优参考：
   • 观察不同car配置的性能差异
   • 了解特定设置（如禁用_source字段）对性能的影响
2. 索引策略优化：
   • 比较不同索引策略的性能（如sorted vs unsorted）
   • 评估特殊功能（如安全特性）的性能开销
3. 查询优化：
   • 分析不同类型查询的性能特征
   • 识别可能的查询优化方向

性能问题诊断

当遇到性能问题时，Benchmark结果可以作为参考基线：

1. 性能基线比较：
   • 将你的集群性能与benchmark结果进行比较
   • 识别显著偏离的指标，作为问题诊断的起点
2. 模式识别：
   • 查看benchmark中类似场景下的性能模式
   • 识别可能的性能问题原因
3. 优化方向确定：
   • 基于benchmark中不同配置的性能差异
   • 确定可能的优化方向和策略

实际案例分析

为了更具体地说明如何应用Elasticsearch Benchmarks，让我们通过几个实际案例进行分析。

案例1：评估安全功能的性能影响

场景：一个组织需要决定是否在其Elasticsearch集群中启用安全功能，但担心这会对性能产生负面影响。

分析步骤：

1. 在benchmark仪表板中，比较"add-4g"和"security-4g"两种car配置
2. 观察索引吞吐量和查询延迟的差异
3. 根据实际工作负载的特点，评估性能影响的可接受程度

结论：通过benchmark数据，该组织发现启用安全功能后，索引吞吐量下降约10-15%，查询延迟增加约5-10%。考虑到安全需求的重要性，这一性能影响被认为是可接受的，因此决定启用安全功能。

案例2：容量规划

场景：一个公司计划部署新的Elasticsearch集群，需要估算处理每日5000万文档所需的节点数量。

分析步骤：

1. 在benchmark中找到与其数据模型最接近的track（如http_logs）
2. 观察单节点和三节点配置的索引吞吐量
3. 计算处理目标数据量所需的时间和资源

结论：benchmark显示单节点配置（add-4g）的索引吞吐量约为13,000 docs/s，三节点配置（add-4g-3nodes）约为20,000 docs/s。考虑到每日5000万文档，以及留出足够的处理窗口（8小时），该公司决定部署一个3节点集群，预计能够在约40分钟内完成索引工作，留出充足的余量。

案例3：版本升级评估

场景：一个团队正在考虑从Elasticsearch 7.10升级到8.0，但担心可能的性能变化。

分析步骤：

1. 在benchmark仪表板中，观察跨版本的性能趋势
2. 特别关注团队最关心的操作类型（如聚合查询）
3. 评估新版本的性能变化是否符合预期

结论：通过分析benchmark数据，团队发现在8.0版本中，大多数查询操作的性能有10-20%的提升，但某些复杂聚合的性能略有下降（约5%）。考虑到8.0版本的新功能和整体性能改进，团队决定进行升级，但计划对那些复杂聚合查询进行优化。

理解Benchmark的局限性

虽然Elasticsearch Benchmarks提供了宝贵的性能数据，但理解其局限性同样重要，这有助于我们更准确地解读和应用这些结果。

环境差异

Benchmark环境与实际生产环境通常存在显著差异：

1. 硬件差异：
   • Benchmark使用特定的硬件配置（Intel i7-7700，32GB RAM）
   • 生产环境可能使用不同的CPU架构、内存配置和存储类型
   • 云环境中的虚拟化层会引入额外的性能变量
2. 规模差异：
   • Benchmark主要测试1-3个节点的小型集群
   • 生产环境可能是数十甚至数百个节点的大型集群
   • 大规模集群面临的网络、协调和资源竞争问题在小型测试中无法完全模拟
3. 工作负载差异：
   • Benchmark使用标准化的数据集和查询模式
   • 实际工作负载通常更加复杂和多样化
   • 特定的数据模式和访问模式可能导致不同的性能特征

解读注意事项

在解读Benchmark结果时，应注意以下几点：

1. 相对比较而非绝对值：
   • 关注不同配置间的相对性能差异，而非绝对性能数值
   • 例如，如果benchmark显示配置A比配置B快30%，这一相对关系在不同环境中可能仍然成立
2. 趋势分析优于单点比较：
   • 关注性能指标的长期趋势
   • 单次测试结果可能受到临时因素的影响
3. 综合考虑多个指标：
   • 不要仅关注单一指标（如吞吐量）
   • 综合考虑延迟、资源使用等多个维度
   • 在某些场景下，较低的吞吐量但更稳定的延迟可能更为重要

结论

Elasticsearch Benchmarks是理解Elasticsearch性能特征的宝贵资源。通过深入理解其测试环境、指标含义和各组件之间的关系，我们可以更有效地解读这些性能数据，并将其应用到实际工作中。

关键要点总结：

1. 测试环境：Elasticsearch Benchmarks使用标准化的硬件环境（Intel i7-7700 4核8线程CPU，32GB RAM），主要测试1-3节点的小型集群。
2. 核心概念：
   • Car：Elasticsearch的配置方案，如堆内存大小、节点数量等
   • Environment：测试的运行环境和目的，如nightly、arm、serverless-nightly
   • Track：测试数据集和操作序列，如geonames、http_logs等
   • Race：单次测试执行的实例，包含特定的Track、Challenge和Car组合
3. 指标解读：关注吞吐量、延迟、资源使用等关键指标，理解它们在不同配置下的变化和趋势。
4. 实际应用：将benchmark结果应用于版本升级决策、硬件规划、配置优化和性能问题诊断。
5. 局限性：认识到benchmark环境与生产环境的差异，合理解读和应用测试结果。

通过正确理解和应用Elasticsearch Benchmarks，我们可以做出更明智的决策，构建更高效、更可靠的Elasticsearch系统，为用户提供更好的搜索和分析体验。

无论你是Elasticsearch的新手还是经验丰富的专家，希望本文能帮助你更好地理解和利用这一强大的性能测试资源，为你的Elasticsearch之旅提供有力支持。