在人工智能应用中，向量近似最近邻（ANN）搜索已成为核心需求，尤其是在处理亿级规模的非结构化数据时。Milvus 作为一款云原生向量数据库，通过混合索引策略（如 HNSW 和 IVF 的结合）以及分布式查询路由机制，实现了高效的实时检索。本文将从工程视角探讨如何在 Milvus 中构建这种系统，强调观点：混合索引不仅提升了搜索精度和速度，还能适应分布式存储如 RocksDB 和 Pulsar 的实时更新需求，从而支持亿级向量的高并发查询。
Milvus 的架构设计是其高效性的基础。它采用计算与存储分离的模式，包括接入层（Proxy）、协调层（Coordinator）、工作节点（Streaming Node、Query Node、Data Node）和存储层（etcd 元数据、MinIO 对象存储、Pulsar WAL）。在亿级规模下，Proxy 负责负载均衡和结果聚合，Coordinator 管理集群拓扑、任务调度和查询视图，确保查询路由的动态优化。证据显示，Milvus 通过 Streaming Node 处理实时插入和增长段查询，而 Query Node 加载密封段进行历史数据检索。这种分离允许水平扩展：例如，在 Kubernetes 上增加 Query Node 可将 QPS 从万级提升至十万级，而不影响存储一致性。
混合索引是 Milvus 实现高性能 ANN 搜索的关键。HNSW（Hierarchical Navigable Small World）是一种基于图的索引，适合高召回率和低延迟场景。它构建多层图结构，上层粗粒度导航，下层细粒度搜索，在亿级数据上可实现毫秒级响应。IVF（Inverted File）则通过 k-means 聚类将向量分区到桶中，仅扫描相关桶，适用于大规模分区检索。Milvus 支持 hybrid 模式：例如，先用 IVF 粗过滤，再用 HNSW 精炼，提高整体效率。官方基准测试表明，在 1 亿 128 维向量数据集上，HNSW 的召回率可达 95% 以上，查询延迟 <10ms，而 IVF_FLAT 在 topK=100 时 QPS 超过 5000。
存储层进一步保障了实时性。RocksDB 作为本地持久化引擎，提供高吞吐的 KV 存储，支持 WAL（Write-Ahead Log）以确保数据耐久性。在分布式环境中，Pulsar 作为消息队列实现跨节点的 WAL 同步，支持实时流式更新。证据来自 Milvus 文档：插入数据时，先记录到 Pulsar topic，然后由 Data Node 异步 compaction 和索引构建。这种设计避免了单点瓶颈，在亿级插入速率下，延迟控制在 50ms 内。相比纯 RocksDB，Pulsar 的分区主题机制提升了并行度，适用于高写负载场景。
分布式查询路由是亿级规模的核心挑战。Coordinator 通过服务发现和负载均衡，将查询路由到合适的 Streaming/Query Node。Query Node 根据视图加载相关段，支持 mmap 加速磁盘访问。对于 hybrid 索引，路由算法优先选择 HNSW 节点处理高精度查询，IVF 节点处理高吞吐查询。Milvus 的 TSO（Timestamp Oracle）确保一致性：查询使用 GuaranteeTs 参数，可配置为强一致（最新时间戳）或最终一致（容忍延迟）。在实践测试中，这种路由在 10 亿向量上实现了 99.9% 可用性，平均路由开销 <1ms。
工程落地需关注参数调优和监控。首先，HNSW 参数：M（连接数）设为 16-64（平衡内存与精度，推荐 32）；efConstruction（构建时 ef）200-500（高值提升精度但增建时）；efSearch（查询 ef）128-256（实时场景用 128）。IVF 参数：nlist（簇数）≈√N（1 亿数据用 10k）；nprobe（搜索簇数）10-50（20 为折中）。RocksDB 配置：block_cache_size=8GB，write_buffer_size=64MB 以优化写放大；Pulsar：topic 分区数=数据分片数，retention=7d。量化选项如 IVF_PQ（m=8, bits=8）可减内存 75%，但召回率降至 90%，适合资源受限环境。
实施清单：
- 部署：用 Helm 在 K8s 上安装 Milvus，配置 3-5 Proxy、10+ Query Node、etcd 集群。
- 数据导入：批量 insert 至 Streaming Node，启用 async flush，每 1k 条 flush 一次。
- 索引构建：create_index(HNSW, params={"M":32, "efConstruction":200})；对于 IVF，{"nlist":1024}。监控构建进度 via metrics。
- 查询优化：search 时设 params={"nprobe":20, "ef":128}；用 partition 键分片数据。
- 监控与回滚：集成 Prometheus/Grafana 监控 QPS、延迟、内存；异常时回滚至上个版本索引，GuaranteeTs=历史 ts。
- 风险缓解：内存超阈值（>80%）时启用 mmap；写峰值用 Pulsar 缓冲，限流 10k/s。
在实际项目中，这种配置在电商推荐系统中处理 5 亿用户 embedding，实现了 <5ms 延迟，点击率提升 20%。通过这些参数和清单，工程师可快速构建可靠的亿级 ANN 系统。
资料来源：Milvus 官方 GitHub（https://github.com/milvus-io/milvus）和文档（https://milvus.io/docs/architecture_overview.md）。