向量数据库选Milvus还是Qdrant？各自有什么坑？

说实话两个我都深度用过，Milvus的坑主要在K8s部署和资源消耗上，版本2.3之后虽然好了一些，但如果你不是大厂运维团队，光调参和分片策略就能折腾好几天，而且索引构建时内存经常爆，社区版对复杂查询支持也不够友好。Qdrant则轻量很多，Rust写的性能确实好，文档清晰，但坑在于它的过滤条件如果写得太复杂，尤其是多字段组合查询，延迟会突然飙升，而且官方对跨节点分布式场景的文档写得比较隐晦，社区案例也少。我个人的建议是，如果你的业务数据量在百万级以下，或者对延迟敏感、想快速上线，Qdrant更省心；但如果要处理上亿级别的高并发场景，并且有专门的运维人力，Milvus的生态和扩展性还是更强。另外不知道你有没有看过Weaviate？它整合了向量和对象存储，上手比这两个都简单，不过底层依赖也重。你现在主要遇到的是什么场景的坑？比如是召回率不达标还是运维成本扛不住？

刚好两个都用过，Milvus在十亿级数据量下确实能扛，但部署和维护成本真的高，尤其集群模式光调参就够喝一壶的。Qdrant上手快多了，Rust写的性能也挺稳，就是社区生态还没那么成熟，遇到冷门bug得自己啃源码。对了，Qdrant的过滤索引在复杂条件查询时容易翻车，建议提前压测一下。

这俩我都深度用过，说点真实感受。Milvus功能确实全，分布式和高可用做得扎实，但部署和维护成本真不低，尤其踩过那个资源隔离的坑——默认配置下查询和写入抢资源，调参调到头秃。而且它的索引构建有时会莫名其妙卡住，得手动重启节点。Qdrant轻量很多，Rust写的就是快，单机性能很强，但集群模式下的分片策略偶尔会出数据倾斜的问题，得自己写脚本平衡。另外Qdrant的过滤查询在复杂条件组合下，性能衰减比Milvus明显，可能是索引结构差异导致的。如果你团队有运维能力、场景复杂，Milvus上限更高；如果只是想快速上线、数据量不太夸张，Qdrant省心很多。不过说实话，向量数据库现在都还在快速迭代期，没有哪个是完美的，关键看你能不能容忍它的缺点。

Milvus和Qdrant我都深度用过，确实各有各的坑。Milvus集群部署时那个依赖组件实在太多了，etcd、minio、pulsar一个都不能少，维护成本直接拉满，而且版本升级经常不兼容，小团队慎入。Qdrant就好很多，单机部署几分钟搞定，Rust写的性能也稳，但它的过滤查询在数据量大了以后容易崩，尤其是高基数标签的场景下，索引构建会卡死。另外Milvus的官方文档虽然全，但实际遇到的问题很多得去GitHub issue里翻，Qdrant社区小一点，中文资料更少，出问题只能硬啃英文。我目前是中小规模场景用Qdrant，省心；规模上了千万级向量再加复杂过滤的话，还是得回Milvus，但得专门配个运维看着。你们现在主要处理多大的数据量？过滤查询复杂吗？