在生产环境中运行搜索需要什么？
一家中型电子商务公司启动了一个向量搜索试点项目，以改善产品发现。在测试过程中，一切运行顺利。但在生产环境中，他们的查询开始间歇性失败：内存错误、磁盘 I/O 峰值和搜索延迟意外出现。
结果发现，团队没有调整默认配置设置，也没有为预写日志保留专用路径。他们的向量索引太大，无法完全放入内存，经常溢出到磁盘，导致速度变慢。
诸如此类的问题凸显了默认配置在生产负载下可能会出现灾难性的失败。
在生产环境中运行向量搜索，无论您的托管环境如何，都关乎确保可靠性、性能和弹性。管理内存限制、配置数据分发、索引选择和备份至关重要，无论您是在裸机、虚拟机还是编排容器上运行。
本指南解决了生产中最常见的问题
无论您是计划首次部署还是希望改进现有系统，本指南都将帮助您构建弹性且高性能的向量搜索基础设施。
本文将帮助您在生产环境中成功部署和维护向量搜索系统。
借鉴我们用户的实际经验，您将发现实用的技术来避免许多生产部署中常见的陷阱。
目录
1. 如何获得最佳搜索性能？
| “添加更多向量后，搜索变得超级慢。” |
❓ 用例：一家客户支持初创公司看到了间歇性的延迟峰值。他们的索引超出了可用内存，因此频繁地从磁盘获取数据。升级他们的内存有所帮助，而对所有数据进行量化则带来了真正的改变。用户所需要做的只是管理他们的内存负载，减少内存中的向量并将其余的卸载到磁盘上。
如果发生这种情况，那么您的索引设置很可能没有优化，因此系统会更频繁地访问磁盘，从而增加延迟。
确保您的热数据集适合内存，以实现低延迟查询。
如果不行，那么您将不得不将数据“on_disk”卸载。如果启用此参数，Qdrant 会将您最常访问的向量加载到内存中进行缓存，其余部分则内存映射到磁盘上。
这确保了查询期间最小的磁盘访问，显著降低了延迟并提高了整体性能。通过监控查询模式和使用指标，您可以识别哪些数据子集值得专用内存存储，仅将磁盘访问保留给较冷、不常查询的向量。
| 阅读更多： 存储文档 |
索引重要元数据以避免昂贵的查询
✅ 您应该始终为您在过滤器或排序中使用的所有字段创建 payload 索引。
许多用户配置复杂的过滤器，但可能没有意识到需要创建相应的 payload 索引。
结果是，每个查询都会扫描数千个向量及其原始 payload，然后丢弃大部分未通过过滤条件的向量。这导致 CPU 使用率飙升和响应时间延长，尤其是在高流量负载下。
在检索数千个向量后进行过滤可能会非常昂贵。如果您不使用查询进行过滤，Qdrant 将评估超出您所需数量的向量。这将使整个系统变慢并消耗更多资源。因此，我们开发了自己的 HNSW 版本——可过滤向量索引。
与其他一些引擎不同，Qdrant 允许您根据您的用例选择要索引的字段，而不是默认情况下为每个字段创建索引。
注意：不要忘记使用正确的payload 索引类型。如果存在数值，则必须使用数值索引。如果您用字符串（“123”）表示数字，数值索引将不起作用。
| 阅读更多： 过滤文档 |
不要忘记调整 HNSW 搜索参数
| “我们的结果不够相关，或者计算时间太长。” |
有时用户没有正确平衡 HNSW 搜索参数。将 HNSW 的ef参数设置为一个非常低的值，例如零，将导致极快的响应（大约一毫秒），但结果质量会很差。
❓ 用例：一位客户在其庞大的近 8 亿向量数据集中运行高级相似性搜索。最初，他们发现查询需要 10 到 20 秒，尤其是在结合多个过滤器和元数据字段时。
✅ 如何在保持准确性的同时保持快速？答案是优化。
图 1： Qdrant 高度可配置。您可以针对速度、精度或资源使用进行配置。
通过调整 ef，团队发现了一个最佳点，可以在亚秒级响应的同时保持准确性。他们还微调了数据库的其他方面，例如将量化向量放入内存中，同时将原始未压缩向量卸载到磁盘上。
此策略平衡了内存使用和性能：只有紧凑的向量需要存储在内存中以进行快速查找，而较大的向量则保留在磁盘上，直到需要时才使用。
使用量化策略压缩数据
| “我们的大数据集使用了太多内存。” |
许多用户跳过量化，导致他们的索引消耗过多的 RAM 并产生不稳定的性能。有些用户犹豫不决地妥协精度，但这并非总是如此。
如果您的工作负载可以容忍嵌入精度适度下降，数据压缩提供了一种强大的方法来缩小向量大小并大幅降低内存使用。通过将高维浮点值转换为低位格式（例如 8 位标量甚至单比特表示），您可以将更多的向量保留在 RAM 中，同时减少磁盘占用。
✅ 如果您的用例允许，您应该评估并应用量化。量化可以显著提高性能并降低存储成本。
这不仅可以加快大规模数据集的查询吞吐量，还可以降低硬件成本和存储开销。虽然标量量化是一种中等压缩替代方案，但二进制量化更为剧烈，因此请务必彻底测试您对每种方法精度要求。
使用量化时，您可以只在内存中存储压缩后的向量，而将原始浮点版本留在磁盘上以供参考。这种方法大大降低了 RAM 消耗——因为量化向量占用空间少得多——但仍然允许您在需要时检索全精度向量，以进行下游任务，如重新排序。
旁注：当 Linux 内核支持且您有
on_disk向量时，您始终可以启用async_io评分器。
| 阅读更多： 量化文档 |
2. 如何摄取和索引大量数据？
| “当我尝试导入一个巨大的数据集时，一切都停滞不前。” |
❓ 用例：一个金融科技团队摄取了 5 亿条交易记录。性能最初很好，但在一个小时内就崩溃了。
他们启用了 HNSW 索引，因此每次插入都会触发完整的索引更新。不幸的是，他们的 CPU 使用率飙升，其他服务超时。
✅ 在逐个案例的基础上，我们建议在大型上传期间禁用构建 HNSW 索引，以提高摄取和索引速度。
所有记录插入后，您可以一次性重建索引。考虑使用专门的摄取管道，该管道批量写入并在低流量时段安排索引。如果您没有这样的低流量时段，您可以调整indexing_threshold以在接收更新而不触发索引和保持集合索引之间找到平衡。
| 阅读更多： 配置向量索引 |
缓解索引瓶颈的其他解决方案
✅ 增加索引线程： 如果您使用超过 16 核，请考虑明确增加索引线程数。
默认情况下，Qdrant 最多使用 16 个线程进行索引，但如果您发现索引期间 CPU 未充分利用，可以增加此数字。
✅ 使用批处理： 增加并发进程数。运行 50-60 个进程可以显著提高上传性能。只使用一两个进程无法发挥真正的性能潜力。
耐心等待索引： 上传大型数据集后，有一个等待期，直到索引完成。这很正常，可能需要时间，具体取决于数据集大小。
| 阅读更多： 配置文档 |
当索引滞后于数据摄取时
在渐进式流式上传和大型批量上传之后，索引可能会暂时滞后于数据摄取。
默认情况下，搜索会包含未索引的数据。然而，大量未索引的点可能会由于全扫描而显著减慢搜索速度，从而可能导致高搜索延迟、超时和应用程序故障。
如果最大索引点数始终保持较低水平，则这可能不是问题。如果您预计存在许多未索引点的时期，则应采取措施防止生产中搜索中断。
一种选择是在搜索请求中设置 indexed_only=true。这将通过仅考虑索引数据来确保快速搜索，但会牺牲最终一致性（新数据仅在索引后才可搜索）。
或者，您可以在低流量时段执行批量向量上传，以便在流量增加之前完成索引。
索引点数持续增加表明存在问题。潜在的解决方案包括：增加硬件资源、优化索引（例如，更小的段、HNSW 调整）或减少数据更改量。
| 阅读更多： 索引文档 |
如何安排元数据和 Schema 以实现一致性
| “我的过滤器每次都不能以相同的方式工作。” |
在某些情况下，payload 模式在数据管道之间不一致，因此某些字段类型不匹配或完全缺失。
❓ 用例：一家医疗保健公司发现某些管道插入字符串，而其他管道插入整数。过滤器默默地失效或返回不一致的结果，这表明统一的 payload 模式未到位。
当您的摄取管道中的 payload 字段类型不一致时，过滤器可能会以不可预测的方式失效。
例如，某些服务可能会将“status”字段写入为字符串（“active”），而其他服务则将其插入为数字代码（1）。结果，预期统一数据的查询可能会默默地失败、跳过重要记录或产生不正确的排序/过滤。
✅ 确保您的 payload 模式始终一致执行，无论是通过严格的类型检查还是明确定义的数据契约，是防止这种不匹配的最佳方法。记录摄取期间的任何模式冲突也很重要，这使您有机会在它们降低查询性能和结果质量之前修复错误。
| 阅读更多： Payload 文档 |
决定如何设置多租户集合
❓ 用例：在实施向量数据库时，医疗保健组织需要确保用户数据之间的隔离。我们的客户需要确保当他们过滤查询以仅显示特定患者的文档时，查询结果中不会出现其他患者的文档。
✅ 如果可能，您几乎应该总是将租户整合到一个集合中，并按租户进行标记。
PUT /collections/{collection_name}/index
{
"field_name": "group_id",
"field_schema": {
"type": "keyword",
"is_tenant": true
}
}
图：对于多租户设置，为每个租户启动一个新集合可能会导致开销膨胀。多租户设计——使用带有租户字段的单个集合——更有效地利用资源。
不要忘记：您始终可以在 Qdrant Cloud 中（或在 OSS 中使用 JWT）创建API 密钥，通过 payload 约束强制执行某个过滤器。
| 阅读更多： 多租户文档 |
3. 扩展数据库和优化资源的最佳方法是什么？
| “我的 Qdrant 集群需要多少节点、CPU、RAM 和存储？” |
这取决于情况。如果您刚开始，我们网站上准备了一个工具来帮助您解决这个问题。欲了解更多信息，请查看容量规划文档。
✅ 使用容量计算器或性能测试来确保节点规格（RAM/CPU）与您的工作负载匹配。
高估会浪费资源，而低估会导致查询缓慢或内存不足错误。通过有条不紊地测试实际工作负载，您可以自信地将硬件规格与您的目标摄取率、查询量和数据集大小相匹配。
为生产中的高可用性场景做准备
✅ 使用至少 3 个节点以确保故障转移并降低停机风险。
三节点设置提供了容错的基线：如果一个节点离线，其余两个节点可以继续提供查询并保持数据一致性的仲裁。这可以防止硬件故障、滚动更新和网络中断。少于三个节点会使您容易受到单点故障的影响，从而可能导致整个集群脱机。
我们遵循 Raft 协议，所以请查看文档并了解为什么这很重要。
✅ 将复制因子设置为至少 2 以容忍节点故障而不会丢失可用性。
PUT /collections/{collection_name}
{
"vectors": {
"size": 300,
"distance": "Cosine"
},
"shard_number": 6,
"replication_factor": 2
}
复制确保每份数据都存储在多个节点上。如果一个节点发生故障，另一个副本可以接管以提供读写服务。这可以防止数据丢失，并为关键应用程序维持不间断的服务。复制因子为 2 或更高对于生产工作负载尤为重要，因为在生产工作负载中，正常运行时间和可靠性是不可协商的。
✅ 将生产环境与开发/测试环境隔离——使用独立的集群以避免“吵闹的邻居”问题。
开发和测试环境通常运行实验构建、测试或模拟，这些可能会不可预测地增加资源使用。将它们与生产环境并行运行会降低性能和稳定性，影响真实用户。通过将生产托管在专用集群上，您可以保护关键工作负载免受开发引起的减速影响，并确保更一致、更可靠的性能。
处理不平衡或过载的节点
| “我的一个节点比其他节点承担了更多的任务。” |
❓ 用例：一家 SaaS 平台新增了数百名客户。突然，延迟飙升，因为一个节点承担了 5 倍的负载。一个特定的分片方案将某些“热”数据引导到单个分片。
很可能用户在一个节点上拥有多个分片，这些分片最终处理了大部分流量，而其他节点则利用率不足。
在这种情况下，您应该根据节点数量和预期 RPS 选择正确的分片数量。
您需要实施与实际使用模式相符的分片策略。首先，将您的分片分布到所有可用节点上。这将有助于更有效地平衡负载。重新分布分片后，运行性能测试以查看其对系统性能的影响。然后添加副本并再次测试以查看性能如何变化。
您的分片策略还取决于您有多少个集合。单个集合更容易平衡，因为要移动/平衡的东西更少。此外，单个集合的开销/编排也最少。
如何分片？
适当的分片会考虑数据分布和查询模式。默认情况下，如果查询总是跨越整个数据集，分片会被随机化以实现均匀分布。如果某些租户或地理区域流量密集，您可能会按集群、按 payload（租户 ID）或自定义分片分布进行分区。
| 阅读更多： 分片文档 |
通过扩展或缩减来管理您的成本
有些团队为了应对白天高峰而扩容，然后在夜间缩容以节省资源。如果您这样做，请确保数据被适当地分片和复制，这样扩容和缩容就不会导致服务降级。
如果您使用 Qdrant Cloud，您还可以使用复制因子来完成此操作，尽管这可能被认为有点投机取巧。
如果您有 3 个节点，只有 1 个分片，复制因子为 6。它将为该分片创建 3 个副本（每个节点一个），因为它不能托管更多。如果您在高峰期再添加 3 个节点，它将自动将该分片再复制 3 次，以尝试匹配因子 6。
如果您再次缩减，多余的副本将被删除。
✅ 在扩容集群后重新分片集合以重新平衡数据并避免内存不足问题。
当您向集群添加节点时，现有副本会与新分片重新平衡，但数量是固定的——这可能无法充分利用新硬件。结果，原始节点仍然过载，而新节点则大部分闲置。通过在扩容后重新分片集合，您可以将数据均匀分布到整个集群中，防止热点导致过载节点出现内存不足 (OOM) 情况。
如果新节点加入后仍然为空，则会浪费资源。如果离开的节点留下未迁移的数据，则存在部分覆盖甚至数据丢失的风险。
注意：这仅适用于 Qdrant Cloud 以及混合云和私有云，而不适用于自托管。
如何预测和测试集群性能
| “我直到为时已晚才发现有问题。” |
此类问题往往发生在用户不监控资源使用、搜索性能或安全性时。在用户投诉之前，关键故障一直未被发现。
✅ 在预期的流量条件下运行负载测试，以在上线前识别瓶颈。
您需要制定一个计划，使用真实数据进行负载测试。理想情况下，您应该使用生产流量或与您的实际工作负载密切相关的历史数据进行测试。这比随机生成的测试数据能提供更准确的结果，因为它能更好地代表真实世界的使用模式和数据分布。
设计您的负载测试，以逐渐增加流量，直到达到或超过您预期的生产负载。例如，如果您预计生产中每秒 1000 个请求 (RPS)，请逐步扩大测试以达到此阈值，同时监控延迟。响应将分别显示服务器计时，以便进行精细监控。
您应该在重启后测试系统性能，以了解冷启动行为。重启后的初始查询可能会显著变慢，因为缓存需要重建。例如，一个查询最初可能需要 50-60 秒，但在后续运行中只需 0.5 秒。
请记住，冷启动和查询行为取决于数据集，这就是为什么您应该建立自己的基线和预期。
| 阅读更多： 分布式部署文档 |
如何设计您的系统以防范故障
| “一个节点崩溃了，我们的整个集群都瘫痪了。” |
不幸的是，您没有为故障转移或混沌测试做计划，因此单点故障导致了生产中断。您应该通过冗余存储数据、测试故障转移和运行混沌实验来为硬件或节点崩溃做计划。
✅ 定期测试故障以揭示您的系统如何恢复。
高并发和大量内存占用可以更快地暴露配置错误，因此定期模拟故障可以揭示您的系统如何恢复。
- 优雅的节点关闭：排空查询，通过负载均衡器重新分配分片所有权。
- 冗余数据路径：将数据存储在多个卷或多个位置。
- 负载测试：生成高并发或大量查询以模拟真实的流量高峰模式。
设置遥测以实现早期检测
❓ 用例：一家医疗保健领域的客户使用来自其 Qdrant 部署的遥测数据来识别其开源实现的性能和扩展问题。遥测帮助他们监控搜索性能、RAM 利用效率和索引速度等指标。通过分析这些数据，他们可以努力减少查询响应时间并优化其系统配置。
✅ 启用遥测和监控，以便您可以跟踪延迟、吞吐量和优化统计信息。
遥测至关重要。您需要收集搜索延迟分布、CPU 使用率、磁盘吞吐量和内存消耗等指标。如果在索引构建期间内存使用率达到 90%，则明显表明您需要更多容量或更多节点。
构建仪表盘以监控 CPU 使用率、内存消耗、磁盘 I/O 和索引速度，帮助您发现资源瓶颈。否则，您只有在延迟飙升或日志充满错误时才会发现问题。
监控什么？
对于检索，关注 P99 延迟指标（最慢 1% 请求的响应时间），而不仅仅是平均延迟。这让您能更好地了解最坏情况下的性能。
对于硬件，在测试期间监控资源利用率。如果您没有看到预期的 CPU 利用率（例如，8 个 CPU 中只有 2 个在使用），则可能存在限制性能的配置问题。测试不同的配置以找到适合您特定工作负载的最佳设置。
图：如果您将监控、网络和日志指标抓取到自己的监控系统中，您可以使用我们的Grafana 仪表盘来可视化这些指标。
包含结合读写操作的测试，以模拟实际使用情况。例如，您可以配置一个读写比例为 80% 读取和 20% 写入的测试，以匹配您预期的生产工作负载。
通过遵循这些全面的负载测试实践，您将能够在系统上线前识别并解决潜在的瓶颈，确保更流畅的发布和更好的用户体验。
4. 使用数据库备份和快照确保灾难恢复
| “我试图恢复快照，现在一切都崩溃了。” |
❓ 用例：一家数字出版商遭遇了一场灾难性停机，并尝试从备份中恢复。他们直到部分数据丢失后才发现索引格式不匹配。另一家公司发现，在高峰流量期间，快照压缩占用 CPU，导致查询性能下降。
我们的一些用户不幸从未测试过备份，因此他们只在最糟糕的时候——恢复期间——才发现版本不匹配或部分/增量备份缺少数据。
完全备份还是快照恢复？
对于灾难恢复场景，您应该使用完全备份而不是快照。快照主要用于在集群之间移动数据，而备份旨在恢复集群的整个状态。
图： 从 Qdrant Cloud UI 配置集群备份
通过完整备份，您复制了整个数据集，包括索引和其他配置。这对于完整性而言非常棒，但可能成本高昂且耗时。完整快照恢复速度更快，但协调和恢复整个状态更复杂。
快照很方便，因为它们会创建集合的存档，或者更细粒度地，创建分片的存档，您可以下载并上传到另一个实例。如果您不想经历漫长的索引过程，请使用此功能。
✅ 设置定期快照或备份，并验证它们是否可以在需要时恢复。
无论您选择哪种方式，请务必测试恢复过程。有些团队直到真正的灾难发生时才意识到备份不完整或已损坏。
备份大型部署的最佳方法
如果您托管数十亿个向量，请将备份存储在节点外，存放在不同的数据中心或远程存储库中。此外，确认您的恢复带宽充足。如果恢复管道比本地磁盘慢，则所需时间将远远超出预期。
为避免恢复后版本不匹配，请务必保留索引配置，例如量化设置或 HNSW 参数。
5. 数据库正确管理的技巧
| “我的内存总是不足，服务也总是崩溃。” |
您很可能没有为数据库分配足够的 CPU 和内存，或者您没有将硬件资源与并发级别匹配。反过来，系统将在重负载下抖动或终止。
❓ 用例：一家中型电子商务公司试点了一个向量搜索解决方案，以改善产品发现。在测试中一切运行顺利，但一旦投入生产，内存错误、磁盘 I/O 峰值和查询延迟就堆积如山。
调查显示，他们没有调整默认配置，也没有为预写日志预留专用存储。由于 RAM 不足，他们的索引反复溢出到磁盘，损害了性能。
✅ 分配与您的数据量和并发需求相匹配的内存和 CPU
向量数据库需要仔细的资源管理。如果您不将内存、CPU 和磁盘设置与实际工作负载对齐，您将在峰值负载下遇到随机减速或部分故障。有时这表现为不可预测的延迟。其他时候，您会看到严重的资源争用使 CPU 或磁盘饱和。
注意：CPU 不足可能只会使速度变慢。内存不足可能会导致系统崩溃。
| 阅读更多： Qdrant 配置文档 |
安全与治理
用例：一家制造公司创建了一个依赖于许多组织组件的“超级聊天机器人”。该公司需要确保其应用程序组件之间的安全通信，并且数据传输至关重要。
✅ 在生产环境中启用 TLS/HTTPS 以进行加密流量。
启用 TLS/HTTPS 对于满足受监管行业的合规性要求至关重要。这种安全级别对于重视数据隐私和安全的公司（例如金融、政府和医疗保健领域的公司）至关重要，有助于克服潜在的安全团队异议。
您需要保护传输中的数据。为了在生产中为加密流量启用 TLS/HTTPS，您需要配置客户端和 Qdrant 数据库之间以及单个集群节点之间的安全通信。这涉及到实施传输层安全 (TLS) 证书来加密所有流量，防止未经授权的访问和数据拦截。
如果是自托管，您可以通过直接从配置中集成 TLS 来自行设置加密
service:
# Enable HTTPS for the REST and gRPC API
enable_tls: true
# TLS configuration.
# Required if either service.enable_tls or cluster.p2p.enable_tls is true.
tls:
# Server certificate chain file
cert: ./tls/cert.pem
# Server private key file
key: ./tls/key.pem
| 阅读更多： 安全文档 |
在生产中设置访问控制
用例：一家大型企业需要在其 Qdrant 数据库中实施访问控制，其中“团队 A 只能访问集合 A、B 和 C，但不能访问集合 D”。
✅ 设置基于角色的访问控制 (RBAC) 以限制用户或服务的操作。
用户可以通过在“角色详情”页面中邀请他们并点击“用户”选项卡来邀请他们并将其附加到特定角色。一旦接受，他们将被分配该角色的权限，以及基本角色。
图：Qdrant Cloud 数据库基于角色的访问控制界面
✅ 使用范围 API 密钥或 Auth 令牌以避免过度授权服务。
对于他们的私有云实现，他们手动设置了 JWT 令牌。他们将这些 JWT 令牌整合到他们现有的基于角色的访问控制系统中。他们使用从他们的 SSO 系统派生出的特定角色、职责和标签创建了令牌。这使他们能够在多个级别控制访问，包括多租户和通过元数据字段进行访问。
✅ 配置访问时遵循最小特权原则——只授予绝对必要的权限。
对于 Qdrant 托管云服务的用户，可以选择直接通过用户界面配置 RBAC，这会自动创建基于角色的访问控制，无需手动 JWT 配置。
| 阅读更多： 云 RBAC 文档 |
记住避免这些常见陷阱
❌ 不要忘记索引 payload 字段——不这样做会减慢您的搜索速度。
❌ 不要不进行复制就运行——单节点设置很脆弱。
❌ 不要为每个用户/客户创建集合——使用多租户。
❌ 不要将对延迟敏感的搜索与繁重的批处理作业并行运行——分离工作负载。
❌ 不要跳过量化——它能大大减少内存占用并加快搜索速度。
❌ 不要运行过时的 Qdrant 版本——定期更新。
结论
总而言之，生产环境中的向量搜索不与特定的云提供商或基础设施绑定。仔细配置、健壮的摄取/索引、智能扩展、彻底备份、强大的可观察性和安全性的这些核心原则普遍适用。通过遵循这些基本原则，无论您的硬件或服务运行在哪里，您都将为用户提供快速、可靠且可扩展的搜索。
