OpenSearch与Elasticsearch基准测试 - Trail of Bits博客

概述与影响

本文完成了一项为期四个月的性能研究，使用OpenSearch Benchmark（OSB）在现实场景中对OpenSearch和Elasticsearch搜索引擎进行测试。我们的完整报告包含详细发现和多个版本应用的比较结果。我们未修改任何代码库。

运行搜索驱动应用的组织——从电子商务网站的产品搜索到金融机构的实时市场分析——严重依赖搜索引擎性能。OpenSearch和Elasticsearch支持快速、可扩展且高效的数据检索，使其成为网站搜索、时间序列日志分析、商业智能和网络安全监控等应用的关键。两者也越来越多地用于生成式AI、机器学习和向量应用。

当毫秒级延迟可能影响用户体验或业务运营时，即使微小的性能差异也可能带来显著成本。亚马逊网络服务（AWS）要求我们进行独立的基准评估，比较这两个知名的搜索与分析软件套件。

根据我们的独立评估，在聚合查询的几何平均数时，我们观察到OpenSearch v2.17.1在Big5工作负载上比Elasticsearch v8.15.4快1.6倍，在向量搜索工作负载上快11%。然而，对这两个应用进行基准测试是一个移动目标，因为OpenSearch和Elasticsearch都有频繁的产品发布周期。

在我们的测试过程中，Elasticsearch将其产品更新至版本8.17.0，OpenSearch发布了版本2.18.0。我们开发了可重用代码，自动化在AWS云基础设施上对两个平台进行可重复测试和分析。

本评论比较了OpenSearch和Elasticsearch在OpenSearch Benchmark工作负载上的查询延迟。OSB使用客户端服务时间指标（以毫秒为单位）进行此目的；它表示请求（即查询）接收响应所需的时间。这包括开销（网络延迟、负载均衡器开销、序列化/反序列化等）。OSB记录每个操作的服务时间的第90百分位数（p90）。

范围限于两个引擎的Apache v2（OpenSearch）和Elastic 2.0（Elasticsearch）许可版本，不包括专有系统。结果可用于指导每个引擎各个组件的未来开发。

虽然完整报告中评估了六个OSB工作负载，但本博客文章重点介绍了Big5（一个执行文本查询、排序、日期直方图、范围查询和术语聚合的综合工作负载）和Vectorsearch（使用近似K-最近邻（KNN）搜索查询1000万个768维向量数据集的工作负载）的结果。我们比较了OpenSearch和Elasticsearch的最新版本——分别是v2.17.1（2024年10月16日发布）和v8.15.4（2024年11月12日发布）。

图1说明了我们在Big5和Vectorsearch工作负载上比较OpenSearch与Elasticsearch的结果：

图1：p90服务时间中位数的几何平均数比率（毫秒）

图2：p90服务时间中位数的几何平均数比率（毫秒）。注意，由于Elasticsearch仅支持Lucene，其他与OpenSearch执行的引擎（NMSLIB和FAISS）与与Elasticsearch执行的Lucene进行比较

观察与影响

方法论

我们每天执行一次OpenSearch和Elasticsearch工作负载，持续15天——除了Vectorsearch，我们运行了11天。我们为每个引擎的每个工作负载收集了11到15次测试。每次设置全新的AWS实例，并连续执行工作负载五次。我们丢弃第一次运行，以确保硬件、操作系统和应用缓存为两个引擎预热。工作负载中的每个操作执行了数百到数千次。这导致每个操作有数千到数万个样本测量。我们相信这是一个足够大的样本量，可以得出可靠的结论。

结果处理与统计分析

我们观察到一些操作（主要是服务时间值小于一毫秒的操作）的统计功效低于我们选择的90%阈值，尽管p值较低：这表明可以检测到统计显著差异，但其幅度无法可靠观察。因此，我们额外运行了这些操作以增加其统计功效。之后，我们确认在上述任务中，OpenSearch和Elasticsearch性能特征之间的任何统计显著差异都是无关紧要的。然而，用户可能更关心运行时间较长的查询性能，而不是在几毫秒内完成的查询。

异常值

我们计算了每个工作负载操作的p90服务时间的中位数。我们这样做是因为我们在OpenSearch和Elasticsearch的多次运行中看到了显著的性能变化。这些异常值可能影响算术平均值。我们选择不统计排除这些异常值（例如，使用标准差或四分位数作为排除标准），因为结果不一定遵循高斯（正态）分布。因此，我们相信跨大量独立数据点的中位数最能代表我们为OpenSearch和Elasticsearch计算的汇总统计。为完整起见，完整报告包括火花线，视觉指示查询间的方差程度。

有了我们的方法论，让我们检查广泛测试揭示了这些搜索引擎的哪些性能特征。

Big5工作负载概述

Big5工作负载包含一组精心设计的查询，练习OpenSearch和Elasticsearch中所有主要功能。它们分为以下类别。对于此性能比较，每个查询权重相同。

• 文本查询：搜索文本是任何搜索引擎或数据库的基础。输入自然语言查询对用户直观，不需要了解底层模式，使其易于搜索非结构化数据。
• 术语聚合：此查询类型根据指定的聚合值将文档分组到桶中，这对数据分析用例至关重要。
• 排序：评估按字母、数字、时间顺序等排列数据。此功能用于根据特定标准组织搜索结果，确保向用户呈现最相关的结果。
• 日期直方图：这对于通过将基于时间的数据划分为间隔来聚合和分析它很有用。它允许用户可视化并更好地理解随时间变化的趋势、模式和异常。
• 范围查询：这对于基于给定字段中的特定值范围过滤搜索结果很有用。此功能让用户快速缩小搜索结果并找到更相关信息。

Big5工作负载类别结果

使用Big5工作负载中所有查询操作中位数值的几何平均数，我们观察到OpenSearch v2.17.1比Elasticsearch v8.15.4快1.6倍。下面，我们提供关于如何得出此估计的更多细节。

首先，为确保测试方法准确，我们参考了OpenSearch项目最近关于其v2.17性能测量的博客文章。我们将他们报告的性能（见其文章的结果部分）与我们的比较在下表中。这包括Big5中的所有操作，同时跳过match_all查询（在工作负载中名为default）和scroll查询。这与文章中遵循的协议相同。

表1：为OpenSearch建立基线

注意，OpenSearch项目每晚在https://opensearch.org/benchmarks发布其性能数字。

由于这些值合理接近（尽管略有不同，最可能由于不同版本号），我们将运行OpenSearch v2.17.1的结果与Elasticsearch v8.15.4比较。

上述原始博客文章不包括两个Big5操作：default和scroll。两者都使用match_all查询，返回所有文档。下面，我们添加并将它们分类为文本查询。

表2：OpenSearch与Elasticsearch的Big5比较

接下来，我们评估全面的Big5工作负载测试结果以理解这些观察，这些练习了核心搜索引擎功能。

Big5工作负载操作结果

以下图表显示了Big5工作负载中每个类别的单个查询操作在 median p90服务时间上的差异。y轴表示操作，x轴表示一个引擎（OpenSearch或Elasticsearch）比另一个快多少倍。

• 图3：文本查询操作
• 图4：排序操作
• 图5：术语聚合操作
• 图6：范围查询操作
• 图7：日期直方图操作

向量搜索工作负载结果

检查了传统搜索操作后，我们现在转向向量搜索功能，这对使用AI/ML技术的现代应用越来越重要。这里，我们讨论Vectorsearch工作负载结果。默认启用force-merge。

OpenSearch支持三个向量搜索引擎：NMSLIB、FAISS和Lucene。这些引擎迎合各种算法（HNSW、HNSW+PQ、IVF和IVF+PQ）和量化技术（fp16、2倍压缩到二进制、32倍压缩），基于不同的用户工作负载。OpenSearch 2.17.1的默认向量引擎是NMSLIB。2.17之后的较新版本已切换到FAISS。

另一方面，Elasticsearch仅支持Lucene。下面图表中Elasticsearch的任何报告值表示使用Lucene引擎的测试运行。为简洁起见，我们以以下格式指定搜索引擎和使用的向量搜索引擎：搜索引擎（向量引擎）。

Vectorsearch工作负载包含一个主要查询：prod-queries，对摄取的数据进行向量搜索，并计算ANN搜索的召回率。

与Big5类似，我们比较 median p90服务时间值。专注于各自默认配置引擎（OpenSearch的NMSLIB和Elasticsearch的Lucene）的开箱即用体验，OpenSearch在此指标上比Elasticsearch快11%，具有相似的召回率和相同的超参数值。

向量搜索性能细节

比较每个OpenSearch v2.17.1向量引擎与Elasticsearch（Lucene）v8.15.4得出以下发现：

• OpenSearch（NMSLIB）快11.3%。
• OpenSearch（FAISS）快13.8%。
• OpenSearch（Lucene）慢258.2%。

中位数值如下：

图8：向量搜索引擎比较

以下是比较OpenSearch和Elasticsearch在Vectorsearch工作负载上的火花线。x轴表示时间，y轴表示p90服务时间（毫秒）。最小和最大值分别表示每个火花线y轴的最小和最大值。每行中的一对火花线以相同的y轴绘制。所有Elasticsearch火花线绘制相同数据，但由于不同的y轴最小和最大值，它们彼此不同。

图9：OpenSearch和Elasticsearch在Vectorsearch工作负载上的火花线比较

如上所示，OpenSearch（Lucene）的性能变化。虽然这描绘了相对性能的清晰图景，但我们的测试也揭示了一些关于一致性的重要注意事项，用户应考虑。

性能不一致性

我们观察到OpenSearch和Elasticsearch的p90服务时间有慢异常运行。我们调查了这些场景，但无法确定根本原因。例如，注意上图9中OpenSearch（Lucene）的随机峰值。虽然这些异常不影响我们的总体结论，但它们值得进一步调查。我们在计算结果时仍将异常值包含在数据集中，因为没有系统的方法移除它们。

我们可以通过最大服务时间与中位服务时间的比率来量化异常值的极端程度。使用此比率，我们发现OpenSearch的异常值比Elasticsearch更极端。OpenSearch和Elasticsearch比率最极端的任务是：

• OpenSearch 2.17.1: composite-date_histogram-daily的1412倍
• Elasticsearch 8.15.4: query-string-on-message的43倍

我们使用运行值比中位数慢两倍以上的标准计算了多少任务有异常运行。我们发现Elasticsearch比OpenSearch有更多异常值：

• OpenSearch 2.17.1: 98个任务中的11个异常任务
• Elasticsearch 8.15.4: 98个任务中的19个异常任务

可重复、开源的基准测试

基于这些关于性能和一致性的发现，我们制定了几个进行可靠搜索引擎基准测试的关键建议：

• 始终在新创建的实例上运行工作负载。如果不这样做，可能无法观察到工作负载性能的变化，这会扭曲用户的期望。
• 收集数据后，测量p值和统计功效以确保统计可靠性。测量相同配置运行的p值有助于检测异常，其中在比较类似运行时期望高p值（> 0.05）。针对不同配置（如不同设置或引擎）测量以确认变化产生统计不同的结果。
• 基准测试应使用与开箱即用体验密切匹配的配置。有时，需要更改以进行公平基准测试。在这些情况下，记录更改并解释为什么它们不适合默认配置。
• 创建更一致结果的快照方法是刷新索引、刷新索引，然后等待合并完成后再拍摄快照。我们在使用Vectorsearch工作负载测试此方法时发现了有希望的初步结果，但尚未广泛测试此策略。

超越我们的具体发现，我们希望确保我们的工作可以作为未来基准测试工作的基础。我们专注于创建OpenSearch和Elasticsearch之间可重复和客观的性能比较，并使用GitHub Actions使我们的实验易于重现。这使得未来能够进行持续的性能比较。

如果您对我们如何支持您的项目感兴趣，请联系我们。

如果您喜欢这篇文章，请分享：Twitter、LinkedIn、GitHub、Mastodon、Hacker News。