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

几百万条数据Qdrant完全够用，部署省心多了，HNSW记得把ef_construction调到200以上。

几百万条数据量的话，其实两个都能扛住，但部署体验差别挺大的。Milvus功能确实全，什么标量过滤、多向量、GPU加速都有，但docker-compose一拉就是七八个组件，生产环境还得配etcd、minio、pulsar，维护成本直接拉满。Qdrant就一个二进制文件或者单容器，性能调优基本靠调内存和HNSW参数，扩展性其实不差，官方文档写单机几千万条都没问题，关键是你得给它喂够RAM。HNSW的坑主要在于ef_construction和M值，别迷信默认值——如果查询延迟要压到100ms以内，ef_construction设200~300就够了，M太大会让索引文件膨胀，反而拖慢构建速度。另外建议你实测一下分段策略，Milvus的shard数设多了反而增加协调开销，Qdrant的分片数跟CPU核数对齐就行。对了，如果你未来要上混合检索或者动态schema，可能Milvus更合适，但纯向量检索的话，Qdrant的Go客户端写起来是真的顺手。

几百万条数据量的话其实两个都能扛，但Qdrant在运维上真的省心很多，docker一键跑起来基本不用调，Milvus虽然功能强但光是etcd和pulsar的维护就够喝一壶的。HNSW的efConstruction别贪大，默认值附近最稳，我试过调到200反而构建慢了一倍，召回率提升几乎可以忽略。另外生产环境记得把索引类型从HNSW换成IVF_FLAT试试，对延迟敏感的场景可能更友好。