数据不搬家也能做检索Milvus的“湖原生”架构革命——深度剖析Milvus的云原生架构、索引引擎与从2.x到3.0的存储范式跃迁一句话概括Milvus不是又一个向量数据库而是一套以“存储与计算分离”为骨架、以“湖原生检索”为最新范式跃迁、以“分层微服务”为运行时的开源向量数据库操作系统——让百亿级向量检索从“先搬家再查询”的传统模式变成“数据留在原地、索引就地构建”的零拷贝检索体系。2019年当Milvus在GitHub上第一次开源时它解决的是一个很朴素的问题如何在百万级向量上做快速的相似性搜索彼时Faiss和HNSW已经在学术界证明了ANN近似最近邻搜索的可行性但把它们包装成一个可扩展、可运维的数据库系统仍然是空白。六年后的2026年7月29日Milvus 3.0正式发布。这一次它要解决的问题变成了当你的向量数据已经躺在数据湖里Parquet、Lance、Iceberg能不能不搬家就直接建索引、做检索看起来很简单对吧把向量往数据库里一插就能搜了。但是——当你的Embedding已经存在S3上的Parquet文件里当你的数据治理要求“数据不能出湖”当你的团队不想维护第二份在线数据副本传统向量数据库的“先导入再检索”范式还够用吗Milvus 3.0给出的答案是External Collections外部集合——直接在对象存储上的数据文件上构建索引零拷贝、零迁移让数据湖真正变得可检索。本文将从架构演进、索引引擎、存储范式和工程实践四个维度深度剖析Milvus的技术实现——它不是一次性的版本升级而是一场从“向量数据库”到“向量数据湖基座Vector Lakebase”的范式革命。一、整体架构与设计哲学从“微服务”到“湖原生”1.1 架构总览四层分离各司其职Milvus的架构设计遵循“存储与计算分离、控制平面与数据平面分离、云原生弹性扩展”三大核心原则。整体架构自上而下分为四层┌─────────────────────────────────────────────────────────────┐ │ 接入层Access Layer │ │ Proxy节点无状态网关、负载均衡 │ ├─────────────────────────────────────────────────────────────┤ │ 协调层Coordinator Layer │ │ RootCoord / DataCoord / QueryCoord / IndexCoord │ │ 集群大脑拓扑管理、任务调度、一致性 │ ├─────────────────────────────────────────────────────────────┤ │ 执行层Execution Layer │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │Streaming │ │ Query │ │ Data │ │ Index │ │ │ │ Node │ │ Node │ │ Node │ │ Node │ │ │ │实时流 │ │历史查询│ │写入持久化│ │索引构建│ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ ├─────────────────────────────────────────────────────────────┤ │ 存储层Storage Layer │ │ 元数据etcd 日志Pulsar/Kafka 对象存储S3/MinIO│ └─────────────────────────────────────────────────────────────┘接入层由一组无状态的Proxy节点组成提供统一的API接口Python/Java/Go/Node.js SDK及RESTful API负责请求验证、负载均衡和结果聚合。协调层是集群的“大脑”包含RootCoord元数据管理、DataCoord数据调度、QueryCoord查询调度和IndexCoord索引调度四个协调器。集群中同一时刻仅有一个活跃的Coordinator节点通过Raft协议实现主从切换。执行层是计算核心包含三类工作节点Data Node负责数据插入、删除和持久化将数据从内存缓冲区刷入对象存储Query Node负责执行搜索和查询操作从对象存储加载Segment到内存Index Node负责为Sealed Segment构建索引存储层由三部分组成etcd存储元数据、Pulsar/Kafka作为消息队列WAL、S3/MinIO作为主要数据存储。1.2 设计哲学的两次跃迁第一次跃迁2.x时代存储与计算分离Milvus 2.0重构为云原生架构所有组件均为无状态组件。这种设计的核心收益在于存储和计算可以独立扩展——数据量大了就扩存储节点查询量大了就扩Query Node。第二次跃迁3.0时代湖原生Lake-NativeMilvus 3.0最大的架构变革是打破了“数据必须先导入向量数据库才能建立索引和提供检索”的传统范式。向量数据可以继续存放在对象存储上的开放格式Parquet、Lance、Iceberg、Vortex中由Milvus负责就地构建索引、执行检索。1.3 版本演进从2019到2026版本发布时间关键变化Milvus 1.02020年首个开源版本支持CPU/GPU向量检索Milvus 2.02021年云原生重构存储与计算分离所有组件无状态化Milvus 2.32023年HNSW索引优化C实现工程级优化Milvus 2.42024年高可用架构完善Milvus 2.52025年内置BM25全文搜索稀疏向量支持Milvus 2.62026年初AISAQ磁盘索引、RaBitQ、三层存储降本85%Milvus 3.02026年7月29日湖原生架构、External Collections、Loon存储引擎数据来源Milvus官方发布说明及GitHub Releases二、核心抽象与数据模型Collection、Segment与Chunk2.1 数据模型的三层抽象Milvus的数据模型采用三层抽象层级概念说明Collection集合类似于关系型数据库中的“表”是数据的逻辑组织单元Partition分区Collection内的数据分区支持按时间等维度划分Segment段数据存储的最小物理单元分为Growing Segment和Sealed Segment2.2 Segment的生命周期从“Growing”到“Sealed”一个Milvus数据单元的完整旅程用户插入数据 → Proxy → 消息队列Pulsar/Kafka ↓ Data Node消费消息 → 写入Growing Segment内存缓冲区 ↓ Segment达到阈值默认122MB→ Sealed封存 ↓ Data Node将Chunk刷入对象存储S3/MinIO ↓ Index Node加载Segment → 构建索引 → 索引文件存回对象存储 ↓ Query Node加载索引 → 提供查询服务逐层解读① Proxy与消息队列用户通过SDK发送插入请求到Proxy节点。Proxy对主键做哈希决定发送到哪个ChannelPulsar或Kafka Topic。② Growing SegmentData Node从Channel消费数据写入内存缓冲区——这就是Growing Segment。每个Shard只有一个Growing Segment。③ Chunk与持久化Segment增长过程中每达到16MB就形成一个Chunk推送到对象存储。每个Chunk是对象存储上的一个物理文件每个字段有独立的文件。④ Sealing与合并当Segment达到122MB时被Sealed。Data Node定期将小的Sealed Segment合并成更大的Segment最大可达1GB。⑤ 索引构建Index Node从对象存储加载Sealed Segment的数据构建索引如IVF、HNSW然后将索引文件存回对象存储。⑥ 查询服务Query Node按QueryCoord调度从对象存储加载Segment数据向量、标量、索引文件到内存或本地SSD缓存。设计权衡Segment大小该设计的收益在于① 通过分片Shard和分段Segment充分压榨集群的并行计算能力② Growing Segment保证“写入后立即可查”③ Sealed Segment的不可变性简化了索引管理和并发控制。该设计的代价在于① 小Segment过多会影响查询性能召回率下降② 需要后台Compaction任务持续合并小Segment。2.3 流批分离Streaming Node的诞生在经典架构中Query Node既处理Sealed数据历史、高吞吐又处理Growing数据实时、低延迟——一个节点干了两种性质完全不同的活。最新架构中新增了Streaming Node专职处理尚未Flush的Growing Segment数据提供刚写入数据的实时搜索能力为搜索请求生成查询计划当Growing Segment达到阈值时触发转换为Sealed Segment同时Index Node合并进Data Node——索引构建和Compaction都是离线批处理任务放在同一节点可避免不必要的数据传输。三、核心模块源码解析索引引擎与查询执行3.1 索引体系从内存到磁盘的全覆盖Milvus支持多种索引类型覆盖不同的性能/内存/精度权衡索引类型原理适用场景FLAT暴力扫描数据量小10万追求100%召回率IVF_FLAT倒排索引聚类平衡性能与精度通用场景IVF_SQ8IVF 标量量化内存受限场景IVF_PQIVF 乘积量化极致压缩超大数据集HNSW分层可导航小世界图高QPS内存充足DISKANN基于磁盘的ANN百亿级数据内存极度受限GPU_CAGRAGPU加速图索引GPU集群追求极致吞吐AISAQ基于SSD的磁盘索引十亿级数据内存压缩3200倍RaBitQ1-bit量化内存压缩至1/32QPS提升4倍HNSW的工程实现Milvus 2.3版本对HNSW索引进行了C层面的工程级优化。在鲲鹏服务器上经过预取优化后HNSW算法在0.99精度下不同并发的查询效率均有40%的提升。DISKANN与AISAQDISKANN通过将索引放到SSD上减少内存压力。Milvus 2.6进一步引入AISAQ由铠侠KIOXIA开发一种受DISKANN启发的基于磁盘的向量索引。AISAQ能将十亿级搜索的内存占用压缩3200倍。RaBitQ从Milvus 2.6开始支持采用1-bit量化将主索引压缩至原内存的1/32叠加SQ8精排后整体内存占比仅28%QPS提升4倍召回率保持95%左右。设计权衡索引选择该设计的收益在于丰富的索引类型让用户可以根据数据规模、硬件配置和性能要求灵活选择。该设计的代价在于索引选型复杂——不同索引的参数nlist、M、efConstruction等需要针对具体场景调优。3.2 查询执行流程从Proxy到Segcore一次搜索请求在Milvus中的完整执行路径客户端Python/Java/Go SDK→ gRPC/REST请求 ↓ 【Proxy】请求验证 → 生成查询计划 → 分发到各Query Node ↓ 【Query Node】ShardDelegator协调 → 并行执行 ├── Growing SegmentStreaming Node处理 └── Sealed SegmentQuery Node从缓存/对象存储加载 ↓ 【SegcoreC核心引擎】执行查询计划 ├── 标量过滤Visitor模式遍历表达式树 ├── 向量检索ANN索引搜索 └── 结果合并与TopK排序 ↓ 【Proxy】聚合各节点结果 → 返回客户端Segcore的执行机制Milvus使用Visitor模式在Segment上执行查询计划。底层通过milvus::exec::Task管理查询的生命周期。查询执行涉及创建QueryContext来持有Segment元数据和查询参数。标量过滤的优化Milvus采用列式向量化的方式执行标量过滤表达式——一次处理一批数据而非逐行处理。3.3 索引引擎拆解三层填充与16倍内存取舍Milvus的索引引擎在设计上做了精妙的内存取舍三层填充策略索引构建过程中通过三层填充优化内存使用和构建速度编译期分流将不同索引类型的逻辑在编译期分离避免运行时分支开销16倍内存取舍在索引构建速度和内存占用之间做了明确的权衡——用更多内存换取更快的构建速度或将内存压到极致但接受更长的构建时间四、核心执行流程与运行时机制4.1 写入链路从内存到对象存储的完整旅程Insert请求 → Proxy主键哈希→ Pulsar/KafkaWAL ↓ Data Node消费 → Growing Segment内存缓冲 ↓每16MB Chunk → 对象存储S3/MinIO ↓达到122MB Seal Segment → 元数据更新etcd ↓ Index Node → 加载Segment → 构建索引 → 索引文件存入对象存储 ↓ Query Node → 加载索引 → 提供服务你可能会担心Data Node还没刷盘时节点宕机了怎么办别担心WALWrite-Ahead Log机制保证了数据安全。所有插入请求先写入Pulsar/KafkaData Node从日志中消费并写入Growing Segment。即使Data Node宕机数据仍在消息队列中重启后可继续消费。4.2 查询链路Growing与Sealed的协同查询请求到达后ShardDelegator负责协调Growing数据由Streaming Node处理保证“写入后立即可查”Sealed数据由Query Node从缓存或对象存储加载两种数据源的结果在Query Node层合并统一返回给客户端。4.3 一致性模型时间戳与MVCCMilvus通过TSOTimestamp Oracle分配全局唯一时间戳保证事务一致性。查询时系统基于时间戳读取特定版本的数据——类似数据库的MVCC机制。时间旅行Time Travel用户可以通过指定时间戳查询历史某个时刻的数据状态。五、存储引擎的范式革命从2.x到3.05.1 2.x时代散落的Binlog在Milvus 2.x中存储模型是逐binlog文件的方式——每个Segment的每个字段对应多个binlog文件散落在对象存储中。这种模型的问题在于元数据膨胀每个binlog都需要在etcd中记录元数据读取放大查询一个Segment需要打开大量小文件Schema演进困难增加或删除字段需要重建整个Collection5.2 3.0时代Manifest表 Loon存储引擎Milvus 3.0的存储层经历了一次范式级别的重写——从逐binlog文件模型转向了类似Apache Iceberg的manifest表格式。新的存储引擎名为Loon核心设计围绕三个要素展开混合文件格式将向量数据、标量数据和索引组织在统一的文件格式中行ID对齐保证向量和标量在物理存储上的对齐加速混合查询Manifest定义数据集的版本化状态支持Schema演进和时间旅行Loon的收益降低读取放大随机点查不再需要打开大量小文件支持Schema演进在线添加、回填和删除列成为可能零拷贝外部数据访问External Collection直接读取湖上数据5.3 External Collections数据不搬家也能建索引External Collection是Milvus 3.0最核心的新功能# 直接在S3上的Parquet文件上定义Collectionclient.create_collection(collection_nameexternal_vectors,# 外部数据源S3上的Parquet文件external_source{format:parquet,location:s3://my-bucket/embeddings/},schemaschema)# 然后就像普通Collection一样使用client.search(collection_nameexternal_vectors,...)核心机制零拷贝数据文件不移动Milvus直接读取对象存储上的文件就地索引在外部数据上直接构建向量索引、BM25倒排索引、JSON索引和标量索引增量更新当外部数据集更新后Milvus读取对应的Storage Manifest仅对新数据分片构建索引只读External Collections是只读的适合治理要求“数据不能出湖”的场景六、工程化实践从部署到生产6.1 部署模式与资源规划Milvus支持两种部署模式模式适用场景组件Standalone开发测试、小规模生产单进程包含所有功能Distributed大规模生产、高并发各组件独立部署可横向扩展核心依赖元数据存储etcd消息队列Pulsar或Kafka作为WAL对象存储MinIO、AWS S3、GCS、Azure Blob等WoodpeckerMilvus 3.0引入的原生WAL服务借鉴BookKeeper的分布式日志模型同时结合对象存储和云网络特性进行了重新设计。在跨可用区部署、对象存储利用和成本控制方面进一步优化性能比传统Kafka方案快5.8倍。6.2 性能优化策略① 索引选型优化数据规模推荐索引参数建议 100万HNSWM16, efConstruction200100万–1000万IVF_FLATnlist4096, nprobe161000万–1亿IVF_SQ8 / IVF_PQnlist16384, 根据精度需求 1亿DISKANN / AISAQ / RaBitQ根据硬件配置② 分段大小调优默认Segment大小为122MB合并后最大1GB。小Segment数量过多会影响查询性能——Compaction后台任务会持续合并小Segment、清理删除数据。③ 缓存策略Query Node从对象存储加载Segment到内存或本地SSD缓存。合理配置缓存大小可以显著降低查询延迟。④ 资源隔离通过PartitionKey隔离可在同一Collection中实现不同业务的数据隔离提升性能。6.3 调试与可观测性Milvus提供了多层次的观测能力Attu官方GUI管理工具可视化查看Collection、Segment状态Metrics通过Prometheus暴露各项性能指标日志各组件独立日志支持日志级别动态调整6.4 常见工程陷阱与解决方案陷阱1小Segment爆炸大量小Segment会导致查询时打开过多文件召回率下降。解决方案调整Data Node的合并策略定期执行Compaction。生产环境建议监控Segment数量设置合理的合并阈值。陷阱2索引构建资源竞争Index Node构建索引时会消耗大量CPU和内存可能影响查询性能。解决方案在Distributed部署中将Index Node独立部署与Query Node隔离资源。陷阱3消息队列积压Pulsar/Kafka消费速度跟不上写入速度时会导致Growing Segment积压。解决方案监控消息队列的Lag适当增加Data Node数量或调整Segment刷盘阈值。七、总结与展望7.1 关键版本里程碑时间版本意义2019年Milvus开源首个开源向量数据库项目2021年Milvus 2.0云原生重构存储与计算分离2025年Milvus 2.5内置BM25全文搜索混合检索成为标配2026年初Milvus 2.6AISAQ磁盘索引、RaBitQ、三层存储降本85%2026年7月29日Milvus 3.0湖原生架构、External Collections、Loon存储引擎7.2 核心设计哲学提炼Milvus的演进可以用三句话概括“存储与计算分离是地基不是选项”——从2.0开始Milvus就将无状态化作为架构的基石让存储和计算可以独立扩展“索引不是终点检索才是”——从FLAT到HNSW到DISKANN到AISAQ到RaBitQ每一次索引创新都在追问同一个问题“如何在更少的硬件上做更快的检索”“数据在哪检索就该在哪”——Milvus 3.0的湖原生架构把“数据不搬家也能建索引”从理想变成了现实7.3 核心架构亮点速览亮点说明效果四层分离架构接入/协调/执行/存储四层独立各层可独立扩展高可用流批分离Streaming Node专职处理实时数据写入后立即可查延迟稳定索引全覆盖从内存到磁盘、从CPU到GPU覆盖从百万到百亿级所有场景RaBitQ量化1-bit量化压缩至1/32QPS提升4倍召回率95%Loon存储引擎Manifest表格式混合文件Schema演进、零拷贝外部访问External Collection数据湖就地建索引无需第二份副本零拷贝检索7.4 对开发者的启示Milvus的故事告诉我们向量数据库的竞争正在从“谁更快”变成“谁更省”和“谁更灵活”。2019年大家关心的是“百万级向量能不能搜”。2023年大家关心的是“十亿级向量能不能搜”。2026年问题变成了“数据已经在湖里了能不能不搬家就搜”这种“优化跑步机”不会停止。随着AI应用从“演示级”走向“生产级”数据规模从百万走向百亿向量数据库的架构必须持续演进。对于开发者这意味着选型时关注架构演进方向——云原生是底线湖原生是趋势部署时关注存储成本——对象存储比本地盘便宜一个数量级能走S3就走S3索引选型要结合数据规模——百万级和亿级的索引策略完全不同关注3.0的External Collections——如果你的数据已经在数据湖里这可能是最优解最后Milvus从2019年的一个向量检索工具到2026年的湖原生向量数据湖基座——六年时间它不仅回答了“怎么搜得快”更在回答“怎么搜得省、搜得灵活”。而答案正写在每一行开源代码和每一次架构重构里。本文数据来源Milvus官方文档milvus.io、GitHub Releasesgithub.com/milvus-io/milvus、Milvus官方博客blog.milvus.io、DeepWiki及社区技术文章。所有版本号、功能特性及性能数据均基于公开可验证的官方资料。如您所在的企业正面临向量检索、RAG系统构建或AI数据基础设施的相关需求欢迎进一步沟通。我们可提供针对贵企业具体场景的定制化方案和现场调研服务。