选择你的计算附加组件

你有两种方式来扩展你的向量工作负载：

🌐 You have two options for scaling your vector workload:

1. 增加你的数据库大小。这份指南会帮你为你的工作负载选择合适的大小。
2. 将你的工作负载分散到多个数据库上。你可以在《Engineering for Scale》(engineering-for-scale)中找到关于这种方法的更多细节。

维度 #

🌐 Dimensionality

在选择合适的计算插件时，你的嵌入向量维度是最重要的因素。一般来说，维度越低，性能越好。下面我们提供了一些常见嵌入维度的指南。对于每个基准测试，我们使用 Vecs 创建了一个集合，将嵌入上传到单个表中，并为嵌入列创建了 inner-product 距离度量的 IVFFlat 和 HNSW 索引。然后我们运行了一系列查询来衡量不同计算插件的性能：

🌐 The number of dimensions in your embeddings is the most important factor in choosing the right Compute Add-on. In general, the lower the dimensionality the better the performance. We've provided guidance for some of the more common embedding dimensions below. For each benchmark, we used Vecs to create a collection, upload the embeddings to a single table, and create both the IVFFlat and HNSW indexes for inner-product distance measure for the embedding column. We then ran a series of queries to measure the performance of different compute add-ons:

HNSW#

384 维 #

🌐 384 dimensions [#hnsw-384-dimensions]

这个基准测试使用了 dbpedia-entities-openai-1M 数据集，其中包含 1,000,000 个文本向量，已重新生成为 384 维度的向量。每个向量都是使用 gte-small 生成的。

🌐 This benchmark uses the dbpedia-entities-openai-1M dataset containing 1,000,000 embeddings of text, regenerated for 384 dimension embeddings. Each embedding is generated using gte-small.

960 维 #

🌐 960 dimensions [#hnsw-960-dimensions]

这个基准使用了 gist-960 数据集，其中包含 1,000,000 个图片的嵌入。每个嵌入有 960 个维度。

🌐 This benchmark uses the gist-960 dataset, which contains 1,000,000 embeddings of images. Each embedding is 960 dimensions.

1536 维度 #

🌐 1536 dimensions [#hnsw-1536-dimensions]

这个基准使用了 dbpedia-entities-openai-1M 数据集，其中包含 1,000,000 个文本嵌入。同时，对于计算附加组件 large 及以下，还使用了 224,482 个来自 维基百科文章 的嵌入。每个嵌入都是 1536 维，由 OpenAI Embeddings API 创建。

🌐 This benchmark uses the dbpedia-entities-openai-1M dataset, which contains 1,000,000 embeddings of text. And 224,482 embeddings from Wikipedia articles for compute add-ons large and below. Each embedding is 1536 dimensions created with the OpenAI Embeddings API.

下面的图表比较了在不同嵌入维度下，各种计算规模的 HNSW 每秒查询次数。

🌐 The chart below compares HNSW queries-per-second across compute sizes for different embedding dimensions.

体外受精平板 #

🌐 IVFFlat

384 维 #

🌐 384 dimensions [#ivfflat-384-dimensions]

这个基准测试使用了 dbpedia-entities-openai-1M 数据集，其中包含 1,000,000 个文本向量，已重新生成为 384 维度的向量。每个向量都是使用 gte-small 生成的。

🌐 This benchmark uses the dbpedia-entities-openai-1M dataset containing 1,000,000 embeddings of text, regenerated for 384 dimension embeddings. Each embedding is generated using gte-small.

960 维 #

🌐 960 dimensions [#ivfflat-960-dimensions]

这个基准使用了 gist-960 数据集，其中包含 1,000,000 个图片的嵌入。每个嵌入有 960 个维度。

🌐 This benchmark uses the gist-960 dataset, which contains 1,000,000 embeddings of images. Each embedding is 960 dimensions.

1536 维度 #

🌐 1536 dimensions [#ivfflat-1536-dimensions]

这个基准测试使用了 dbpedia-entities-openai-1M 数据集，其中包含 1,000,000 个文本向量。每个向量有 1536 个维度，是通过 OpenAI Embeddings API 创建的。

🌐 This benchmark uses the dbpedia-entities-openai-1M dataset, which contains 1,000,000 embeddings of text. Each embedding is 1536 dimensions created with the OpenAI Embeddings API.

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

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

性能小贴士 #

🌐 Performance tips

有很多方法可以提升你的 pgvector 性能。这里有一些小贴士：

🌐 There are various ways to improve your pgvector performance. Here are some tips:

预热你的数据库 #

🌐 Pre-warming your database

在投入生产之前，先执行几千个“热身”查询是很有用的。这有助于 RAM 的使用。这也可以帮助你确定为你的工作负载选择的计算规模是否合适。

🌐 It's useful to execute a few thousand “warm-up” queries before going into production. This helps help with RAM utilization. This can also help to determine that you've selected the right compute size for your workload.

微调索引参数 #

🌐 Fine-tune index parameters

你可以通过增加 m、ef_construction 或 lists 来提高每秒请求数。不过这里有个重要提醒：这些参数的值越高，构建索引所需的时间也越长。

🌐 You can increase the Requests per Second by increasing m and ef_construction or lists. This also has an important caveat: building the index takes longer with higher values for these parameters.

HNSWIVFFlat

下面的图表显示了 HNSW 构建参数 m 和 ef_construction 如何影响 dbpedia 数据集上的每秒请求数。

🌐 The chart below shows how the HNSW build parameters m and ef_construction affect requests-per-second on the dbpedia dataset.

在 Going to Production for AI applications 查看更多技巧和完整的逐步指南。

🌐 Check out more tips and the complete step-by-step guide in Going to Production for AI applications.

基准方法 #

🌐 Benchmark methodology

我们遵循ANN Benchmarks方法中概述的技术。一个 Python 测试运行器负责上传数据、创建索引以及执行查询。pgvector 引擎是使用 vecs 实现的，这是一个用于 pgvector 的 Python 客户端。

🌐 We follow techniques outlined in the ANN Benchmarks methodology. A Python test runner is responsible for uploading the data, creating the index, and running the queries. The pgvector engine is implemented using vecs, a Python client for pgvector.

上图显示了 vecs 基准测试的设置：一个 Python 测试运行器上传数据、构建索引，并对 pgvector 运行查询。

🌐 The diagram above shows the vecs benchmark setup: a Python test runner uploads data, builds the index, and runs queries against pgvector.

每次测试至少运行30-40分钟。测试包括在不同并发级别下进行的一系列实验，以测量引擎在不同负载类型下的性能。然后将结果取平均值。

🌐 Each test is run for a minimum of 30-40 minutes. They include a series of experiments executed at different concurrency levels to measure the engine's performance under different load types. The results are then averaged.

一般建议是，对于大多数工作负载，我们建议使用至少5的并发级别；对于高负载工作负载，则建议使用至少30的并发级别。

🌐 As a general recommendation, we suggest using a concurrency level of 5 or more for most workloads and 30 or more for high-load workloads.