登录 免费开始

Qdrant 概述

欢迎！

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

检索流程

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

Workflow Overview

虽然稠密向量擅长捕捉上下文，但有时可能会遗漏特定的技术术语或唯一标识符。为了弥补这一差距，Qdrant 还利用稀疏向量（sparse vectors）来捕捉特定关键字的精确词法匹配（lexical matches）。详情请参阅此指南。

从非结构化数据生成嵌入的过程称为推理（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 organizes data around collections - named sets of points that you search within. Each point consists of a vector (numerical representation of your data) and optional payload metadata. Points are identified by 64-bit integers or UUIDs. Collections support multiple vector types per point, dense or sparse, and named vectors are used for storing different embedding types in a single point. When creating a collection, you specify vector dimensionality and distance metric for each of the named vectors you want to store. The HNSW index enables fast similarity search by building a graph structure that efficiently traverses similar vectors. Payload indexes can be created on specific fields to enable filtering during search, extending the HNSW graph for combined vector similarity and metadata filtering in a single pass. Data is organized into segments - storage units containing vectors and indexes - which are automatically optimized in the background. For distributed deployments, collections are split into shards, each containing its own segments. Strict mode prevents performance issues by enforcing constraints like blocking queries on unindexed fields.

Qdrant 集合专为横向和纵向扩展而设计。您可以通过下方的链接了解图表中的详细信息。

部署

Qdrant 支持多种部署模型，以满足不同的基础设施和运营需求。合适的选择取决于您的安全限制和运营模型：Qdrant 管理的基础设施（托管云）、与您自己的集群共同承担责任（混合云），或完全所有权与独立性（私有云 或 开源版）。

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

扩展考量

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

内存需求

内存是扩展向量搜索时的关键资源。默认情况下，Qdrant 将向量存储在 RAM 中以获得最佳搜索性能，但随着集合增长到数百万个向量，将所有内容保留在内存中会变得成本高昂。Qdrant 允许您通过将数据卸载到磁盘来控制内存使用，即使在现有集合上，您也可以随时启用该机制。

  • 如果将向量存储在磁盘上，频繁访问的向量会自动保留在缓存中，而其他向量仅在需要时才从磁盘读取。
  • 如果将 HNSW 索引存储在磁盘上，图形遍历可能需要 IO 操作。

仅在 RAM 严重受限时才将两者都放入磁盘，并确保拥有快速的 NVMe 存储。

筛选

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

载荷索引

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

载荷索引的一个独特之处在于它扩展了 HNSW 图，允许在语义搜索阶段应用过滤条件。这意味着它是单次遍历图形，而不是预过滤或后过滤，这两种过滤方式都有各自的缺陷。

HNSW Graph with Filtering

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

ACORN 是一种额外的机制，如果您的搜索操作中存在多个高基数过滤器，它可以提高搜索精度。

扩展

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

分片

Qdrant 使用分片将集合分散到多个节点上，其中每个分片都是独立的点存储区。通常建议从 12 个分片开始，这提供了从 1 个节点扩展到 2、3、6 或 12 个节点的灵活性，而无需重分片。然而，这种方法可能会限制小集群的吞吐量，因为每个节点需要管理多个分片。

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

复制

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

Choosing a Replication Factor: RF=1 causes operational problems: node restarts make parts of your collection unavailable, and data loss is permanent without backups. Use RF=1 only for non-production workloads, development environments, or when data can be easily regenerated. RF=2 provides the optimal balance for most production deployments: data remains available during single-node failures, read operations benefit from load balancing, and rolling updates work without downtime. RF>2 is a throughput optimization for read-heavy workloads. More replicas distribute read operations across more nodes, increasing cluster throughput. The cost is proportionally increased storage and higher write overhead.

段配置

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

安全

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

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

获取帮助

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

此页面有用吗？

感谢您的反馈！🙏

很遗憾听到这个消息。😔 您可以在 GitHub 上编辑此页面，或创建一个 GitHub Issue。

本页内容