将数据批量上传到 Qdrant
内容提要
Qdrant大规模数据上传需兼顾效率与稳定性：密集向量可存磁盘并用TurboQuant量化降低内存，上传前建好负载索引，稀疏索引可存磁盘；通用做法包括使用gRPC、分批上传（64-256）、并行上传、多分片；上传后确认集合状态为绿色、优化完成再服务流量。
延伸解读
上传策略需按向量类型区分
文章强调，稠密向量和稀疏向量在批量上传时的索引路径不同。稠密向量依赖HNSW，上传过程中后台优化器会构建和更新索引，可能增加CPU和内存压力；稀疏向量则使用独立的索引方式，随点写入而更新。因此，不能将稀疏向量的上传与稠密HNSW索引同等对待，需要根据向量类型选择相应的优化策略。
内存优化与搜索性能的权衡
为降低批量上传时的内存压力，可将稠密向量直接存于磁盘，并配合TurboQuant量化在内存中保留压缩版本。但文章提醒，磁盘存储可能使搜索更依赖磁盘访问，量化也可能影响精度。因此，需要在内存占用和搜索性能之间取得平衡，并用真实数据测试搜索质量和延迟。
通用上传技巧：批处理、并行与分片
无论集合如何配置，批处理、并行上传和分片都是提升吞吐量和稳定性的通用手段。建议使用gRPC连接，批大小从64-256开始，并行数逐步增加，分片数根据部署规模调整。但需注意，过大的批或过高的并行会增加内存和重试成本，分片过多也会带来额外开销。
上传后确认状态再服务流量
文章最后提醒，大规模上传完成后，应确认集合状态为绿色且优化器已完成工作，再开始服务生产流量。这可以避免在索引尚未完全构建时处理查询，导致性能下降或不稳定。提前规划集合和上传过程，能使批量上传更高效、稳定，并易于扩展。
Q&A
Qdrant批量上传数据时，如何降低内存压力？
可以将密集向量直接存储在磁盘上，在创建集合时设置on_disk=True，使向量数据从一开始就使用memmap存储，避免依赖后台优化将向量从内存移到磁盘。
Qdrant中密集向量和稀疏向量在批量上传时有什么不同？
密集向量依赖HNSW索引，上传时后台优化器会构建和更新索引，增加CPU和内存压力；稀疏向量使用独立的索引方式，写入时更新稀疏索引，因此上传策略应区别对待。
Qdrant批量上传时，负载索引应该在什么时候创建？
如果已知哪些字段会用于过滤，应在批量上传点之前创建负载索引。这样过滤搜索可以利用索引提高效率，避免上传后重建HNSW图带来的资源消耗和长时间等待。
Qdrant批量上传时，如何平衡内存和搜索性能？
可以使用TurboQuant量化，将压缩后的向量保留在内存中，原始向量存储在磁盘上。通过bits参数控制压缩级别，如BITS4（默认）接近全精度，BITS1压缩率最高。
Qdrant批量上传时，推荐的批处理大小和并行数是多少？
批处理大小建议从64-256开始，并行上传可以设置parallel参数，例如parallel=4。但并行度不宜过高，以免增加CPU、内存、磁盘I/O和网络压力，应从较小值开始逐步调整。
Qdrant批量上传后，如何确认可以开始服务流量？
上传完成后，应确认集合状态为绿色，并且优化器已完成工作，然后再开始服务生产流量。
