Qdrant向量数据库实战：从架构解析到生产部署-深圳市維司達科技有限公司

1. 项目概述：向量数据库的“新基建”

最近几年，AI应用，特别是大语言模型和生成式AI的火爆，让一个原本相对小众的技术领域走到了聚光灯下——向量数据库。如果你尝试过构建一个基于私有知识库的智能问答机器人，或者想为自己的图片、视频库添加“以图搜图”的智能检索功能，那你大概率已经接触过“向量”和“向量搜索”这些概念了。简单来说，传统数据库擅长处理“张三的年龄是25岁”这类精确的结构化查询，而向量数据库则专精于处理“给我找几张和这张风景照意境相似的图片”这类模糊的、基于语义或内容的相似性搜索。

qdrant/qdrant正是在这个浪潮中脱颖而出的一个开源向量数据库和相似性搜索引擎。它不是一个简单的库，而是一个功能完备、可以独立部署的服务。你可以把它想象成一个专门为高维向量数据（比如一段文本经过AI模型转换成的512维浮点数数组）量身定做的“超级索引器”和“高速检索机”。它的核心价值在于，能够以极快的速度，从上亿甚至十亿级别的向量数据中，找出与目标向量最相似的那一小撮结果。

我最初接触Qdrant，是在为一个客户构建企业级知识库检索系统时。当时评估了市面上几乎所有主流的开源和商业方案，最终选择Qdrant，是因为它在性能、功能完整度和开发者体验上找到了一个非常棒的平衡点。它用Rust语言编写，这意味着在内存安全和执行效率上有先天优势；它提供了丰富的API（包括gRPC和REST）以及多语言的客户端SDK，让集成变得异常简单；更重要的是，它的设计理念非常“云原生”和“生产就绪”，从数据持久化、分布式部署到复杂的过滤查询，都考虑得相当周全。

所以，无论你是一个想快速验证AI应用创意的独立开发者，还是一个需要为海量非结构化数据构建检索平台的企业架构师，Qdrant都值得你深入了解。它降低了向量搜索技术的应用门槛，让开发者能更专注于业务逻辑，而不是底层索引算法的实现与优化。

2. 核心架构与设计哲学解析

2.1 为什么是Rust？性能与安全的基石

Qdrant选择用Rust语言实现，这绝非偶然，而是其追求极致性能与可靠性的核心体现。在向量数据库这个领域，性能瓶颈主要来自两方面：一是海量向量距离计算带来的巨大算力消耗（通常是CPU密集型）；二是高并发读写场景下的内存管理与数据一致性挑战。

Rust的“零成本抽象”和“无垃圾回收”特性，在这里发挥了巨大优势。首先，在计算层面，Rust能生成堪比C/C++的高效机器码，对于需要大量循环和浮点运算的向量距离计算（如余弦相似度、欧氏距离），它能将硬件性能压榨到极致。其次，没有GC（垃圾回收）意味着没有“Stop-The-World”的停顿，这对于要求低延迟、高吞吐的在线服务至关重要，保证了检索响应时间的稳定性和可预测性。

注意：很多开发者会担心Rust的学习曲线。但作为Qdrant的使用者，你完全不需要精通Rust。你通过HTTP API或各种语言的客户端SDK与之交互，其复杂度被很好地封装了起来。选择Rust是Qdrant团队为了给你提供一个更稳定、更高效的后端引擎，而不是增加你的使用成本。

更重要的是Rust的所有权系统和内存安全保证。向量数据库需要长时间管理大量内存中的数据（索引常驻内存以加速搜索）。Rust在编译期就杜绝了数据竞争、空指针解引用、缓冲区溢出等常见的内存错误，这极大地增强了系统的稳定性和安全性，减少了生产环境中因内存问题导致的诡异崩溃，这对于需要7x24小时提供服务的数据库来说是无价的。

2.2 核心概念：集合、点、向量与负载

要高效使用Qdrant，必须理解其数据模型中的几个核心概念，它们构成了所有操作的基础。

集合：这是最高层次的数据容器，类似于传统数据库中的“表”或“索引”。你通常会为同一类数据创建一个集合，例如“产品图片向量”、“新闻文章向量”或“用户画像向量”。创建集合时，你需要定义向量的维度（例如，text-embedding-ada-002模型生成的是1536维），以及选用的距离度量方式（如余弦相似度Cosine、点积Dot、欧氏距离Euclid）。

点：集合中的一条记录或一个数据项，称为一个“点”。每个点由三部分组成：

id：一个唯一的标识符，可以是整数或UUID，用于精确查找或更新。
vector：核心数据，一个浮点数数组，代表你数据的嵌入表示。
payload：一个可选的JSON对象，用于存储与该向量关联的原始数据或元数据。这是Qdrant非常强大的一个特性。例如，你的向量是文章摘要的嵌入，那么payload里可以存储文章的标题、作者、发布日期、分类等。后续搜索时，你不仅可以按向量相似度排序，还可以用payload中的字段进行复杂的过滤。

这种设计实现了“向量”与“元数据”的分离与联合。向量专门用于高效的相似性搜索，而payload则承载了丰富的业务属性，支持灵活的过滤和聚合。这比一些将元数据编码进向量的方案要清晰和高效得多。

2.3 存储与索引引擎：HNSW的魅力与配置权衡

Qdrant默认使用，也是其高性能搜索的基石，是HNSW算法。HNSW全称“可导航小世界图”，它是一种近似最近邻搜索算法。理解它为什么快，有助于你进行合理的配置。

想象一下，你要在一个拥有千万人口的城市里（所有向量点），快速找到离你最近的咖啡馆（最近邻）。最笨的方法是测量你到每一个咖啡馆的距离（暴力搜索）。HNSW则像在这个城市里建立了一个多层次的高速公路网。最上层是少数几个枢纽（长连接），中间层有更多节点，最底层是所有的具体地址。搜索时，从顶层枢纽开始，快速定位到大致区域，然后逐层向下细化，最终找到目标。这种方法牺牲了微不足道的绝对精度（比如找到的是最近的第2、3名，而非绝对第1名），却换来了几个数量级的搜索速度提升。

在Qdrant中，创建集合时与HNSW相关的关键参数有：

m：构建图时每个节点创建的最大连接数。值越大，图越密集，精度越高，但构建速度和内存占用也越大。通常范围在16-64之间，默认值16是一个很好的平衡点。
ef_construct：构建索引时，动态候选列表的大小。影响索引构建的质量和速度。值越大，构建的索引质量越高（搜索精度越高），但构建越慢。
ef_search：搜索时动态候选列表的大小。这是搜索时最重要的参数之一。值越大，搜索精度越高，但耗时越长。这是一个典型的“精度-速度”权衡旋钮。在生产中，你需要根据业务对延迟和召回率的要求来调整它。

除了内存索引，Qdrant还使用RocksDB作为持久化存储引擎。所有向量、payload和索引元数据都可靠地存储在磁盘上。这意味着Qdrant服务重启后，数据不会丢失。这种“内存索引（HNSW）+ 磁盘存储（RocksDB）”的架构，兼顾了极致的内存检索速度和可靠的数据持久化。

3. 从零开始：部署与基础操作实战

3.1 多种部署方式：选择最适合你的场景

Qdrant提供了极其灵活的部署选项，从本地开发到大规模生产集群都能覆盖。

1. 使用Docker（最快上手，推荐开发测试）：这是最推荐初学者和开发者的方式。一条命令就能跑起来。

docker pull qdrant/qdrant docker run -p 6333:6333 -p 6334:6334 \ -v $(pwd)/qdrant_storage:/qdrant/storage:z \ qdrant/qdrant

解释一下参数：-p 6333:6333映射REST API端口，-p 6334:6334映射gRPC端口。-v参数将主机目录挂载到容器内，用于持久化数据，这样即使容器删除，你的向量数据也不会丢失。

2. 从源码编译（用于深度定制或开发）：如果你需要修改源码或使用最新的开发版，可以克隆仓库并编译。

git clone https://github.com/qdrant/qdrant.git cd qdrant cargo build --release --bin qdrant # 编译产物位于 ./target/release/qdrant

3. 云服务（最省心，生产环境推荐）：Qdrant官方提供了完全托管的云服务。你无需关心服务器、运维、升级和备份，只需通过API使用即可。这对于创业公司或没有专门运维团队的项目来说，能大幅降低初始成本和运维风险。你可以根据数据量和QPS选择不同的套餐。

4. Kubernetes部署（大规模生产）：Qdrant提供了Helm Chart，可以轻松地在K8s集群中部署有状态副本集。这对于需要高可用、弹性伸缩和自动化运维的企业级场景是标准选择。配置文件中可以详细定义资源请求、持久化卷、服务发现等。

3.2 第一个集合：创建、插入与查询

让我们通过一个完整的例子，感受一下Qdrant的基本工作流。假设我们要构建一个电影推荐系统，根据电影描述的语义向量来寻找相似电影。

步骤1：启动Qdrant服务使用上述Docker命令启动服务后，API将在http://localhost:6333可用。

步骤2：创建集合我们需要创建一个名为movies的集合，假设我们使用一个能生成384维向量的句子嵌入模型。

curl -X PUT http://localhost:6333/collections/movies \ -H 'Content-Type: application/json' \ -d '{ "vectors": { "size": 384, "distance": "Cosine" } }'

这个请求定义了一个向量维度为384，使用余弦相似度作为距离度量方式的集合。余弦相似度非常适合文本语义相似度比较，因为它关注向量的方向而非大小。

步骤3：插入点（数据）现在，我们插入一些电影数据。每个点包含id、向量和payload。

curl -X POST http://localhost:6333/collections/movies/points \ -H 'Content-Type: application/json' \ -d '{ "points": [ { "id": 1, "vector": [0.12, -0.45, 0.23, ...], // 384维向量，此处省略 "payload": {"title": "Inception", "genre": ["sci-fi", "action"], "year": 2010} }, { "id": 2, "vector": [0.15, -0.42, 0.20, ...], "payload": {"title": "The Matrix", "genre": ["sci-fi", "action"], "year": 1999} }, { "id": 3, "vector": [-0.05, 0.30, -0.10, ...], "payload": {"title": "The Notebook", "genre": ["drama", "romance"], "year": 2004} } ] }'

在实际应用中，vector字段需要通过你的嵌入模型（如OpenAI的text-embedding-ada-002，或开源的sentence-transformers模型）将电影描述文本计算出来。payload里存储了便于人类理解的原始信息。

步骤4：执行相似性搜索这是最核心的操作。假设我们有一部电影《盗梦空间》（Inception），想找到风格类似的电影。

curl -X POST http://localhost:6333/collections/movies/points/search \ -H 'Content-Type: application/json' \ -d '{ "vector": [0.12, -0.45, 0.23, ...], // 《盗梦空间》的向量 "limit": 5 }'

Qdrant会返回与目标向量最相似的5个点（包括《盗梦空间》本身）。结果会包含点的id、相似度得分（score）以及payload。不出意外的话，《黑客帝国》（The Matrix）会以很高的相似度得分排在前面，而《恋恋笔记本》（The Notebook）则可能不会出现在结果中，因为它们的向量在语义空间里相距较远。

3.3 使用客户端SDK：提升开发效率

虽然cURL可以用于演示和调试，但在真实项目中，使用官方SDK是更高效、更安全的方式。Qdrant提供了Python、Go、Rust、Java等主流语言的SDK。

以Python为例，使用qdrant-client库：

from qdrant_client import QdrantClient from qdrant_client.http import models # 1. 连接客户端 client = QdrantClient(host="localhost", port=6333) # 或 QdrantClient(url="http://localhost:6333") # 2. 创建集合（如果不存在） client.recreate_collection( collection_name="movies", vectors_config=models.VectorParams(size=384, distance=models.Distance.COSINE), ) # 3. 插入数据 client.upsert( collection_name="movies", points=[ models.PointStruct( id=1, vector=[0.12, -0.45, 0.23, ...], # 你的向量 payload={"title": "Inception", "genre": ["sci-fi", "action"], "year": 2010} ), # ... 更多点 ] ) # 4. 搜索 hits = client.search( collection_name="movies", query_vector=[0.12, -0.45, 0.23, ...], # 查询向量 limit=5 ) for hit in hits: print(hit.id, hit.score, hit.payload)

SDK封装了所有API细节，提供了类型提示和更Pythonic的接口，能极大提升开发体验和代码健壮性。

4. 高级功能与生产级应用

4.1 有效负载过滤：让搜索更精准

单纯的向量相似度搜索有时过于“粗放”。回到电影的例子，你可能想：“给我找和《盗梦空间》相似的电影，但不要1990年以前的，并且我只想看科幻片。” 这就是Payload过滤的用武之地。

Qdrant的搜索API支持强大的过滤条件，语法灵活，支持嵌套字段和多种操作符（gt,gte,lt,lte,match,range,geo等）。

from qdrant_client.models import Filter, FieldCondition, MatchValue, Range # 构建一个过滤器：genre包含"sci-fi" 且 year >= 1990 search_filter = Filter( must=[ FieldCondition(key="genre", match=MatchValue(value="sci-fi")), FieldCondition(key="year", range=Range(gte=1990)), ] ) hits = client.search( collection_name="movies", query_vector=[0.12, -0.45, 0.23, ...], query_filter=search_filter, # 应用过滤器 limit=5 )

这个搜索会先通过HNSW图快速找到语义相似的候选点，然后在候选点中应用过滤器，只返回满足条件的点。过滤是在检索后执行的，这意味着它不会影响HNSW的搜索路径。对于复杂的过滤条件，Qdrant还会为payload中的字段建立可选的索引（如哈希索引、整数索引、文本索引），以加速过滤过程。

实操心得：过滤条件的设计需要谨慎。如果过滤条件过于严格，可能会在向量搜索后过滤掉大量结果，导致返回数量不足（limit）。此时可以考虑调整limit参数，先获取更多的候选点再进行过滤，或者优化你的数据payload结构。

4.2 多向量与命名向量：应对复杂数据模型

一个数据点并非只能有一个向量。Qdrant支持“命名向量”，允许一个点拥有多个不同维度、不同含义的向量。这为复杂的多模态搜索打开了大门。

例如，一个商品点可以同时拥有：

一个基于“商品标题和描述”生成的文本向量（维度：768）。
一个基于“商品主图”生成的图像向量（维度：512）。
一个基于“用户评论摘要”生成的情感向量（维度：256）。

你可以为这些向量分别命名，如title_vector,image_vector,review_vector。

创建集合时需要定义所有向量配置：

client.recreate_collection( collection_name="products", vectors_config={ "title_vector": models.VectorParams(size=768, distance=models.Distance.COSINE), "image_vector": models.VectorParams(size=512, distance=models.Distance.COSINE), "review_vector": models.VectorParams(size=256, distance=models.Distance.COSINE), } )

搜索时，你需要指定使用哪个命名向量进行查询：

# 用文本向量搜索相似商品 hits = client.search( collection_name="products", query_vector=([0.1, ...], "title_vector"), # 元组形式：(向量, 向量名) limit=5 ) # 用图像向量搜索相似商品（以图搜物） hits = client.search( collection_name="products", query_vector=([0.3, ...], "image_vector"), limit=5 )

你甚至可以执行跨模态搜索，例如用一段文本描述（生成文本向量）去搜索相似的图片（使用image_vector索引），只要它们在语义空间中对齐得当。

4.3 分片与复制：实现可扩展性与高可用

当你的数据量超过单机内存容量，或者查询QPS超过单机处理能力时，就需要分布式部署。Qdrant原生支持分布式架构，核心概念是分片和复制。

分片：将一个大的集合水平分割成多个部分，每个部分称为一个分片，可以分布在不同的物理节点上。查询请求会被路由到所有分片，各分片并行搜索，最后合并结果。这解决了数据量（容量）和查询吞吐量（性能）的扩展问题。
复制：为每个分片创建多个副本（副本集）。其中一个副本是领导者，负责处理写操作和强一致性读；其他副本是追随者，异步同步数据，用于负载均衡读请求和提供高可用性。如果领导者节点故障，系统会自动选举一个新的领导者。

在Qdrant Cloud或自建集群中，你可以通过配置来定义分片数和副本因子。例如，一个拥有1000万个向量的集合，可以配置为4个分片，每个分片2个副本，这样总共需要8个节点来承载（4分片 x 2副本）。

配置示例（概念性）：

# 在集群配置中指定集合的分布策略 collection_config: shard_number: 4 # 4个分片 replication_factor: 2 # 每个分片2个副本 write_consistency_factor: 2 # 写操作需要至少2个副本确认才成功

write_consistency_factor是一个重要的生产参数。它决定了写操作需要同步到多少个副本才算成功。设为1（默认）意味着只要领导者写入成功就返回，性能最高，但存在数据丢失风险（领导者宕机前未同步数据）。设为2或等于replication_factor，则能保证更高的数据可靠性，但写延迟会增加。你需要根据业务对数据一致性的要求来权衡。

5. 性能调优、监控与问题排查

5.1 索引参数调优指南

默认配置适用于大多数场景，但针对特定工作负载进行调优，能获得显著的性能提升。以下是一些关键参数：

ef_search（搜索时动态候选列表大小）：
- 作用：控制搜索精度与速度的平衡。值越大，搜索越精确（召回率越高），但越慢。
- 调优建议：从默认值100开始。在测试集上，逐步增加ef_search（如200，400），观察召回率（找到的真实最近邻的比例）和延迟的变化。找到满足你业务最低召回率要求的最小ef_search值。对于延迟敏感的应用（如实时推荐），可能需要在召回率上做些妥协。
m（HNSW图中每个节点的最大连接数）：
- 作用：影响图的连通性和索引质量。m越大，图越“稠密”，搜索路径更短更精确，但索引构建更慢，内存占用更大，插入点也更慢。
- 调优建议：对于静态数据集（很少更新），可以适当增大m（如32或64）来构建一个高质量的索引，获得长期的最佳搜索性能。对于需要频繁增删的数据集，保持较小的m（如16）以维持插入速度。内存有限时，也应优先考虑较小的m。
payload索引：
- 作用：为payload中的字段建立二级索引（如关键字索引、整数范围索引、地理空间索引），以加速过滤操作。
- 调优建议：只为那些频繁用于过滤且基数较高（不同值较多）的字段建立索引。例如，user_id（基数高，常过滤）适合建索引；而is_active（只有true/false两种值）建索引收益不大。索引会占用额外内存和存储，并减慢写入速度。
在创建集合或插入数据后，可以创建索引：
```
client.create_payload_index( collection_name="movies", field_name="year", field_schema=models.PayloadSchemaType.INTEGER, )
```

5.2 监控与运维要点

将Qdrant用于生产环境，必须建立有效的监控。

内置Metrics端点：Qdrant在http://localhost:6333/metrics提供了丰富的Prometheus格式指标。这是监控的核心数据源。
- 关键指标：
  - app_grpc_requests_duration_seconds：gRPC请求耗时直方图。
  - app_http_requests_duration_seconds：HTTP请求耗时直方图。
  - qdrant_collections_total：集合数量。
  - qdrant_collection_vectors_total：每个集合的向量总数。
  - process_resident_memory_bytes：进程占用内存。
  - rocksdb_*：RocksDB相关的IO和状态指标。
健康检查：API端点http://localhost:6333/health返回服务健康状态。
日志：通过环境变量RUST_LOG控制日志级别。生产环境建议设置为RUST_LOG=qdrant=info。日志有助于排查慢查询、错误请求等问题。
磁盘与内存：
- 磁盘：监控存储目录（默认./storage）的容量。RocksDB的压缩和SST文件管理需要足够空间。
- 内存：HNSW索引和正在服务的分片数据常驻内存。确保服务器有足够RAM。监控process_resident_memory_bytes，如果持续增长并接近物理内存上限，可能需要优化索引参数、增加内存或启用分片将数据分布到更多节点。

5.3 常见问题与排查实录

在实际使用中，你可能会遇到以下典型问题：

问题1：搜索速度突然变慢。

可能原因A：内存交换。检查系统是否发生了内存交换（swap）。使用free -h或top命令查看。一旦发生交换，速度会下降数个数量级。
- 解决方案：增加物理内存，或者通过优化m参数、减少副本数、将不活跃集合卸载（unload）来降低内存使用。
可能原因B：ef_search值设置过高。在流量高峰时，过高的ef_search会导致CPU和延迟飙升。
- 解决方案：根据监控，动态调整ef_search，或在业务层面实施限流降级。
可能原因C：磁盘IO瓶颈。虽然搜索主要靠内存索引，但过滤时可能需要从磁盘读取payload，如果磁盘慢或负载高，会影响整体延迟。
- 解决方案：使用高性能SSD，并监控磁盘IO使用率。

问题2：插入点（upsert）失败或报错。

可能原因A：向量维度不匹配。尝试插入的向量维度与集合定义不符。
- 解决方案：检查插入数据的向量长度。确保嵌入模型输出维度与集合size一致。
可能原因B：ID冲突。upsert操作中，如果ID已存在，默认会更新该点。但如果是并发写入，可能需要处理版本冲突。
- 解决方案：使用SDK的wait=true参数确保操作同步完成，或实现业务层的重试机制。
可能原因C：Payload字段类型不匹配。例如，尝试为已存储整数的字段插入字符串。
- 解决方案：Qdrant的payload是schema-less的，但类型在第一次插入时会被推断并“锁定”。确保同一字段后续插入的数据类型一致。

问题3：过滤后返回结果为空，但不过滤时有结果。

可能原因：过滤条件太严格，或者payload字段名/类型有误。
- 排查步骤：
  1. 先执行一个不带过滤的搜索，确认数据存在。
  2. 检查过滤条件语法，特别是嵌套字段的路径（如metadata.tags）。
  3. 使用scrollAPI 或查询单个点，确认目标点的payload结构与你的过滤条件匹配。
  4. 对于match条件，注意是匹配整个值还是子串（MatchText用于子串，MatchKeyword用于精确匹配）。

问题4：集群节点状态异常。

可能原因：网络分区、节点宕机或资源不足。
- 解决方案：
  1. 检查集群节点间的网络连通性。
  2. 查看异常节点的日志，寻找OOM（内存不足）或磁盘满的错误信息。
  3. 利用Qdrant的Raft共识协议，在多数派节点存活的情况下，集群应能自动恢复。确保replication_factor设置合理，允许少数副本故障。

问题5：数据一致性疑虑（读不到刚写入的数据）。

可能原因：Qdrant默认的读一致性是“最终一致性”。写入领导者后，数据异步复制到追随者。如果立即从追随者读取，可能读不到最新数据。
- 解决方案：
  1. 强一致性读：在搜索请求中指定consistency=“majority”或consistency=“all”。这会确保从已同步最新数据的副本读取，但延迟更高。
  2. 会话一致性：对于用户会话内的操作，可以使用shard_key将同一用户的所有请求路由到同一个副本，在该副本内保证读写顺序。
  3. 业务层容忍：如果业务允许短暂的数据延迟，使用默认设置即可，这是性能和可用性最好的选择。

6. 生态整合与最佳实践

6.1 与AI框架和编排工具的集成

Qdrant很少单独使用，它通常是AI应用流水线中的一环。与上下游工具的顺畅集成至关重要。

1. 与嵌入模型协同工作：你的数据（文本、图像）需要先通过嵌入模型转化为向量，才能存入Qdrant。常见的模式是：

离线批处理：使用Apache Spark、AWS Glue等ETL工具，调用嵌入模型API或本地模型，批量生成全量数据的向量，然后导入Qdrant。
在线实时处理：在应用服务器中，当用户生成新内容（如发布一篇文章）时，实时调用嵌入服务（如OpenAI API，或部署的sentence-transformers模型），生成向量后立即插入Qdrant。

2. 与LangChain、LlamaIndex等AI编排框架集成：这些框架将LLM、向量数据库、工具调用等组件抽象化，让你能快速搭建复杂的AI应用。Qdrant是它们的首选向量数据库后端之一。

以LangChain为例，集成只需几行代码：

from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import Qdrant from langchain.document_loaders import TextLoader # 加载文档 loader = TextLoader(“state_of_the_union.txt”) documents = loader.load() # 创建向量库 embeddings = OpenAIEmbeddings() qdrant_vector_store = Qdrant.from_documents( documents, embeddings, url=“http://localhost:6333", collection_name=“state_of_the_union”, ) # 之后，就可以将其用作检索器 retriever = qdrant_vector_store.as_retriever()

这极大地简化了构建RAG（检索增强生成）应用的过程。

3. 在Kubernetes中与模型服务共部署：在K8s集群中，你可以将Qdrant StatefulSet、嵌入模型服务（如用Triton Inference Server部署的模型）、以及你的应用服务部署在同一个集群内。利用服务发现和内部网络，减少延迟，并统一管理资源配额和弹性伸缩。

6.2 数据生命周期管理与备份策略

向量数据库并非“只进不出”，也需要考虑数据管理。

1. 数据更新与删除：

更新：使用upsert操作，指定点的ID。如果ID存在，则更新该点的向量和payload；如果不存在，则插入。
删除：可以按点ID删除，也可以使用过滤条件批量删除。例如，删除所有year < 1990的电影。
```
client.delete( collection_name=“movies”, points_selector=models.FilterSelector( filter=models.Filter( must=[models.FieldCondition(key=“year”, range=models.Range(lt=1990))] ) ), )
```
注意：删除操作在Qdrant中是“标记删除”。空间不会立即释放，会在后续的段合并过程中回收。对于大量删除，可能会暂时影响性能。

2. 集合快照与备份：这是生产环境的必备操作。Qdrant支持为整个集合创建快照，快照文件包含了该集合在某个时间点的完整数据。

创建快照：POST /collections/{collection_name}/snapshots
下载快照：GET /collections/{collection_name}/snapshots/{snapshot_name}
从快照恢复：PUT /collections/{collection_name}，在请求体中指定快照文件路径。

最佳备份策略：

定期全量快照：例如每天凌晨对关键集合创建快照，并将快照文件上传到对象存储（如S3、MinIO）。
点对点恢复测试：定期在测试环境中执行恢复演练，确保备份有效。
结合WAL：对于需要点-in-time恢复的场景，需要结合快照和Write-Ahead Log。Qdrant的RocksDB存储引擎本身提供了WAL机制，但更高级的备份方案可能需要定制化脚本。

6.3 安全与权限控制

开源版本Qdrant本身不提供内置的用户认证和权限控制（RBAC）。在生产环境暴露到公网时，必须在前端部署安全层。

1. API密钥与反向代理：最常见的方案是使用反向代理（如Nginx、Traefik、API Gateway）来保护Qdrant服务。

在反向代理层配置API密钥验证。每个客户端请求必须携带有效的API Key。
反向代理将验证后的请求转发给后端的Qdrant实例。
可以进一步在反向代理配置IP白名单、速率限制等。

2. 网络隔离：

将Qdrant实例部署在私有子网内，不分配公网IP。
只有应用服务器或内部的API网关可以通过安全组规则访问Qdrant的端口（6333， 6334）。
这是云环境下的最佳实践，从网络层面杜绝外部直接攻击。

3. Qdrant Cloud的托管安全：如果使用Qdrant Cloud，这些安全问题大部分由平台负责。你只需要保管好云控制台的访问凭证和API密钥即可。平台会提供TLS加密传输、VPC对等连接、审计日志等企业级安全功能。

4. 数据传输加密：确保客户端与Qdrant服务之间的通信使用HTTPS（对于REST API）或基于TLS的gRPC。在反向代理或负载均衡器上配置SSL证书是最简单的方式。

Qdrant向量数据库实战：从架构解析到生产部署