资讯评论 - OpenSearch 3.0 发布 - OSCHINA - 中文开源技术交流社区

OpenSearch 3.0 现已发布。这是自 2022 年以来 OpenSearch 项目的第一个重大版本，带来了性能、数据管理、向量数据库功能等方面的重要进展。

为什么 major 版本之间间隔三年？该项目遵循语义版本控制，避免了零点版本发布，意味着 OpenSearch 只会在重大版本中发布破坏性更改。Apache Lucene 10 的发布为 3.0 的推进提供了动力，OpenSearch 开发者社区抓住了这个机会，推出了一系列技术创新，将 OpenSearch 提升到新的能力、性能和多样性层面。感谢他们的努力，以及技术指导委员会的监督，OpenSearch 3.x 系列现已准备好，帮助你应对未来应用所需的高负载和大数据集。

成本、性能与可扩展性

OpenSearch 在性能方面取得了显著进展，并在基准测试中表现出色，致力于满足数据密集型搜索、可观测性和生成性 AI 工作负载的性能需求。3.0 版本进一步加速了这些性能提升，在高影响操作（如 desc_sort_after_timestamp、query_string_on_messagem 和 cardinality_agg_high）上相比 OpenSearch 2.19 提高了 20%；相比 OpenSearch 1.3，该版本在关键查询类型上的性能提升超过 9.5 倍。

利用 Lucene 10 升级

Apache Lucene 的最新版本在性能、效率和向量搜索功能上有显著提升。这些改进为更大规模的向量和搜索部署铺平了道路，使 AI 工作负载能够随着时间的推移成倍扩展。Lucene 10 的发布说明中包含了所有细节，以下是一些亮点：

索引性能：Lucene 10 优化了向量字段的索引过程，导致索引时间更快，向量数据的索引大小减小。
稀疏索引：在使用索引排序将相似文档分组时，稀疏索引提高了 CPU 和存储效率。
向量量化：新的压缩技术减少了内存使用，提高了查询性能。

其他改进包括通过文本/语义搜索集成改进混合搜索性能、增强引擎内性能监控等。

使用 protobuf 和 gRPC 提升数据传输性能

OpenSearch 3.0 在客户端和服务器之间实现了更高性能的数据传输，实验性支持通过 gRPC 传输的协议缓冲区（protobuf）。gRPC 利用底层的 HTTP/2 基础设施，支持多路复用和双向数据流，使客户端能够在同一 TCP 连接上并发发送和接收请求。对于处理大型复杂查询的用户来说，性能提升尤为明显，因为在使用 JSON 时请求的反序列化开销会增加。希望降低 JSON 序列化成本或更方便地将 OpenSearch 集成到现有 gRPC 生态系统中的用户，请关注我们即将发布的扩展支持。

使用基于拉取的摄取流式数据

此次发布将拉取式摄取作为实验性功能引入 OpenSearch。用户现在可以配置 OpenSearch 索引，从流式数据源获取数据，或继续通过 REST API 加载数据。拉取式摄取的一个关键优势是能够本质上处理背压和数据摄取的节奏控制，确保数据管道更加稳定和可靠。本次发布包括支持从 Apache Kafka 和 Amazon Kinesis 数据源进行拉取式摄取的插件。

将范围查询性能提高 25%

OpenSearch 3.0 引入了更智能的范围查询策略，针对数值和日期字段使用近似技术，如多级区间树过滤器。这样可以用更少的 I/O 操作回答范围过滤器。在实践中，这意味着像 timestamp >= X AND timestamp <= Y 或在大数据上的数值过滤查询将更快，减轻集群负担。这些增强特别有利于日志分析和时间序列用例，在 Big5 基准测试中相比 OpenSearch 2.19 提供了 25% 的性能提升。

将高基数聚合的延迟减少多达 75%

针对具有极高基数（大量唯一值）或宽数值范围的分析查询，OpenSearch 3.0 提供了新的优化以加速结果。其中一个改进是针对基数聚合的执行提示，用于估算唯一值计数。在拥有数百万个唯一术语的数据集中，基数聚合器可能会消耗大量内存。

现在，这个执行提示允许你选择算法策略（如 precision_threshold），在准确性和性能之间取得平衡，避免在高基数字段上占用过多内存。基于基准测试，p90 延迟减少了 75%。

支持过滤重写优化中的子聚合

OpenSearch 3.0 增强了支持子聚合的过滤重写优化，旨在减少日期直方图聚合工作负载的查询延迟。之前，该优化仅适用于没有子聚合的单层聚合；现在其性能提升也适用于任何子聚合，扩展了功能以适应更复杂的实际用例。这项优化在 Big5 工作负载中相关操作的改进幅度达到 30% 至 40%。

向量数据库与生成 AI

OpenSearch 3.0 拥有新功能，可提升性能并简化构建强大向量驱动的搜索、可观测性和生成 AI 工作负载的任务。

通过原生 MCP 协议支持增强 AI

在 3.0 版本中，OpenSearch 引入了原生模型上下文协议（MCP）支持，作为实验性功能，使与 AI 代理的无缝集成成为可能。

该开放协议标准化了大型语言模型（LLM）应用、数据源和工具之间的通信；通过 MCP 客户端支持，用户可以将现有工具和系统纳入 ML Commons 代理框架，构建更全面和可定制的 AI 驱动解决方案。在服务器端，OpenSearch 现在可以将搜索索引和获取索引统计信息等操作作为工具暴露出来，更加方便与外部 AI 代理（如 Anthropic、LangChain 和 OpenAI）的集成。

部署计划-执行-反思代理以支持复杂分析

ML Commons 代理框架的新功能是实验性的计划-执行-反思代理，可以通过规划和反思自主解决复杂任务。该代理将复杂问题拆解为可管理的步骤，选择合适的工具进行执行，并通过反思不断改进策略。例如，在分析服务错误时，代理可以自动分析日志、查询相关索引、搜索网络以查找相关问题，并总结发现帮助故障排除。

通过派生源减少多达 3 倍的存储成本

在 2.19 中首次作为实验性功能发布的 k-NN 向量的派生源在 OpenSearch 3.0 中已准备好投入生产。派生源允许你在搜索和重建索引时访问向量值，而无需在 OpenSearch 中存储整个源向量。

通过从 JSON 源中移除向量并在需要时动态注入，派生向量提高了查询性能，在 Lucene 引擎中提供了高达 30 倍的 p90 冷启动查询延迟改善，并减少了所有引擎的合并时间高达 40%。该功能还在 Faiss、Lucene 和 NMSLIB 库中表现出 3 倍的存储成本降低，为向量工作负载解锁了进一步的优化。

使用 GPU 加速构建更快的向量解决方案

向量操作计算密集，特别是在大规模时。这使得它们非常适合并行处理，而 GPU 在这方面表现出色。作为实验性功能，本次发布解锁了部署 GPU 来加速索引构建的能力，从而显著提高索引创建速度、降低运营成本并增强容错能力。根据基准测试，GPU 加速可以将索引速度提高 9.3 倍，同时将成本降低 3.75 倍。

通过语义句子高亮提高搜索结果的相关性

语义句子高亮通过使用机器学习识别和高亮相关句子，增强搜索结果的相关性，不仅仅依赖关键词匹配。与传统的基于精确文本匹配的高亮不同，这一功能通过高亮整句来捕捉上下文并保留完整的思想。

语义高亮适用于所有查询类型，包括传统、神经和混合搜索，使得即使没有精确关键词的情况下，搜索结果也更有意义。此次发布包括一个预训练的 opensearch-semantic-highlighter-v1 模型，优化了在一般领域识别语义相关句子的能力。用户可以轻松将此模型部署到集群中，并在高亮配置中引用，消除为基本语义高亮用例训练自定义模型的需求。

通过并发段搜索将二进制量化（32x）性能提高 2.5 倍

并发段搜索现已默认启用，适用于 OpenSearch k-NN 查询。启用并发段搜索后，你可以将 k-NN 查询的性能提高多达 2.5 倍，而不会影响召回率，通过在多个线程之间并行化搜索查询。本次发布还启用了合并策略中楼层段大小设置的更改，以创建更平衡的段，并将尾延迟提高多达 20%。

通过 Explain API 获得向量搜索评分的见解

从此次发布开始，你可以使用 explain 参数深入了解在使用 Faiss 引擎的 k-NN 查询中，如何计算、标准化和组合评分。该功能提供有关每个搜索结果评分过程的详细信息，揭示使用的评分标准化技术、不同评分的组合方式以及单个子查询评分的计算。这一全面的见解使得理解和优化查询结果变得更加容易。

搜索

OpenSearch 3.0 还带来了多种新功能，以增强搜索操作并改善搜索结果。

用 Z-score 标准化增强混合搜索结果

此次发布引入了 Z-score 标准化，这是一种用于混合搜索的新的统计评分标准化方法。虽然默认的基于评分的标准化方法（最小-最大标准化）对异常值的处理可能不佳，但 Z-score 标准化通过将原始评分转换为标准单位而表现出色。此技术考虑到每个子查询的评分分布，并有效处理异常值，使得不同查询类型之间的评分直接可比。这种方法显著提高了混合搜索的可靠性，减少了异常值和不同评分规模的影响，从而产生更一致和有意义的搜索结果。

通过设定最小阈值改善混合搜索结果的相关性

此次发布解决了混合搜索相关性中的一个关键限制，增加了最小-最大标准化的下限。传统的最小-最大标准化在结合神经和关键词搜索结果时，可能会不成比例地提升得分极低的文档，导致排名不理想。下限允许你在标准化过程中设定最小阈值，防止微不足道的得分被过度放大，确保标准化值保持有意义并与其实际相关性成比例。当得分低于指定下限时，将进行调整以保持适当的排名顺序，这对于一个搜索方法提供最小相关性信号的查询尤其有益。

通过支持内击改善混合查询结果

此次发布为混合查询添加了对内击的支持。内击是执行嵌套字段或父连接字段搜索操作时默认隐藏的基础命中。对于混合查询，内击是根据最终搜索结果中每个父文档提取的。父文档将显示混合得分，内击将显示归一化前的原始得分。要使用此功能，用户需要在搜索请求中添加 inner_hits 条款。

通过星树索引减少聚合查询开销

对于聚合密集型工作负载，OpenSearch 3.0 继续基于 2.19 引入的星树索引功能，显著加快某些聚合的速度。在此次发布中，星树支持扩展到处理聚合中的指标聚合和过滤术语查询；OpenSearch 能够通过读取更小的预聚合段来回答查询，而不是扫描每个文档以进行重聚合（例如，对数十亿条记录计算直方图）。早期结果显示，星树驱动的聚合查询工作减少了高达 100 倍的查询工作量，并将缓存使用量降低了 30 倍，尤其对高基数的分组操作和多层聚合有显著好处。

可观测性、日志分析与安全分析

此次发布包括支持可观测性、日志分析和安全分析工作负载的新工具。

通过 PPL 查询进步更高效地丰富和管理日志数据

此次发布为 OpenSearch 的管道处理语言（PPL）工具增加了强大的功能，包括 lookup、join 和 subsearch 命令。这些功能使用户（特别是可观测性和安全领域的用户）能够在大数据集中更高效地丰富、关联和过滤日志。

例如，安全工程师现在可以连接身份验证和应用日志以调查事件，或使用 lookup 实时丰富日志。得益于 Apache Calcite，这些增强还改善了查询规划和执行，为未来版本的更高级分析能力奠定了基础。此次发布标志着 PPL 语言在交互式数据探索中变得更加表达力强和高效的一大步。

改善查询监控和性能分析

OpenSearch 3.0 通过若干强大功能增强了查询洞察，改善查询监控和性能分析。新的实时查询 API 提供了对集群中当前执行的搜索查询的实时可见性，帮助你识别长时间运行或资源密集的操作。

这使得用户能够评估资源密集型查询的影响，并可能采取主动措施，例如取消查询，以维护系统稳定性和弹性。verbose 参数优化了仪表板性能，允许用户在不需要完整细节时获取轻量级版本的查询数据，显著减少负载大小，提高响应速度。查询洞察仪表板中的新动态列可以根据筛选选择智能适应，仅显示与查询、组或组合视图相关的指标。这些功能共同提供了更高效的监控和故障排除能力，同时在处理数千条查询记录时保持仪表板性能。

直接从 Discover 界面探索异常

此次发布还进一步增强了可观测性和日志分析工作负载的用户体验。例如，通过上下文启动，Discover 界面现在可以让你从主仪表板启动异常检测器，并在 Discover 视图中填充所有相关日志。这消除了在检测到异常后手动查询日志的需要，现在 OpenSearch 为你处理这一过程。

模块化架构

此次发布包括对 OpenSearch 模块化架构的更新，例如：

通过将远程存储集群的读取和写入分离来提高资源利用率

从此次发布开始，OpenSearch 将支持在启用远程存储的集群中分离索引和搜索流量。将索引和搜索操作分开提供故障隔离，支持独立扩展，并提高性能和成本效率，特别是对于需要高量索引和密集搜索操作的用例。对于只写一次、可多次读取的用例（如日志分析），此版本引入了新的 _scale API，允许你关闭所有写入操作，仅进行索引搜索。

安全性

OpenSearch 3.0 包括数个重要更新，帮助你维护 OpenSearch 部署的安全性。

替换 OpenSearch 3.0 中的 Java 安全管理器

在 JDK 17 中，Java 将 Java 安全管理器标记为弃用，并计划最终移除。在 JDK 24 中，Java 已永久禁用安全管理器，使其成为 Java 语言的过时部分。OpenSearch 一直依赖这一 Java 功能为在与 OpenSearch 进程同一 JVM 中运行的插件提供适当的沙盒。

在 OpenSearch 3.0 中，Java 安全管理器已被新的 Java 代理替代，提供低级别的仪表化，使 OpenSearch 能够拦截特权调用，并确保执行特权操作的调用者已被明确授予权限。新的 Java 代理以与安全管理器相同的方式进行配置，通过策略文件为指定的代码库授予执行特权操作的权限。