我把向量数据库从 Milvus 切到 pgvector 后，检索 P99 从 230ms 压到 18ms：这 4 个取舍要注意

我把向量数据库从 Milvus 切到 pgvector 后检索 P99 从 230ms 压到 18ms这 4 个取舍要注意RAG 上线三个月后检索 P99 突然从 80ms 涨到 230ms。排查了一圈问题不在 embedding 模型也不在向量维度而是每次查询都要跨一次网络去 Milvus。我们的主服务连着 PostgreSQL向量库却单独跑在一套 K8s 里中间隔着 DNS、负载均衡、序列化反序列化延迟想低都难。后来我把向量检索整体迁到了 pgvector和业务库共用一个 PostgreSQL。改造完后 P99 压到 18ms架构也清爽了不少。但这不是无脑替换有几个取舍必须提前想清楚。老架构Milvus 确实强但对我们太重最开始选型 Milvus 是合理的。它专为向量设计支持十亿级规模、分布式、GPU 索引文档也成熟。我们的场景是把 100 多万条文档切片向量化供 RAG 检索。架构是应用服务 → PostgreSQL业务数据 → Milvus向量检索问题慢慢暴露多一套基础设施Milvus 需要独立集群、独立监控、独立备份。跨网络查询每次 RAG 检索要先去 Milvus 拿 top-k再回 PostgreSQL 查业务字段。运维成本高一次 Milvus 升级导致部分 collection 不可见排查了两个小时。资源利用率低我们的向量量级其实远没触达 Milvus 的优势区间。我算了笔账我们日均向量查询大概 50 万次数据量不到 200 万条向量维度 768。Milvus 的猛兽级能力我们只用到了它 10% 的功能。为这 10% 的功能多养一套集群性价比不高。切到 pgvector把向量存回业务库pgvector 是 PostgreSQL 的向量扩展。安装就是一句CREATE EXTENSION vector;然后表结构可以长这样CREATEEXTENSIONIFNOTEXISTSvector;CREATETABLEdocument_chunks(id BIGSERIALPRIMARYKEY,doc_idBIGINTNOTNULL,chunk_indexINTNOTNULL,contentTEXT,embedding VECTOR(768));CREATEINDEXONdocument_chunksUSINGhnsw(embedding vector_cosine_ops)WITH(m16,ef_construction64);把向量字段和业务字段放在同一张表里最直接的好处是检索结果自带业务字段不需要跨库 JOIN。一个 SQL 就能把向量和业务上下文一起带出来。查询语句SELECTdoc_id,chunk_index,content,embedding:query_vecASdistanceFROMdocument_chunksWHEREdoc_idIN(SELECTdoc_idFROMuser_docsWHEREuser_id:uid)ORDERBYembedding:query_vecLIMIT10;这里WHERE doc_id IN (...)是 RAG 里很常见的业务过滤。在 Milvus 里这种过滤要通过标量过滤或表达式复杂一点就报错在 PostgreSQL 里直接写 SQL爽多了。压测方法不能只盯平均延迟切之前我做了两轮压测。第一轮只看平均延迟Milvus 和 pgvector 差距不大差点让我放弃。后来发现真正的痛点是长尾。Milvus 的 P99 在业务过滤复杂时会突然跳到 200ms 以上因为标量过滤和向量检索不是同一套执行路径协调层会把请求拆成多段。pgvector 走的是 PostgreSQL 自己的执行器计划和索引可以统一优化。压测脚本我用的是 Python asyncio并发 100 个请求每个请求随机抽 100 条向量做 top-10 检索importasyncio,time,random,psycopgfromcollectionsimportdeque DSNpostgresql://user:passlocalhost/dblatenciesdeque()asyncdefquery_one(pool,qvec):t0time.perf_counter()asyncwithpool.connection()asconn:asyncwithconn.cursor()ascur:awaitcur.execute(SELECT doc_id, content FROM document_chunks ORDER BY embedding %s LIMIT 10,(qvec,))awaitcur.fetchall()latencies.append((time.perf_counter()-t0)*1000)asyncdefmain():poolpsycopg.AsyncConnectionPool(DSN,min_size5,max_size20)qvecs[...]# 100 条查询向量awaitasyncio.gather(*[query_one(pool,random.choice(qvecs))for_inrange(1000)])sorted_latsorted(latencies)print(fP50{sorted_lat[500]:.1f}ms P99{sorted_lat[990]:.1f}ms)asyncio.run(main())注意压测时要把 PostgreSQL 连接池和客户端连接池分开。pgvector 的 HNSW 查询主要是 CPU 计算连接池太小会把 PG 的并行度压死。性能对比P99 230ms → 18ms迁移前后的数据指标Milvus 方案pgvector 方案备注平均检索延迟45ms6ms同机房100 并发P99 检索延迟230ms18ms含业务过滤网络往返2 次服务→Milvus→PG1 次同库索引构建时间约 15 分钟约 8 分钟200 万条HNSW运维组件Milvus Etcd MinIOPostgreSQL 本身组件少很多内存占用约 16 GB约 19 GBHNSW 索引在 PG shared_buffers 外P99 的提升主要是消除了跨服务的网络抖动。业务过滤在 PostgreSQL 里走 B 树比在 Milvus 里做标量过滤更稳定。内存虽然多了 3 GB但省掉一套独立集群的 overhead整体成本反而更低。4 个取舍不是银弹1. 索引类型HNSW 还是 IVFFlatpgvector 支持 IVFFlat 和 HNSW。IVFFlat 省内存但高维数据召回和延迟都不如 HNSWHNSW 查询快、召回高但构建慢、内存占用大。我们测过IVFFlatlists100P99 约 55ms召回 92%HNSWm16, ef64P99 约 18ms召回 97%最后选了 HNSW。内存多用了 20%但延迟和召回都更稳。如果你的数据量小、查询频率低IVFFlat 也能用。关键参数是m每个节点最大出度和ef_construction构建时搜索宽度。维度 768 的话m16和ef_construction64是常见起点数据量超过 500 万可以适当调大。2. 和业务库共存资源会打架吗最担心的问题是向量检索把 PostgreSQL 的 CPU/IO 吃光影响业务事务。我们的做法单独表空间把document_chunks放在独立的 SSD 表空间避免和事务表争 IOPS。连接池隔离RAG 查询走只读副本写入走主库。autovacuum 调优大表频繁更新时autovacuum 会抢锁。我们加了autovacuum_vacuum_scale_factor 0.02。ALTERTABLEdocument_chunksSET(autovacuum_vacuum_scale_factor0.02);另外HNSW 索引在查询时几乎不锁表但CREATE INDEX会长时间加锁。上线时可以用CREATE INDEX CONCURRENTLY避免阻塞业务。3. 向量更新批量写入还是实时更新pgvector 的 HNSW 索引在更新时不是完全无锁的。高频单条INSERT或UPDATE会导致索引页竞争写入延迟飙升。我们的做法是业务端先把向量变更写到 staging 表每分钟批量INSERT到主表并用pg_advisory_lock串行化索引更新。importpsycopg2defbatch_insert_embeddings(rows):withpsycopg2.connect(DSN)asconn:withconn.cursor()ascur:cur.execute(SELECT pg_advisory_lock(42))cur.executemany(INSERT INTO document_chunks (doc_id, chunk_index, content, embedding) VALUES (%s, %s, %s, %s),rows)cur.execute(SELECT pg_advisory_unlock(42))conn.commit()实际写入峰值从单条 200ms 降到了批量 15ms。如果更新频率不高也可以直接单条写但要把事务控制在合理的并发数内。4. 扩展天花板什么时候该回退pgvector 不是替代 Milvus 的万能药。如果未来向量规模涨到几千万、几亿或者需要多租户隔离、混合查询极其复杂我们可能还要重新考虑专用向量数据库。目前定的阈值是数据量 500 万条pgvector 够用。日均查询 100 万pgvector 能扛。超过任一阈值评估重新拆分出专用向量库。这里的数据量不是纯向量数而是“活跃索引中的向量数”。如果旧数据可以归档pgvector 的寿命会更长。监控看板我们盯了哪些指标切过去后我搭了一个简单的监控看板核心指标就三个pg_stat_user_tables.n_tup_ins和n_tup_upd观察向量写入速率防止单条更新把索引拖垮。pg_stat_activity中state active的查询数确认连接池没有被打满。业务层的 P99 检索延迟用 Prometheus histogram 直接埋点比看数据库平均延迟更真实。SELECTschemaname,relname,n_tup_ins,n_tup_upd,n_live_tupFROMpg_stat_user_tablesWHERErelnamedocument_chunks;这几个指标够用不用整太复杂。迁移踩坑记录1.pgvector扩展版本问题旧版 PostgreSQL 13 的 pgvector 版本太低不支持 HNSW。我们先升级到了 PostgreSQL 15再装扩展。2. 距离函数选错我们默认用了-L2但 embedding 模型用的是 cosine 归一化应该用。换到 cosine 后召回率提升了 4%。3. 索引参数没调默认 HNSW 参数m16, ef_construction64对 768 维数据够用但ef查询参数在 SQL 里设置SET hnsw.ef 32对 P99 影响很大。调到 64 后召回和延迟达到我们想要的平衡点。SEThnsw.ef64;4. 并发写入时索引膨胀一开始用多线程同时写结果表和索引都膨胀得厉害。改成单连接批量 pg_advisory_lock后稳定下来。写在最后把 Milvus 切到 pgvector不是因为它更好而是因为它更适合我们当前的数据规模和团队栈。省掉一套独立中间件意味着少一套监控、少一份 on-call 压力、少一堆跨服务问题。代价是你要接受 PostgreSQL 的资源边界并学会在 HNSW 索引、批量写入、查询参数之间做权衡。如果你的向量量级和我差不多主库已经是 PostgreSQL不妨先试试 pgvector。别急着上猛兽合适比先进更重要。