向量数据库和ES都能做语义搜索，实际项目里到底怎么选？

几百万条这个量级，ES的kNN其实完全能扛，尤其你还带用户ID、时间这种硬过滤条件，ES那边filter和search走同一个段，省一次网络往返。不过真要上高并发，比如每秒几百个查询，ES的瓶颈在内存和段合并，召回率倒不是问题，主要看你的embedding维度。我建议先压测ES，扛不住再上向量库，不然多一套Milvus还得同步数据，运维成本直接翻倍。至于和关系库配合，我一般是业务数据放MySQL，向量和元数据都扔向量库，按需回表查细节，别搞双写，容易出脏数据。

几百万量级真不用纠结，ES自带kNN加过滤够用了，少维护一套系统省心多了。

几百万条这个量级其实挺微妙的，ES的kNN只要把filter字段和向量索引规划好，响应完全能压到几十毫秒，省掉一套Milvus集群的运维成本真不是小事。不过得提醒一句，ES的HNSW参数调起来比较糙，如果召回率要求特别苛刻，尤其是过滤条件特别多且选择性很强的时候，向量库的索引分片策略会更灵活。我之前在项目里试过，ES在无过滤或低过滤率场景下和专用向量库差距不大，但一旦加了用户ID这种高基数过滤，ES的暴力扫描段就可能拖慢查询，这时候Qdrant的payload过滤优势就出来了。至于和关系库配合，我现在的做法是MySQL存元数据和业务状态，向量库只存embedding和主键，先向量召回拿到ID列表再去MySQL回表补全信息，避免两边数据不一致的同步地狱。倒是想问问，你那几百万条数据更新频率高吗？如果每天都有大批量增删改，ES的段合并和向量库的增量构建代价完全不是一个量级。

几百万条这量级其实ES的kNN完全能扛，我司之前就是纯ES做的，过滤条件多的话它优势反而大，向量库那些过滤做得好的也就那样。不过你如果后续数据涨得猛或者并发上去了，ES的召回率和延迟确实会抖，得提前压测。真要选向量库，别想着替代关系库，拿它当纯检索服务，业务数据扔MySQL，先查后召回或者先召回再过滤都行，反正别让向量库管状态。

几百万条加毫秒级响应，ES的kNN其实够用了，我们之前用8分片跑过类似量级，过滤条件写进query里没太大问题，省一套运维很香。但如果后续数据涨到千万级以上，或者对召回率特别敏感，向量库的优势就出来了，尤其Milvus在GPU加速和标量过滤的并行处理上确实更稳。我的建议是先用ES顶着，把过滤逻辑和索引调明白，真到了瓶颈再迁向量库也不迟，毕竟迁移成本主要在设计层面。至于配合关系库，我一般把向量库当纯检索层，业务数据还在MySQL里，拿到topk结果后再回表查详情，这样两边职责清晰，也不用担心一致性问题。

几百万量级ES够用，但复杂过滤加高并发还是上Milvus，省心。数据双写呗，元数据丢MySQL，向量丢向量库。

说实话你这场景我太熟了，几百万条加复杂过滤，ES的kNN其实挺能打的，尤其是你已经有ES在跑业务的话，省一套运维真不是小事。但要注意ES的kNN得提前把filter和向量检索的交互想清楚，官方文档里那种pre-filter和post-filter的坑我踩过，召回率在过滤条件特别严的时候掉得挺明显。Milvus这类专用库在高并发和纯向量检索上确实更稳，但一旦牵扯到用户ID、时间这种结构化过滤，你得自己维护一份元数据映射，或者干脆再搭个Redis做倒排，架构复杂度一下就上来了。我现在的做法是ES做主存储和复杂过滤，向量只存embedding的ID，召回后用ES的terms查询去重排序，效果还行，但延迟会比纯向量库多个几毫秒，看你能否接受。至于和关系型数据库配合，我觉得别让向量库管业务状态，它只负责算距离，真正的文档内容、权限校验、版本管理全放MySQL或PG，用异步任务同步embedding和元数据变更，这样出了问题好回滚。还有个疑问想请教下，你那个开源embedding模型对中文长文档的效果稳定吗，我之前试过几个，在段落切分后语义漂移挺厉害的，有时候召回准但排序乱，这块可能比数据库选型更影响最终体验。

几百万条加复杂过滤，ES的kNN其实够用，省一套运维挺香。

几百万数据加复杂过滤，ES的kNN确实能扛，但得注意filter和向量检索的执行顺序，搞不好会先扫全量再过滤，延迟就上去了。我们生产环境用Qdrant配合PG，PG存元数据和业务字段，向量库只负责召回，过滤条件通过payload带进去，这样两边各干各的活。高并发下向量库的HNSW索引确实比ES稳一些，但运维多一套是实打实的成本。建议先拿ES压测一下你们的真实查询模式，如果过滤后候选集很小，ES未必输。

几百万条ES的kNN扛得住，过滤条件多反而它更顺手，省一套运维真香。

几百万数据加复杂过滤，ES的kNN其实够用，省一套运维真香；但召回要求高还是上Milvus稳。