Qdrant 概览

欢迎！

无论您是刚刚接触 Qdrant 开源版还是云服务版，这份简短的入门指南都将帮助您了解该平台的核心概览。强烈建议您在开始使用 Qdrant 开发之前阅读此概览！

检索流程

向量搜索是一种革命性的信息检索技术，它超越了简单的关键词匹配，能够基于语义含义查找数据。它始于嵌入模型（embedding models），将非结构化数据（文本、图像、音频）转换为稠密向量嵌入（dense vector embeddings）——即代表数据概念本质的定长数字列表。这些向量被映射到一个高维向量空间（vector space）中，含义相似的项目会被放置在空间中靠近的位置。这种空间组织方式使得搜索“气候变化”能够检索到关于“全球变暖”的文档，即便两者的词汇完全不同。

Workflow Overview

虽然稠密向量在捕捉上下文方面表现出色，但有时可能会遗漏特定的技术术语或唯一标识符。为了弥补这一差距，Qdrant 还利用稀疏向量（sparse vectors）来捕捉特定关键词的精确词汇匹配。更多信息请参阅本指南。

从非结构化数据生成嵌入的过程称为推理（inference）。在 Qdrant Cloud 上，您可以使用云推理（Cloud Inference）让 Qdrant 在服务器端生成嵌入。或者，您也可以使用类似 FastEmbed 的库在客户端生成嵌入。

搜索过程本身围绕 Top-K 检索概念展开。当用户提交请求时，请求会立即转换为查询向量（query vector）。引擎随后计算该查询向量与文档向量之间的相似度，并返回“Top-K”个最接近的匹配项，其中 K 是用户定义的代表所需结果数量的数字。这允许开发者微调搜索广度与答案精确度之间的平衡。

Retrieval Process

为了提供最强大的搜索体验，Qdrant 支持结合语义搜索与词汇搜索的混合检索（Hybrid Retrieval），您可以在此处了解更多信息。

架构

Qdrant 采用客户端-服务器架构，为 Python、JavaScript/TypeScript、Rust、Go、.NET 和 Java 提供官方客户端库。此外，Qdrant 还通过 HTTP 和 gRPC 接口提供服务，便于与几乎任何编程语言集成。

数据结构

Qdrant 集合（Collections）专为横向和纵向扩展而设计。您可以从下方的链接中查看图中所示的详细信息。

部署

Qdrant 支持多种部署模型，以满足不同的基础设施和运营需求。选择取决于您的安全约束和运营模式：Qdrant 管理的基础设施（托管云）、与您共享集群的责任共担模式（混合云），或完全自主拥有的模式（私有云或开源版）。

特征	优势	开源版	托管版	混合云	私有云
部署	根据您的基础设施需求，选择如何以及在何处部署您的 Qdrant 向量数据库。	✅	✅	✅	✅
高可用性	自动故障转移和复制，确保您的向量搜索始终可用。	❌	✅	✅	✅
零停机升级	利用复制机制升级您的 Qdrant 数据库，无需中断服务。	❌	✅	✅	✅
监控与告警	内置监控和告警功能，实时观测集群的健康状况和性能。	❌	✅	✅	❌
集中管理 UI	统一控制台，用于创建、配置和管理您所有的 Qdrant 数据库集群。	❌	✅	✅	❌
横向与纵向扩展	支持自动分片重新平衡和重分片，轻松实现集群的扩容、缩容或扩展。	❌	✅	✅	✅
备份与灾难恢复	自动备份和恢复功能，确保数据持久性和平稳恢复。	❌	✅	✅	✅
数据隐私与控制	将所有用户数据保留在您自己的基础设施和网络内，第三方无法访问。	✅	❌	✅	✅
多云与本地部署	根据您的需求，部署在 AWS、GCP、Azure、本地环境或边缘节点上。	✅	❌	✅	✅
企业支持	为生产环境部署提供 Qdrant 企业支持服务。	❌	✅	✅	✅
无需管理基础设施	Qdrant 全面管理您的基础设施，让您可以专注于应用程序开发。	❌	✅	❌	❌

扩展考量

当您开始进行 POC（概念验证）或业余项目时，Qdrant 的默认配置已经足够合理。然而，当过渡到生产环境并面对数据量增加和高并发用户时，您对高可用性、延迟或吞吐量的期望将会改变。如果您预见需要扩展服务，则应从一开始就建立能够应对这些挑战的系统。以下是一些您应该注意的常见场景，特别是如果您刚接触 Qdrant、预计业务将快速增长，并希望使系统能够经受住未来的考验。

内存需求

内存是扩展向量搜索时的关键资源。默认情况下，Qdrant 为了追求极致的搜索性能，将向量存储在 RAM 中，但当集合增长到数百万个向量时，将所有数据保存在内存中会变得非常昂贵。Qdrant 允许您通过将数据卸载到磁盘来控制内存使用，您可以随时启用该机制，即使是在现有集合上。

如果将向量存储在磁盘上，频繁访问的向量会自然留在缓存中，而其他向量仅在需要时从磁盘读取。
如果您将 HNSW 索引存储在磁盘上，图遍历可能会涉及 I/O 操作。

仅在内存严重受限时才将两者都放在磁盘上，并确保您拥有高速 NVMe 存储。

筛选

单纯的向量搜索可以为您的用户提供不错的搜索体验；然而，语义相似度往往不是您唯一需要考虑的因素。嵌入无法捕捉价格等属性，通常必须对特定的有效载荷（payload）属性应用过滤器。为了使这种过滤有效，您需要了解一些特定的 Qdrant 机制，包括有效载荷索引（payload indexes）。

有效载荷索引

有效载荷索引是一种辅助数据结构，能够对特定的有效载荷属性进行有效的过滤。这对于关系型数据库用户来说是一个熟悉的概念，即在经常用于过滤的列上创建索引。同样，在 Qdrant 中，您也应该为用于过滤的字段创建有效载荷索引。

有效载荷索引的一个独特之处在于它扩展了 HNSW 图，允许在语义搜索阶段应用过滤标准。这意味着它是单次路径图遍历，而不是预过滤或后过滤（两者都有各自的缺点）。

由于有效载荷索引扩展了 HNSW 图，因此在索引数据之前创建索引会更有效，因为优化器只需要构建一次图。然而，在某些情况下，您可能已经拥有一个包含大量向量的集合，并意识到需要按特定属性进行过滤。在这种情况下，您仍然可以创建有效载荷索引，但它不会立即影响 HNSW 图。

ACORN 是一种额外的机制，如果您的搜索操作中包含多个高基数（high cardinality）过滤器，它可以提高搜索准确性。

扩展

纵向扩展有天然的局限性——最终您会达到可用硬件的最大容量，且单节点部署缺乏冗余。通过分片（sharding）、复制（replication）和段配置（segment configuration）选项来优化扩展。

分片

Qdrant 使用分片将集合分布在多个节点上，每个分片都是独立的点存储区。通常建议从 12 个分片开始，这为您提供了灵活性，可以在不进行重分片的情况下从 1 个节点扩展到 2、3、6 或 12 个节点。但是，这种方法在小型集群上可能会限制吞吐量，因为每个节点需要管理多个分片。

为了获得最佳吞吐量，请将 shard_number 设置为与您的节点数相等（点击此处了解更多）。如果您想更好地控制分片，Qdrant 支持自定义分片。

复制

复制因子决定了每个分片的副本数量。对于生产系统，强烈建议复制因子至少为 2。

段配置

每个分片将数据存储在多个段（segments）中。一个段存储分片中部分点的所有数据结构。段越少，段体积越大，搜索吞吐量越好，因为更大的 HNSW 索引所需的比较次数越少。然而，较大的段构建和重建耗时更长，会降低写入和优化速度。段越多，索引速度越快，但搜索性能较低，因为查询需要扫描更多的段。点击阅读更多关于段配置的内容。

安全

某些集合级别的操作可能会降低 Qdrant 集群的性能。Qdrant 的严格模式（strict mode）通过多种控制手段防止低效使用模式：它可以阻止对未索引有效载荷字段的过滤和更新，限制查询结果大小和超时时长，限制过滤条件的复杂度和数量，设置有效载荷索引数量上限，约束批量 upsert 大小，强制执行集合存储限制（针对向量、有效载荷和点数），并对读写操作实施速率限制，以防止系统过载。

开源版本默认不强制执行任何限制，但请根据应用程序需求考虑启用和配置严格模式设置。否则，某些 API 调用可能会因以非优化方式使用 Qdrant 而影响集群性能。

寻求帮助

如果您是 Qdrant 的新手，请从免费的基础课程（Essentials Course）开始，该课程涵盖了核心概念和最佳实践。有关问题、故障排除和社区支持，请加入Discord 社区——这是从 Qdrant 用户和核心团队获得帮助的最佳场所。付费客户可以通过 Qdrant Cloud 控制台访问支持门户（Support Portal），以获得直接的技术支持和优先响应服务。