上线

本指南帮助你为生产环境准备你的应用。它提供了可执行的步骤，帮助你扩展应用、确保其可靠、能够承受负载，并为你的使用场景提供最佳的准确性。

🌐 This guide helps you prepare your application for production. It provides actionable steps to help you scale your application, ensure that it is reliable, can handle the load, and provide optimal accuracy for your use case.

查看我们的大规模工程指南，了解有关大规模工程的更多信息。

🌐 See our Engineering for Scale guide for more information about engineering at scale.

你需要索引吗？ #

🌐 Do you need indexes?

顺序扫描会导致明显更高的延迟和更低的吞吐量，同时保证100%准确性，并且不受限于内存。

🌐 Sequential scans will result in significantly higher latencies and lower throughput, guaranteeing 100% accuracy and not being RAM bound.

有几种情况你可能不需要索引：

🌐 There are a couple of cases where you might not need indexes:

• 你有一个小数据集，不需要把它扩展。
• 你不指望每秒会有大量向量搜索查询。
• 你需要保证100%准确。

在这些情况下，你不必创建索引，可以使用顺序扫描。这类工作负载不会受限于内存，也不需要额外资源，但会导致更高的延迟和较低的吞吐量。额外的 CPU 核心可能有助于提高每秒查询次数，但不会改善延迟。

🌐 You don't have to create indexes in these cases and can use sequential scans instead. This type of workload will not be RAM bound and will not require any additional resources but will result in higher latencies and lower throughput. Extra CPU cores may help to improve queries per second, but it will not help to improve latency.

另一方面，如果你需要扩展你的应用，你就需要创建索引。这会带来更低的延迟和更高的吞吐量，但需要额外的内存来利用 Postgres 缓存。此外，使用索引会导致准确性下降，因为你是在用近似（ANN）搜索替代精确（KNN）搜索。

🌐 On the other hand, if you need to scale your application, you will need to create indexes. This will result in lower latencies and higher throughput, but will require additional RAM to make use of Postgres Caching. Also, using indexes will result in lower accuracy, since you are replacing exact (KNN) search with approximate (ANN) search.

HNSW 和 IVFFlat 索引 #

🌐 HNSW vs IVFFlat indexes

pgvector 支持两种类型的索引：HNSW 和 IVFFlat。我们推荐使用 HNSW，因为它在 性能 和 应对数据变化的稳健性 方面表现更好。

HNSW，理解 ef_construction、ef_search 和 m#

🌐 HNSW, understanding ef_construction, ef_search, and m

索引构建参数：

🌐 Index build parameters:

• m 是在构建过程中为每个新元素创建的双向链接数量。较高的 m 适合高维度和/或对精度要求高的数据集。m 的合理取值在 2 到 100 之间。大多数使用场景的起始范围为 12-48（默认值为 16）。
• ef_construction 是最近邻动态列表的大小（在构建算法中使用）。更高的 ef_construction 会带来更好的索引质量和更高的准确率，但同时也会增加构建索引所需的时间。ef_construction 至少要为 2 * m（默认值是 64）。在某个点上，增加 ef_construction 并不会提高索引质量。当 ef_search=ef_construction 时，你可以测量准确率：如果准确率低于 0.9，那么还有改进的空间。

搜索参数：

🌐 Search parameters:

• ef_search 是最近邻动态列表的大小（在搜索时使用）。增加 ef_search 会提高准确性，但也会增加执行查询所需的时间（默认值是 40）。

IVFFlat，理解 probes 和 lists#

🌐 IVFFlat, understanding probes and lists

在 pgvector 中用于近似向量相似搜索的索引会将数据集划分为多个分区。这些分区的数量由 lists 常量定义。probes 控制在查询过程中会搜索多少个列表。

🌐 Indexes used for approximate vector similarity search in pgvector divides a dataset into partitions. The number of these partitions is defined by the lists constant. The probes controls how many lists are going to be searched during a query.

列表和值探针会直接影响准确性和每秒查询量（QPS）。

🌐 The values of lists and probes directly affect accuracy and queries per second (QPS).

• 更高的 lists 意味着索引构建会更慢，但你可以获得更好的 QPS 和准确性。
• 更高的 probes 意味着选择查询会更慢，但你可以获得更好的准确性。
• lists 和 probes 不是独立的。更高的 lists 意味着你必须使用更高的 probes 才能达到相同的准确率。

你可以在 pgvector 0.4.0 性能 博客文章中找到更多关于 lists 和 probes 常量如何影响准确性和 QPS 的例子。

🌐 You can find more examples of how lists and probes constants affect accuracy and QPS in pgvector 0.4.0 performance blog post.

下面的图表显示了 IVFFlat 列表数量如何影响准确性和每秒查询数。

🌐 The chart below shows how the IVFFlat lists count affects accuracy and queries-per-second.

使用索引时的性能小贴士 #

🌐 Performance tips when using indexes

首先，这里有一些通用的小贴士，你可以挑着用：

🌐 First, a few generic tips which you can pick and choose from:

1. Supabase 托管平台会根据你的计算附加组件自动优化 Postgres 配置。但如果你自托管，可以考虑根据 RAM 和 CPU 核心 调整你的 Postgres 配置。更多细节请看 优化示例。
2. 如果你的向量是归一化的（像 text-embedding-ada-002），建议使用 inner-product 而不是 L2 或 Cosine 距离。如果嵌入没有归一化，使用 Cosine 距离在索引中应该能得到最好的效果。
3. 预热你的数据库。 在过渡到生产环境或运行基准测试之前，先实现预热技巧。
   • 使用 pg_prewarm 将索引加载到 RAM select pg_prewarm('vecs.docs_vec_idx'); 中。这有助于避免冷缓存问题。
   • 在每次基准测试或生产环境之前，先执行 10,000 到 50,000 次“热身”查询。这有助于更高效地使用缓存和缓冲区。
4. 确定你的工作负载。 微调 m 和 ef_construction 或 lists 常量以加速 pgvector 索引的查询（以牺牲构建速度为代价）。例如，对于包含 1,000,000 个 OpenAI 嵌入的基准测试，我们将 m 和 ef_construction 设置为 32 和 80，结果 QPS 比 24 和 56 的数值高出了 35%。
5. 对你自己的特定工作负载进行基准测试。 在缓存预热期间进行测试有助于评估索引构建参数的最佳值，在准确性和每秒查询数（QPS）之间取得平衡。

投入生产 #

🌐 Going into production

1. 决定是否要使用索引。如果不使用索引，你可以跳过本指南的其余部分。
2. 在准备阶段多配一些内存。你可以在步骤 5 中缩减，但最好一开始就用更大的容量，以获得最佳的内存效果。（如果你使用 Supabase，我们建议至少用 8XL。）
3. 将你的数据上传到数据库。如果你使用vecs库，它会自动用默认参数生成索引。
4. 使用随机生成的查询运行基准测试并观察结果。同样，你可以使用 vecs 库配合 ann-benchmarks 工具。用索引构建参数的默认值来做，之后你可以调整它们以获得最佳结果。
5. 监控内存使用情况，并把它记下来。以后你可能会想用一个计算插件，其内存大小和当时使用的一样（包括实际内存使用和用于缓存及缓冲的内存）。
6. 把你的计算附加组件缩小到当前使用相同内存的那一个。
7. 重复步骤3将数据加载到RAM中。你应该会看到后续运行的QPS增加，当不再增加时就可以停止了。
8. 使用真实查询运行基准测试并观察结果。你也可以用 vecs 库配合 ann-benchmarks 工具来做。调整 HNSW 的 ef_search 或 IVFFlat 的 probes，直到准确率和 QPS 都达到你的要求。
9. 如果你想要更高的 QPS，你可以增加 HNSW 的 m 和 ef_construction，或者 IVFFlat 的 lists 参数（可以考虑从 IVF 切换到 HNSW）。你需要用更高的 m 和 ef_construction 值重建索引，并重复步骤 6-7 来找到 m、ef_construction 和 ef_search 常量的最佳组合，以实现最佳的 QPS 和准确率。更高的 m、ef_construction 意味着索引构建会更慢，但你能获得更好的 QPS 和准确率。更高的 ef_search 意味着选择查询会更慢，但你可以获得更高的准确率。

有用的链接 #

🌐 Useful links

别忘了查看通用的 生产清单，确保你的项目安全、高效，并且能够持续为用户提供服务。

🌐 Don't forget to check out the general Production Checklist to ensure your project is secure, performant, and will remain available for your users.

你可以看看我们的选择计算附加组件指南，以大致了解你的工作负载可能需要多少计算资源。

🌐 You can look at our Choosing Compute Add-on guide to get a basic understanding of how much compute you might need for your workload.

或者看看我们的pgvector 0.5.0 性能和pgvector 0.4.0 性能博客文章，了解 pgvector 的能力，以及如何使用上述技巧来获得最佳效果。

🌐 Or take a look at our pgvector 0.5.0 performance and pgvector 0.4.0 performance blog posts to see what pgvector is capable of and how the above technique can be used to achieve the best results.

下面的图表绘制了每秒请求数与计算规模的关系。

🌐 The chart below plots requests-per-second against compute size.