七、混合检索Hybrid Search原理同时执行多种检索方式向量语义检索 BM25 全文检索各取 TopK然后融合排序最终返回 TopN。代码示例frompymilvusimportWeightedRanker,RRFRanker resultsclient.hybrid_search(collection_namearticles,reqs[{data:[query_vector],anns_field:vector,limit:10},# 向量检索{data:[query_text],anns_field:sparse,limit:10},# BM25全文检索],rerankWeightedRanker(0.7,0.3),# 加权融合向量70%BM25 30%limit5,# 最终返回5条)为什么需要混合检索纯向量检索抓语义相近但可能漏掉关键词精确匹配 纯BM25检索抓关键词命中但理解不了语义 混合检索两者结合既不漏语义也不漏关键词融合策略策略原理特点WeightedRanker按分数加权需要调权重调优后效果更好RRFRanker按排名倒数融合不需要调参通用场景首选前提条件建表时需定义稠密向量和稀疏向量两个字段client.create_collection(collection_namearticles,fields[{name:id,type:INT64,is_primary:True},{name:vector,type:FLOAT_VECTOR,dim:384},# 稠密向量{name:sparse,type:SPARSE_FLOAT_VECTOR},# 稀疏向量(BM25){name:text,type:VARCHAR,max_length:1000},])八、面试常见问题基础概念问题简答Milvus 是什么向量数据库存储高维向量做 ANN 相似度检索为什么不用 MySQL 存向量MySQL 没有 ANN 索引百万级数据全表计算就卡死支持哪些相似度计算L2欧氏距离、IP内积、COSINE余弦相似度检索结果是精确的吗不是ANN 是近似算法召回率通常 95%索引与性能问题简答有哪些索引类型FLAT、IVF、HNSW、DISKANNHNSW 为什么快多层跳表O(logN) 复杂度IVF 的 nlist/nprobenlist 分桶数nprobe 搜索桶数nprobe 越大召回越高但越慢查询慢怎么优化检查索引是否生效、调 nprobe/ef 参数、数据量是否超内存架构与原理问题简答整体架构存算分离Coordinator 调度 Worker 计算 对象存储持久化 etcd 元数据写入流程写消息日志 → 消费写入对象存储 → Growing Segment可查→ Seal 后建索引插入后多久能查到近实时写入后进入 Growing Segment 立即可查但无索引是暴力扫描实战场景问题简答向量维度怎么选取决于 Embedding 模型BERT 768维OpenAI 1536维百亿级怎么处理分 Collection/Partition DISKANN 分布式集群Embedding 模型升级维度变了新建 Collection重新生成全量向量迁移数据能替代 MySQL 吗不能无 JOIN/聚合通常 Milvus MySQL 配合九、选型建议场景推荐本地开发/测试Milvus Litepip install无需 Docker生产单机Docker 单机版生产集群Milvus 分布式 etcd MinIO云托管Zilliz CloudMilvus 官方云服务与其他向量数据库对比数据库类型特点Milvus开源国产、生态全、十亿级Pinecone云托管闭源SaaS、开箱即用pgvectorPG 插件SQL 原生、迁移成本低Qdrant开源Rust、性能好Weaviate开源内置向量化模块Chroma开源轻量级、适合原型FAISS库Meta 开源、纯计算库、极致性能十、Milvus vs MySQLMilvus 和 MySQL 是互补关系不是替代关系。核心区别在于设计目标不同MySQL 解决结构化数据的精确查询和事务Milvus 解决高维向量的近似最近邻检索。事务与一致性MySQLMilvus事务ACIDBEGIN/COMMIT/ROLLBACK无事务每条插入独立两阶段提交支持XA 协议不支持回滚支持不支持隔离级别4 种RU/RC/RR/Serializable无隔离级别概念一致性强一致最终一致写入后近实时可查并发与锁MySQLMilvus行锁共享锁/排他锁无锁表锁支持无写写并发行锁串行化消息队列串行化天然有序读写并发MVCC 锁读写分离互不阻塞死锁可能发生不可能Milvus 不需要锁的原因追加写入 segment 不可变。写入追加到消息队列天然有序读取操作的是已 Seal 的不可变 segment和写入互不冲突。不存在同一个位置两个人同时改的情况。数据更新MySQLMilvus按主键更新UPDATE t SET x1 WHERE id1upsert(id1, ...)删除旧插入新按条件批量更新UPDATE t SET x1 WHERE ...❌ 不支持部分字段更新UPDATE t SET categorynew❌ 必须提供完整数据含向量自增/计算UPDATE t SET countcount1❌ 不支持Milvus 的 upsert 本质是删除旧记录 插入新记录不是原地修改。频繁 upsert 会产生碎片影响查询性能。查询能力MySQLMilvus精确匹配WHERE id1✅ 标量过滤向量相似度搜索❌✅ ANN 检索JOIN✅❌GROUP BY / 聚合✅❌子查询✅❌全文检索需插件✅ 内置 BM25数据持久化与索引加载MySQLMilvus数据存储磁盘B树对象存储S3/MinIO写入持久性WAL redo log消息队列 对象存储索引位置磁盘按需读页到内存HNSW/IVF 全在内存DISKANN 在磁盘重启恢复从 WAL/redo log 恢复从对象存储重新加载索引到内存生产架构建议实际生产中通常 MySQL Milvus 配合使用用户请求 ├── MySQL业务数据、事务、JOIN、聚合 │ ├── 用户表、订单表 │ └── 按 id 查业务详情 │ └── Milvus向量检索 ├── 文章/商品向量 └── 相似度搜索 → 拿到 id 列表 → 回 MySQL 查详情典型流程1. Milvus 向量检索 → 得到 TopK 的 id 列表 2. MySQL SELECT * FROM articles WHERE id IN (...) → 查业务字段 3. 合并返回给前端十一、Segment 机制Segment 是 Milvus 数据管理的最小单元类似 MySQL 的页但粒度更大。Collection表 ├── Segment 1已 Seal建了 HNSW 索引→ 内存中可查 ├── Segment 2已 Seal建了 HNSW 索引→ 内存中可查 └── Segment 3Growing还在写入→ 内存中可查暴力扫描Segment 生命周期插入数据 → 进入 Growing Segment可变追加写入 │ │ 写满阈值默认约 512MB ↓ Seal冻结不可变→ 后台建索引HNSW/IVF │ ↓ 加载到内存 → 可用索引快速查询两种 SegmentGrowing成长中Sealed已封存状态可变可追加写入不可变冻结索引无暴力扫描有HNSW/IVF 等查询能查但慢遍历能查快走索引在哪内存索引在内存数据在磁盘为什么要分 Segment1. 增量建索引 新写入 10 万条 → 只给这个新 Segment 建索引 不用重建整个 Collection 的索引 2. 并行查询 查询时并行扫描所有 Segment → 合并结果 Segment 1 找到 [A, B, C] Segment 2 找到 [D, E, F] 合并排序 → 返回 TopK 3. 内存管理 可以单独 load/unload 某些 Segment 而不是全量加载或全量卸载和 MySQL 对比MySQLMilvus数据单元页16KBSegment~512MB写入方式原地修改B树追加到 Growing Segment冻结机制无Seal 后不可变建索引全表建按 Segment 增量建