刚学向量数据库，Milvus和Qdrant到底该怎么选？

几百万条这量级其实两个都能扛，主要看你团队运维能力。我当初图省事先上了Qdrant，单机跑得很稳，后来数据涨到千万级才发现分片迁移确实麻烦，折腾了好一阵。Milvus功能全但光那一堆依赖组件就够喝一壶的，如果你们有专人搞运维就选它，不然Qdrant省心太多。HNSW的坑倒是有一个，M别一上来就调很高，默认16先跑通，efConstruction和efSearch得配合着调，不然内存直接爆掉，我吃过这亏。

几百万条这量级其实两个都能扛，主要看你运维团队有多能折腾。Milvus那个依赖etcd、MinIO啥的，光搭环境就够喝一壶，但要是你后面要上过滤、混合检索这些高级玩法，它确实是Qdrant比不了的。Qdrant胜在省心，单机docker一把梭，延迟也稳，我这边之前压过100ms以内问题不大。HNSW的坑主要在efConstruction别贪大，设个200-300就行，再高建索引慢到哭，还有efSearch要按你的延迟预算去调，不是越大越准。建议先拿你真实数据量去两台机器各压一遍看看召回率和内存占用，毕竟文档说和实际跑起来是两码事。

几百万的量其实qdrant够用，部署省心太多了，milvus那套组件光运维就够喝一壶的。

几百万条数据、100ms以内的延迟，这两个条件其实都不算苛刻，Milvus和Qdrant都能扛住。我去年有个类似规模的项目先用的Milvus，后来迁到了Qdrant，主要原因是Milvus那套etcd+MinIO+Pulsar的依赖链太重，小团队维护成本高，出问题排查起来也累。Qdrant单机性能其实很能打，Rust写的，内存占用比Milvus友好不少，几百万向量用HNSW完全够用，扩展性方面它现在也支持分布式了，虽然生态没Milvus那么热闹，但该有的都有。HNSW参数上M和efConstruction是关键，M一般16到32够用，调太大内存涨得厉害收益还不明显，efConstruction建议200起步再往上试。真正容易踩坑的是查询时的ef，很多人只调索引参数忘了这个，ef太小召回率掉得很难看，太大延迟又上去了，得拿自己的数据集实际测。另外别忘了payload过滤这块，Qdrant的filterable HNSW做得比Milvus顺手，如果RAG里有元数据过滤需求，这点值得重点考虑。

几百万数据量其实两个都扛得住，Qdrant单机跑100ms以内没啥压力，扩展性也没想象中那么差，分片和副本都支持了。Milvus胜在生态和索引类型全，但你要是小团队维护，etcd加minio那套确实有点重。HNSW的m和efConstruction别调太高，内存吃得吓人，ef搜的时候按召回率慢慢往上加就行，另外记得开标量过滤和向量索引的联合优化，不然过滤完再搜会很慢。

几百万条数据、100ms以内延迟，这俩其实都能扛住，关键看你团队运维能力和后续扩展预期。我自己两个都用过，Qdrant单机性能非常能打，Rust写的，内存占用也友好，部署起来一个docker就起来了，几百万向量根本不算大，别被“轻量”吓到，它分布式版本虽然晚点但现在已经能用了。Milvus功能确实全，但组件多，etcd、minio、pulsar一堆，你要是没专职运维，出问题排查起来挺头疼的。HNSW那块，M和efConstruction别照默认抄，M太大内存爆炸，太小召回掉得厉害，一般16到32先试，efConstruction往200以上调，查询时的ef也得根据召回要求动态调，别设死了。还有payload过滤这块，Qdrant的filterable HNSW做得比早期Milvus顺手，如果RAG里要带元数据过滤，这点值得考虑。建议你先拿真实数据各跑一轮压测，别光看文档，实际体感差挺多的。

几百万条数据两个都扛得住，Qdrant单机性能其实挺猛的，上生产没那么不堪。不过你们团队要是没人专门维护基础设施，Milvus那套etcd+minio+pulsar的组合真能折腾死人。HNSW的ef_construction调太低召回率会崩，M值也别无脑拉满，内存吃不消。建议先拿Qdrant跑一版，真到千万级再考虑换。