Milvus还是Elasticsearch：同为0.83召回率，18毫秒不等于稳赢
科技
OpenSearch还是Elasticsearch：基准领先者会随负载翻转
OpenSearch与Elasticsearch没有跨负载的固定性能赢家。AWS委托的Trail of Bits基准测试显示，在OpenSearch 2.17.1与Elasticsearch 8.15.4之间，前者的Big5综合查询结果约快1.6倍，默认配置的向量负载约快11%；文本查询类别却由Elasticsearch领先。
因此，以全文检索为主的服务不能直接采用综合排名，以聚合为主的分析系统也不能只看文本查询结果。选型还取决于许可证和迁移起点：旧索引能否使用、应用客户端能否正常工作，都会改变从公开延迟数据推算出的收益。
综合排名为何掩盖文本查询与聚合的反转
Big5把文本查询、排序、词项聚合、范围查询和日期直方图纳入同一负载。测试记录客户端从发出请求到收到响应的第90百分位服务时间，因此数值包含网络传输和序列化等开销；随后对多次运行取中位数，再计算几何平均值。它呈现的是这组操作的整体表现，并未按某个业务的真实请求量加权。
分项数据把领先方向分得更清楚。以下数值均为该测试中各类别操作的中位数第90百分位服务时间的几何平均值，顺序为OpenSearch、Elasticsearch；时间越短，响应越快。
- 文本查询为18.11毫秒、7.47毫秒，Elasticsearch在这一类别更快。该类别还计入使用match_all的默认查询和scroll操作，不能将其简单理解为普通关键词搜索的单项成绩。
- 词项聚合为104.90毫秒、354.52毫秒，领先方向转向OpenSearch。对频繁按字段分桶的负载，这组差距比综合平均值更有针对性。
- 日期直方图为124.79毫秒、2064.61毫秒，同样由OpenSearch领先。排序和范围查询的两组数值则接近，不能据此预期明显的业务收益。
综合结果为12.1毫秒对18.8毫秒，反映了测试选定操作的几何平均值，而不是生产请求的加权平均延迟。一个主要返回关键词匹配结果的接口，与一个持续生成时间分桶的日志分析服务，查询构成不同，就可能从同一组数据得到不同的选型结论。
测试使用新建的AWS实例，预热后重复运行，并保留异常运行数据。这些安排有助于理解公开结果的边界：这里比较的是指定版本、工作负载和环境下的响应时间；索引布局、缓存状态、并发量与数据分布改变后，实际延迟仍需重新测量。
向量搜索还要区分查询引擎与整条请求链
向量负载使用近似最近邻查询，数据集包含1000万个768维向量。在所测版本的默认配置中，OpenSearch使用NMSLIB，Elasticsearch使用Lucene；两者召回率接近，OpenSearch的第90百分位服务时间约低11%。这是一组具体配置的比较，不能外推到任意向量引擎组合。
更换OpenSearch的引擎后，排名甚至再次翻转：使用FAISS时，相对Elasticsearch的Lucene配置约快13.8%；使用OpenSearch的Lucene引擎时，服务时间却约高258.2%。因此，产品名称之外还必须写清引擎、参数和召回质量。只比较耗时而不核对返回结果质量，可能把检索效果的变化误判为性能优势。
OpenSearch向量搜索API文档列出k-NN与Neural Search插件提供的向量查询、神经查询、嵌入生成及重排能力。公开负载测量的是近似最近邻查询，不能代替对嵌入生成、过滤、混合检索或重排后整条请求链的测量。若应用实际经过这些环节，端到端延迟、召回质量和资源消耗应分别比较。
许可证与索引兼容性会改变迁移成本
OpenSearch项目FAQ说明，该项目采用Apache 2.0许可证，可使用由Elasticsearch 6.0至7.10创建的索引；这一索引范围不等于任意版本集群都可直接滚动升级。对于需要修改、嵌入或再分发搜索引擎的团队，许可证赋予的权利是架构选择的一部分；对于迁移项目，源索引版本则决定能否沿用现有数据结构。
Elasticsearch需要把源码许可与实际部署的发行版分开看。Elastic许可证说明列出免费部分源码的AGPLv3、SSPL和Elastic License 2.0选项，同时指出官方默认发行版继续采用Elastic License 2.0。源码增加许可选项，并不会自动改变已下载发行版适用的条款；将两者混为一谈，容易误判嵌入、分发或托管方案的条件。
许可证不会改变某条查询的实测毫秒数，却会影响产品如何交付。若只是内部部署，团队仍需核对所用版本和功能的条款；若要把引擎放入对外交付的软件或服务，更应先明确采用源码构建还是官方发行版，再计算性能收益与改造投入。
迁移前需要核对哪些兼容边界
索引、请求和客户端是迁移检查的三个不同层面。源索引超出前述兼容范围时，应规划数据导出或重新索引，并校验文档数量、映射与查询结果；能够连接目标集群，也不代表应用使用的查询语法、聚合、摄取流程和插件接口都能保持原有行为。
OpenSearch客户端文档指出，适用于Elasticsearch OSS 7.10.2的旧客户端通常可与OpenSearch 1.x配合，但OpenSearch 2.0及以后没有完全兼容的Elasticsearch客户端，项目建议使用对应的OpenSearch客户端。迁移时应核对应用依赖的客户端版本，并验证连接时的版本检查、批量写入、分页、异常处理及返回对象，而非只做一次简单读写。
一份有用的迁移检查表应覆盖：
- 索引：记录源索引的创建版本、映射、分词器与重建路径，并校验迁移后的文档和查询结果。
- 接口：列出实际使用的查询DSL、聚合、摄取流程和插件功能，逐项检查目标端行为。
- 客户端：盘点语言客户端及其版本，确认是否需要替换，并测试应用真正使用的请求和错误处理路径。
- 性能：用生产查询组合分别测文本、聚合和向量操作；向量请求同时固定召回目标，记录引擎配置与端到端延迟。
新建系统可以把分项成绩作为确定测试重点的线索：文本查询占主导时关注Elasticsearch领先的类别，频繁做词项或时间聚合时关注OpenSearch的优势，向量应用则比较具体引擎和完整请求链。迁移系统还需把重建索引、更换客户端及验证结果一致性的工作量纳入选择，才可能判断性能差距是否值得承担改造成本。
相关阅读：
相关文章
订阅我们的新闻通讯
将最新 Web3、AI 和加密货币新闻直接发送到您的邮箱。
0