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倍,在Vectorsearch工作负载上快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查询。这与文章中遵循的协议相同。
操作类别的几何平均数 – p90服务时间中位数(毫秒) 我们的结果(v2.17.1) | OpenSearch结果(v2.17) 文本查询 | 16.09 | 21.88 排序 | 5.82 | 7.49 术语聚合 | 104.90 | 114.08 范围查询 | 1.47 | 3.30 日期直方图 | 124.79 | 164.03
表1:为OpenSearch建立基线
注意:OpenSearch项目每晚在https://opensearch.org/benchmarks发布其性能数字
由于这些值合理接近(尽管略有不同,最可能由于不同版本号),我们将运行OpenSearch v2.17.1的结果与Elasticsearch v8.15.4进行比较。
上述原始博客文章未包括两个Big5操作:default和scroll。两者都使用match_all查询,返回所有文档。下面,我们添加并将它们分类为文本查询。
操作类别的几何平均数 – p90服务时间中位数(毫秒) OpenSearch v2.17.1 | Elasticsearch v8.15.4 | OpenSearch比Elasticsearch慢/快 文本查询 | 18.11 | 7.47 | 2.42倍慢 排序 | 5.82 | 6.14 | 1.05倍快 术语聚合 | 104.90 | 354.52 | 3.38倍快 范围查询 | 1.47 | 1.49 | 1.02倍快 日期直方图 | 124.79 | 2,064.61 | 16.55倍快 所有操作 | 12.11 | 8.8 | 1.56倍快
表2:OpenSearch与Elasticsearch的Big5比较
接下来,我们评估全面的Big5工作负载测试结果以理解这些观察,这些练习了核心搜索引擎功能。
Big5工作负载操作结果
以下图表显示了Big5工作负载中每个类别的单个查询操作在median p90服务时间上的差异。y轴表示操作,x轴表示一个引擎(OpenSearch或Elasticsearch)比另一个快多少倍。
图3:文本查询操作 图4:排序操作 图5:术语聚合操作 图6:范围查询操作 图7:日期直方图操作
Vectorsearch工作负载结果
检查了传统搜索操作后,我们现在转向向量搜索功能,这对使用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%,具有相似召回率和相同超参数值。
Vectorsearch性能细节
比较每个OpenSearch v2.17.1向量引擎与Elasticsearch(Lucene)v8.15.4产生了以下发现:
- OpenSearch(NMSLIB)快11.3%
- OpenSearch(FAISS)快13.8%
- OpenSearch(Lucene)慢258.2%
中位数值如下:
图8:Vectorsearch引擎比较
以下是小提琴图比较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
页面内容
观察与影响 方法论 结果处理与统计分析 异常值 Big5工作负载概述 Big5工作负载类别结果 Big5工作负载操作结果 Vectorsearch工作负载结果 Vectorsearch性能细节 性能不一致 可重复、开源的基准测试 最近文章 我们构建了MCP一直需要的安全层 利用废弃硬件中的零日漏洞 Inside EthCC[8]:成为智能合约审计员 使用Vendetect大规模检测代码复制 构建安全消息传递很难:对Bitchat安全辩论的 nuanced 看法 © 2025 Trail of Bits。 使用Hugo和Mainroad主题生成。