Milvus 3.0-beta深度解析：十大核心特性与架构重构全解读

2026年5月9日，Milvus 3.0-beta正式发布，这不是一次简单的版本迭代，而是对整个系统架构的根本性重构。从数据搬运之苦到向量缺失之痛，从排序聚合的代码冗余到多租户管理的复杂度，3.0版本几乎逐一击破了老用户长期积累的痛点。本文将深入解析这次重大升级的十大核心特性及其背后的技术逻辑。

External Collection：告别数据搬运时代

在Milvus 2.x时代，如果你的数据存储在S3或HDFS上（Parquet或Iceberg格式），想要进行向量检索，必须先将数据完整复制一份到Milvus中。这意味着你需要维护两份存储、编写ETL同步脚本，还要忍受数据湖已更新但Milvus中仍是旧数据的不一致问题。

3.0引入的External Collection彻底改变了这一局面。你只需告诉Milvus数据所在的文件夹路径，它就会直接在原始位置建立索引并执行查询，完全不触碰原始数据。用一个形象的比喻：这就像请了一位图书管理员直接去你的书库找书，而不是把所有书搬到他的办公室。

这个特性对金融、医疗等对数据安全和合规性要求极高的行业尤为重要——这些行业的监管规定往往不允许数据离开公司的数据湖环境。同时，对于希望降低存储成本、减少运维负担的团队来说，External Collection也是一个极具吸引力的功能。

Snapshot快照：离线与在线的完美隔离

在生产环境中，一边服务线上检索请求、一边跑离线任务（如AB测试、数据分析）是常态。但这两者之间的冲突一直是个老大难问题：离线任务可能读到未写完的脏数据，或者锁住正在写入的数据导致线上服务卡顿。

3.0的Snapshot功能采用了一种极其轻量的方案——它只记录元数据，不真正复制数据，因此创建快照的操作几乎瞬间完成且几乎不占额外存储空间。离线任务读取快照，线上业务继续写入原始Collection，两者完全互不干扰。

更巧妙的是，Spark可以直接通过Snapshot读取Milvus中的数据，数据工程师再也不需要手动导出数据再分析，整个数据分析流程变得无缝衔接。

Order By与聚合查询：数据库级别的业务逻辑

按业务规则排序

以前向量搜索只能按相似度排序，但实际业务中往往需要在相似结果中再按价格、发布时间等维度二次排序。过去的做法是把所有结果拉到客户端再手写排序代码，效率低且代码复杂。

Milvus 3.0的Order By支持在搜索语句中直接指定多级排序规则——先按向量相似度、再按价格升序、再按发布时间降序——数据库内核一次性处理完毕，直接返回排好序的结果。

聚合查询下沉到数据库层

类似地，以前想要按租户分组统计数量或求某字段平均值，只能把所有记录查出来在应用层计算，网络传输量巨大且代码冗余。现在Milvus 3.0支持直接在查询中编写聚合逻辑——按租户分组、统计记录数、求分数平均值、求时间最大值——数据库内部完成计算，只返回最终结果，代码简洁度堪比SQL。

No Vector与在线加列：灵活的Schema演进

向量字段可以暂时为空

在异步生成Embedding的场景中，以前要么等向量生成完才能写入（增加延迟），要么先写入全零向量占位（污染检索结果）。Milvus 3.0支持向量字段为空——先存入无向量的记录，搜索时自动跳过这些记录，等向量算好后再更新补入。

动态添加向量列

在线加列允许你直接给现有Collection新增向量字段，无需重建整个表。当业务模型发生变化时，可以立即灵活扩展，极大降低了Schema变更的成本。

实体级TTL：精细化的数据生命周期管理

以前只能在Collection或Partition级别统一设置过期策略。如果一个表中有上千个租户，A租户数据保留30天、B租户保留90天，你只能写复杂的定时扫表脚本手动清理。

Milvus 3.0的实体级TTL允许在表结构中指定一个时间戳字段作为TTL字段，每条数据写入时自带过期时间，后台自动清理到期数据。这对实现GDPR的"被遗忘权"、清理会话数据、管理对话历史等场景特别实用。

Ambulist：一条记录存多个向量

处理长文档时，将其切成多个chunk并生成多个向量是常见做法。以前要么拆成多条记录（丢失chunk间关联），要么手动打包成复杂结构（容易内存溢出）。

Milvus 3.0的Ambulist允许一条记录直接存储一个向量列表，配合DiskANN磁盘索引，即使数据量巨大也不会出现内存不足的问题。这也是Milvus多向量支持的第一步。

File Resource与Storage V3：底层基础设施升级

统一的文本搜索配置管理

在医疗、法律、中文等场景中，自定义词典和同义词对分词效果至关重要。Milvus 3.0的File Resource允许将自定义词典、同义词表、停用词文件统一上传到Milvus的文件资源管理器中，注册后可被分词器、过滤器、BM25算法、全文匹配等功能共享使用，多个Collection共用一套配置，告别到处复制粘贴配置文件的时代。

全新存储引擎Storage V3

Storage V3是Milvus 3.0引入的基于Segment的列存储引擎，所有数据和元数据直接存放在对象存储（如S3）上。每次修改生成新的不可变清单快照，删除操作仅在delta log中记录标记而不重写文件，保证了文件结构的稳定性。

最关键的是，数据文件是自描述的——任何读取器（如Spark）只要拿到存储路径就能直接解析文件内容，无需依赖Milvus的中央元数据服务。配合定期Compaction（小文件合并），避免了文件碎片问题。可以说，Storage V3为湖仓一体架构奠定了坚实的底层基础，External Collection和Snapshot正是建立在这一基础之上。

正式版展望：更多值得期待的功能

作为Beta版，Milvus 3.0仍有一些重要功能尚未就绪，正式版中值得期待的升级包括：

• 多向量增强：Struct List过滤、Multi-vector和Late Interaction等多向量加速能力
• 数据管理：全局PK去重、字段删除、备份填充，以及Text和Blob新类型支持直接存储和搜索文本、图片、视频等原始文件
• 搜索体验：More Like This（通过示例文档直接查找相似内容）、语义增强、结果高亮等
• 企业级功能：基于快照的备份恢复、端到端审计日志、更细致的多租户管理和高可用集群
• 向量湖升级：升级到0.2版本，与Spark深度集成，支持离线索引、聚类和去重

总结

Milvus 3.0-beta的发布标志着它从一个纯粹的向量搜索引擎，正式迈向AI数据基础设施的定位。通过External Collection消除数据搬运、通过Snapshot实现读写隔离、通过Order By和聚合查询将业务逻辑下沉到数据库层、通过Storage V3打通湖仓一体——这些改进不是零散的功能堆砌，而是围绕一个清晰的架构愿景展开的系统性重构。对于正在构建AI应用的团队来说，这次升级值得认真关注和评估。