我要投稿

官宣|Milvus 2.6正式开源：内存减少 72%，速度比ES快4倍

发布日期：2025-06-13 19:58:34 浏览次数： 1551

作者：Zilliz

微信搜一搜，关注“Zilliz”

好消息，Milvus 2.6于今日正式上线！（目前是RC版，正式版预计在7月推出）

功能上，Milvus 2.6 延续并加强了 2.5 版本引入的全文检索功能，进一步强化了搜索功能，并整体升级底层架构以满足更严苛的性能、成本与规模需求。

除此之外，2.6版本还围绕降本增效、搜索能力增强和架构优化三大方向，致力于为大家打造一个更高效、更强大、更经济的向量数据库解决方案。

作为 2025 年 Milvus 产品路线图中的重要里程碑，Milvus 2.6将作为稳定版本维护一年时间，欢迎更多朋友尝鲜！

以下是Milvus2.6功能更新的详细介绍：

01 降本提速：极致优化，释放数据底座潜能

在降低成本和提升效率方面，Milvus 2.6 引入了多项关键改进和优化，主要方式有以下几种：

（1）RabitQ 量化：既省内存又提性能

面对海量高维度向量带来的内存资源消耗瓶颈问题，Milvus 2.6 将 RaBitQ 1 bit 量化能力引入了向量数据库的生产环境。基础的 RaBitQ 1 bit 方案可以提供理论 1/32 的内存压缩，但是也会带来召回率大幅降低（95% -> 76%）。因此，Milvus 2.6 还额外实现了 Refine 优化能力，可以提供更灵活的内存使用和精度配比。我们实现了主索引 RaBitQ 量化 + SQ6/SQ8/FP16/FP32 Refine 等多种可选方案，兼顾内存和召回率的需求。以 SQ8 refine data 为例，其综合压缩仅占原始数据约 28 %（1/32+1/4）大小，但带来了 3 倍以上的 QPS 显著提升，而召回率仍能和无量化的原始数据索引保持相同的水平。

基准：VectorDBBench 1 M / 768 D，m6id.2xlarge 单机测试

Milvus 提供的 IVF_RABITQ 索引的主要亮点包括：

内存大幅缩减：1 bit 二值化将主索引压至原来的 1/32（省内存）。可选再叠加 SQ8 精排仅需 25 % 原始空间（提 Recall），在保证精度的前提下整体内存压缩比为 1/3 。
吞吐显著提升：POPcnt 指令加速 bit‑wise 距离计算，配合 SQ8 二次精排，QPS 较 IVF_FLAT 提升 3 倍以上。
精度 / 性能可调：refine_type (SQ6/SQ8/FP16/FP32) 与 rbq_bits_query (1‑8 bit) 两个参数即可在精度‑吞吐‑成本之间自由滑动，轻松适配不同业务场景。

这一组合让 Milvus 在大规模、低成本、灵活精度之间可取得最佳平衡，是大规模图像检索、推荐系统以及文本匹配等场景的理想之选。

而在 Zilliz Cloud 的内核版本中，我们通过大量的比对实验和优化，最终也调试出一组梯度变化的最佳配置，可供不同精度性能要求的用户更方便地使用强大高效的 RaBitQ 功能。

（2）Sparse-BM25 性能提升：提供 4x Elastic Search 的检索性能

在 Milvus 2.5 的基础之上，我们设计了灵活的近似检索策略（如 drop_ratio_search 与 dim_max_score_ratio），让用户在精度与速度之间灵活调控。

而在 Zilliz Cloud 的云上版本中，我们进一步构建了更加先进的检索框架：在工程实现中引入了 SIMD 加速、数据预取机制等，引入并优化了 Block-Max WAND 与 Block-Max MaxScore 等高性能剪枝算法，相较传统的 WAND/MaxScore，在减少无效计算和内存访问方面效果更佳，从而显著提升了查询效率。以下是我们基于 BEIR 数据集，在 4CU 规格的机器上对 Zilliz Cloud 和 ElasticSearch 在 BM25 检索的 QPS 性能对比：

在实际测试中，在 Recall 保持高一致性的前提下，近似策略能够将 QPS 提升 3～4 倍，部分数据集可达 7 倍。

此外，Zilliz Cloud 还通过倒排索引压缩算法将索引体积压缩至原始数据的 1/3，大幅降低内存与存储占用，并支持索引持久化以加速加载与部署。

（3）JSON Path Index 加速动态字段过滤：灵活应对复杂元数据查询

随着应用场景的日益复杂化，用户对向量数据库的元数据管理和查询能力提出了更高的要求。特别是在需要处理半结构化数据或 schema 经常发生变化的场景下，传统的固定 schema 设计往往显得捉襟见肘。Milvus 在之前的版本引入了动态字段（dynamic field）支持，允许用户在不预先定义所有字段的情况下灵活地插入和查询数据。然而，如何高效地对这些动态字段中的内容进行过滤，成为了提升查询性能的关键。因此，新版本在此基础上更进一步，推出了 JSON Path Index功能，专门用于加速对动态字段内部特定路径下数据的过滤操作。

想象一下，您在向量数据中存储了用户的画像信息，其中包含了多层嵌套的 JSON 结构，例如用户的兴趣标签、购物历史、地理位置等。当您需要在向量搜索的同时，根据这些动态变化的元数据进行精确过滤时，例如“查找所有居住在北京且对‘人工智能’标签感兴趣的用户的相关向量”，传统的全量扫描 JSON 内容的方式效率低下，难以满足实时性要求。JSON Path Index 的出现将改变这一局面。它允许用户针对 JSON 字段内的特定路径（例如 $meta.user.location.city ）创建索引。

index_params.add_index(    field_name="metadata",    index_type="INVERTED",    index_name="json_index",    params={        "json_path": "metadata[\"user\"][\"location\"][\"city\"]",          "json_cast_type": "varchar"    }当执行包含这些路径条件的过滤查询时，Milvus 能够利用这些预先构建的索引，快速定位到符合条件的记录，而无需逐条解析和匹配完整的 JSON 对象。这极大地提升了在动态 schema 或复杂元数据场景下的过滤性能，使得用户可以更灵活、更高效地组织和查询数据。从实际线上用户场景的落地效果来说，含 Json field 的过滤搜索延迟在构建 JSON 索引后大幅降低，监控显示单个 segment 的平均延迟从 140 ms（P99 480ms）下降到 1.5ms（P99 10ms），查询效率大幅提升。

其他

除了上述介绍的关键优化之外，Milvus 2.6 还支持 Int8 数据类型的向量存储，以适配更高性价比且快速的模型推理服务。此外还有一系列与降本相关的技术架构升级，例如数据冷热分层架构和 Zero-Disk 的云原生日志系统等，这部分我们将放到第三部分架构优化篇进行介绍。

02 搜索与功能增强：拓展边界，赋能多元应用

在现代搜索应用中，向量相似性搜索与传统全文检索（如 BM25 算法）的结合，已成为提升搜索质量和用户体验的关键策略。自 Milvus 2.5 发布全文检索功能以来，受到了社区和用户的广泛关注和使用，在功能层面我们也收到了更多的需求。在 Milvus 2.6 版本我们开发了以下功能，旨在为用户提供更好用的检索与排序能力，从而进一步增强混合搜索的整体表现。

Analyzer/Tokenizer 功能增强：精细化文本处理，提升多语言搜索效能

在文本相关的搜索场景中，无论是关键词检索还是基于稀疏向量的全文检索（如 BM25），Analyzer（分析器）和 Tokenizer（分词器）的质量都直接影响着最终的搜索效果。它们负责将原始文本数据转化为可供搜索引擎理解和处理的词元（token）序列，这个过程涉及到语言识别、大小写转换、停用词去除、词干提取、同义词扩展等多个复杂环节。Milvus 2.6 对 Analyzer/Tokenizer 功能进行了显著增强，为用户提供了更强大、更灵活的文本处理能力，尤其在多语言支持和自定义配置方面取得了诸多进展。

其重点功能包括：

新增 Run Analyzer 语法支持，提供分词配置的可观测性
新增 Lindera 分词器，支持日语、韩语等亚洲语种
新增 ICU 分词器，适合多语言场景
新增多语言分词器配置，用户可精细定义语种及其对应的分词器配置
Jieba 分词器更新升级，支持自定义词表传入，支持用户通过配置项传入自定义词表（未来会支持文件传入和动态修改）
支持更多过滤器，提供细粒度的配置

通过这些增强，Milvus 2.6 致力于帮助用户更深入地理解和利用文本信息，无论面对何种语言、何种复杂度的文本数据，都能获得高质量的搜索结果。

Phrase Match 短语和词序匹配：精准捕捉用户全量输入

在多数搜索场景中，用户的查询往往不只是词语的简单拼接，短语的完整性与词语的顺序承载着丰富的语义。例如，查询“人工智能最新进展”与“最新人工智能进展”，虽然包含相同词汇，但用户的关注点可能略有差异；再如，“苹果手机”一词的含义也远非“苹果”和“手机”两词的简单组合。传统依赖分词和关键词匹配的方式，如 Text Match，往往难以准确还原这种语义上的微妙差别。为提升搜索的精度与理解能力，Milvus 2.6 正式引入 Phrase Match 功能，支持基于短语结构和词序的精确匹配

PHRASE_MATCH(field_name, phrase, slop)

Phrase Match 在文档匹配过程中，不仅判断关键词是否出现，更关注查询短语是否完整出现、词语是否按原顺序排列。这使得系统能够准确识别用户输入中的关键语义结构，特别适用于如下场景：

法律文档检索：如“合同违约责任”等术语，需保持完整性和词序；
用户评论分析：如“电池续航差”这类负面短语，有助于企业快速定位产品问题；
智能问答与RAG系统：对高精度匹配有更高要求。

Milvus 2.6 在索引构建和查询解析阶段引入短语与词序的处理逻辑，同时支持通过 slop 参数配置词序允许的“宽容度”，灵活应对轻微的词语顺序变动。

? 提示：由于不同 tokenizer 对 position 的定义方式不同，相同短语在不同分词器中可能产生不同的 slop 值。建议在使用 Phrase Match 前，通过 run_analyzer 先行验证分词效果。

Decay Function 时间衰减的重排序：赋予搜索结果时效性与动态性

在许多信息检索和推荐场景中，内容的时效性是一个至关重要的因素。用户往往更关注最新的资讯、最近发生的事件或近期活跃的项目。传统的相似性搜索可能仅仅依据内容本身的匹配度进行排序，而忽略了时间维度对信息价值的影响。为了解决这一问题，赋予搜索结果更强的时效性和动态性，Milvus 2.6 引入了 Decay Function 时间衰减的重排序功能。

Decay Function 允许用户在获取初步的搜索候选集之后，根据每个条目的时间戳信息，对其原始相关性得分进行调整。其核心思想是，随着时间的推移，信息的价值或相关性可能会逐渐衰减。通过应用一个预定义的衰减函数（例如指数衰减、线性衰减或高斯衰减），系统可以降低较旧条目的得分，同时保持或提升较新条目的得分。这样，在最终呈现给用户的搜索结果中，那些内容相关且时间上更新的条目将更有可能排在靠前的位置。

例如，在新闻推荐系统中，用户更希望看到最近发生的新闻报道；在电商平台的产品搜索中，新上架的商品或近期有促销活动的商品可能更具吸引力；在社交媒体内容流中，最新的帖子通常具有更高的优先级。Milvus 2.6 的 Decay Function 提供了灵活的配置选项，用户可以根据业务需求选择合适的衰减函数类型、设定时间衰减的速率（半衰期）、以及定义用于计算时间差的基准时间点。这一功能可以无缝集成到现有的搜索流程中，作为召回之后的重排环节。

通过引入时间衰减的重排序机制，Milvus 不仅能够帮助用户找到“相关”的内容，更能找到“在当前时间点最相关”的内容，极大地提升了搜索结果的质量和用户体验，使得信息流更具时效性。

Data-In, Data-Out 第三方模型集成：简化工作流，加速应用落地

在构建一个完整的 AI 应用时，向量数据库通常只是整个数据处理和分析流水线中的一个环节。数据在进入 Milvus 进行向量化和索引之前，可能需要经过复杂的预处理、特征提取（例如通过各种 Embedding 模型将文本、图像、音频等转换为向量）等多个步骤，而在从 Milvus 检索出向量结果之后，也可能需要进一步的处理，比如根据主键 id 反查原始文本。

在 Milvus 2.6 之前的版本，用户与 Milvus 交互的主要方式还是通过不易理解的向量数据，因此 Milvus 2.6 重点增强了与第三方模型的集成能力，通过 function 来集成模型的能力，致力于打造更流畅的 “Data-In, Data-Out” 体验。

Milvus 2.6 将多种 embedding models 引入的 Function 模块，支持在插入和查询时直接使用原始文本，系统会自动调用第三方模型服务（如 OpenAI、Bedrock、Vertex AI 等），将文本转化为向量并存储或用于搜索，无需用户手动生成 embedding。这些能力包括：

插入时自动向量化：插入文本字段时，Milvus 自动通过配置的模型服务生成向量并写入指定字段。
查询时自动向量化：使用文本字段查询，系统自动生成查询向量并进行向量检索，最终返回文本字段。
支持多种服务商：内置支持 OpenAI、AWS Bedrock、Google Vertex AI、Hugging Face 等主流模型提供方。
统一配置管理：API 凭据集中管理，确保安全调用，无需硬编码。

通过 Function 功能，Milvus 可以更加方便用户构建语义搜索系统的一站式平台，简化了从原始数据到语义检索的工作流程。

其他

除了以上介绍的功能特性之外，Milvus 2.6 还支持以下功能：

支持 Add Field 新增标量字段
支持 Minhash 方式高效识别近似重复数据

03 架构优化：稳固基石，支撑未来扩展

一个强大而灵活的系统架构是向量数据库能够持续演进、应对日益增长的数据规模和查询复杂度的基石。Milvus 2.6 在架构层面进行了多项关键优化与创新，旨在进一步提升系统的稳定性、可扩展性、可维护性和整体性能。这些架构上的改进，不仅为当前引入的各项新功能提供了坚实的支撑，更为 Milvus 未来的发展奠定了稳固的基础，确保其能够从容应对更大规模、更复杂场景的挑战。

Tiered Storage 数据冷热分层 (架构视角)：构建弹性高效的存储体系

面对日益增长的向量数据量，存储成本成为部署中的重要考量。Milvus 2.6 引入了冷热分层存储机制，将“热”数据与“冷”数据分级存放：经常访问的热点向量数据保存在高速存储介质上（例如本地 SSD），而长时间未访问的海量冷数据则自动下沉到低成本的对象存储中。整个过程对应用透明，Milvus 在查询时会按需将冷数据提取并加载，确保检索性能不会受到明显影响。通过分层存储策略，用户能够在性能和成本之间取得平衡——将绝大部分数据置于廉价存储以降低成本的同时，仍然保障活跃数据的高速读写和查询效率。

该功能通过在 Milvus 中引入动态按需加载与卸载机制，使查询节点（Query Node，QN）能够处理超出常规内存容量的数据，显著降低资源占用并提升系统灵活性。其核心原理是在集合加载时仅加载必要的元数据，执行检索时再根据查询需求动态下载所需的数据段和索引；对于长时间未访问的冷数据，系统可基于 LRU 算法主动卸载，以腾出内存资源。主要特性包括延迟加载（Lazy Load）、部分加载（Partial Load）和基于 LRU 的缓存逐出（LRU-based Cache Eviction），实现“先元后数、按需拉取、自动回收”的高效流程。该功能计划在 Milvus 2.6.0 中以 Beta 测试版提供，计划在 2.6.x 中升级为 GA 正式版。

就功能兼容性而言，存储版本 V1 仅支持延迟加载，存储版本 V2 全面支持三大特性；标量和向量索引目前仅支持延迟加载，但对增长段写入不产生影响。关闭分层存储可回退至传统整体加载模式；启用后集合加载速度显著提升、资源使用减半，但首轮冷缓存查询延迟略增，缓存命中后检索性能可恢复至常规水平。用户可通过在 milvus.yaml 中设置全局配置项来灵活开关该功能。此外，当前实现仍存在若干开放问题，包括分层存储与其他资源（如计算节点、网络带宽）的协调策略、不同资源类型的预留配置粒度、缓存命名空间管理与监控可视化等，社区将在后续版本中持续迭代优化。分层存储以其存算分离、按需分层调用的设计理念，为大规模向量检索场景提供了兼顾性能与资源效率的新路径，既满足高并发检索需求，又有效控制云原生环境中的成本与运维复杂度。

从更宏观的层面看，Tiered Storage 的实现，增强了 Milvus 部署的灵活性和经济性，使得用户可以根据自身的业务负载、数据增长速度和成本预算，更精细化地配置和管理存储资源，构建出真正符合其需求的、可持续发展的向量数据平台。

Streaming Service：拥抱实时数据流，赋能即时向量处理

在当今这个数据爆炸且高度动态的时代，实时性已成为许多 AI 应用的核心竞争力。无论是金融欺诈检测、实时个性化推荐，还是物联网设备状态监控，系统都需要能够即时处理和分析持续涌入的数据流，并迅速做出响应。传统的批处理模式在这些场景下往往显得力不从心。为了更好地满足用户对实时向量数据处理的需求，Milvus 2.6 在架构层面引入了全新的 Streaming Service，旨在增强 Milvus 对流式数据接入、实时索引构建和即时查询的能力。

Streaming Service 的设计目标是为 Milvus 提供一个高效、可扩展的流式处理引擎，使其能够无缝对接现有各种主流的消息队列（如 Kafka, Pulsar ）、Woodpecker(Zilliz 自研的为云原生环境设计的轻量级 WAL 实现) 或直接消费来自数据源的实时数据流。在架构上，Streaming Service 引入一个新的角色 Streaming Node。Streaming Node 与 Milvus 的其他组件（如 Query Node, Data Node）紧密协作。它负责从数据源拉取数据、进行必要的预处理和转换（例如，结合 Data-In, Data-Out 机制调用外部模型进行实时向量化），然后将处理后的数据高效地分发给负责存储和索引的组件。通过引入专门的 Streaming Node，Milvus 能够更有效地隔离流处理负载与批处理负载，避免了因大规模实时数据注入而对现有查询性能造成冲击。同时，Streaming Node 本身也具备良好的横向扩展能力，可以根据数据流入的速率和处理需求，动态调整节点数量，确保系统在高吞吐量下的稳定性和低延迟。这一架构上的创新，使得 Milvus 不再仅仅是一个擅长处理静态大规模向量数据的数据库，更演进为一个能够从容应对高并发实时数据流、支持即时分析和决策的强大平台，为构建实时 AI 应用提供了坚实的架构支撑。

新架构 Streaming Service 相比于旧架构具有如下优势：

写入可见更加实时，去除了 WAL 复制的延迟，更好的支持主键去重，partial 更新，动态 Shard 拆分等操作；
配合 Woodpecker，写入吞吐大幅超过 kafka/pulsar；
故障恢复速度更快，通过擦除读放大以及优化时钟消息机制，可以更快地从故障中恢复；
横向拓展能力增强，将流处理和批处理模块进行解耦，各个角色的功能定义更加清晰和对等。

其他

此外架构方面的优化还包括：

支持 100k Collection：从容应对海量租户与复杂业务隔离需求（可参考Milvus多租户实践：你的技术选型扛得住一夜爆火吗？）
Woodpecker 云原生日志系统：Zero-disk 的 WAL 存储系统（可参考Milvus Week | Kafka 很好， Pulsar也不错，但WoodPecker才是未来）
File format v2（Storage v2）：优化存储结构和效率，减少 IOPS 和内存使用
Coord Merge：优化集群协调，提升大规模部署稳定性与效率

04 总结与展望

Milvus 2.6 的发布，是我们在构建世界领先的向量数据库征程中的又一个坚实足迹。通过在降本提效、搜索与功能增强以及架构优化三大核心方向的深度耕耘和优化，相信 Milvus 2.6 会为用户带来更多业务价值。从 RabitQ 1 bit 量化、Tiered Storage 到 BM25 性能优化、JSON Path Index，我们致力于帮助用户以更经济高效的方式管理和利用海量向量数据；从 Analyzer/Tokenizer 功能增强、Phrase Match 到 Decay Function、Data-In, Data-Out 第三方模型集成，我们不断拓展搜索的边界，赋能更多元的 AI 应用场景；从 Streaming Node、Storage v2 到 Coord Merge 乃至支持 100k Collection，我们持续夯实系统架构，为未来的大规模扩展和更高性能挑战奠定稳固基础。

Milvus 和 Zilliz Cloud 一直在解决一个具体问题：让 AI 时代的数据检索变得更快、更稳定，也更易于集成。

这不是一蹴而就的事，需要持续的技术演进，也需要真实用户场景的反复打磨。过去一段时间，我们收到了大量来自社区的反馈，很多都非常细节，也非常有启发。这些反馈让我们意识到产品还有很多可以改进的空间。

Milvus 2.6 是一个新起点，我们希望它能回应一部分用户的真实需求。但与此同时，未来还有很多工作要做，也欢迎你继续提出问题。每一个问题，都是我们产品设计的一部分。