类型和数量
在规划Pinecone部署时，了解向量的大致存储要求，以选择适当的Pod类型和数量非常重要。本页面将提供有关大小的指导，以帮助您做好规划。
与所有指南一样，这些考虑因素是一般性的，可能不适用于您的具体用例。我们建议您始终测试您的部署，并确保您使用的索引配置适合您的需求。
集合使得创建具有不同Pod类型和大小的新版本的索引变得容易，我们鼓励您利用这个功能来测试不同的配置。本指南仅是大小考虑因素的概述，不应被视为明确的指南。
标准版、企业版和企业专属版的用户可以联系支持人员获取有关大小和测试的进一步帮助。
概览
配置Pinecone索引时需要考虑五个主要因素：
向量数量
向量维度
每个向量的元数据大小
每秒查询速率
索引元数据的基数
每个因素都需要对索引大小、Pod类型和复制策略有所要求。
向量数量
在确定大小时，最重要的考虑因素是您打算使用的向量数量。一般而言，单个p1 Pod可以存储约1M个向量，而s1 Pod可以存储5M个向量。但是，这可能会受到其他因素的影响，例如维度和元数据，这些因素在下面进行了解释。
向量的维度
上述关于在给定的pod中可以存储多少向量的经验法则，假定了每个向量的典型配置为768个向量维度。由于您的个别用例将决定向量的维度，因此存储它们所需的空间可能需要更大或更小。
单个向量上的每个维度消耗4个字节的内存和存储器空间，因此如果您预计每个具有768个维度的1M向量，则大约需要3GB的存储空间（不考虑元数据或其他开销）。利用这个参考值，我们可以估算出给定索引所需的典型pod大小和数量。下表1给出了一些示例。
表1：根据维度预计每1M向量的pod数量
| Pod类型 | 维度 | 预计每个pod最大向量数 |
|---|---|---|
| p1 | 512 | 1,250,000 |
| 768 | 1,000,000 | |
| 1024 | 675,000 | |
| p2 | 512 | 1,250,000 |
| 768 | 1,100,000 | |
| 1024 | 1,000,000 | |
| s1 | 512 | 8,000,000 |
| 768 | 5,000,000 | |
| 1024 | 4,000,000 |
Pinecone不支持分数型Pod部署，因此在选择Pod时，向上舍入至最接近的整数。
每秒查询数 (QPS)
QPS速度受索引的Pod类型，副本数以及查询的top_k值的组合控制。Pod类型是主要驱动QPS的因素，因为不同的Pod类型是针对不同的方法进行优化的。
P1 pods 是性能优化的 pod，提供非常低的查询延迟，但每个 pod 所能容纳的向量数量较少，比 S1 pods 更适用于对延迟要求较低 (<100ms) 的应用。S1 pods 则优化了存储，并提供大容量存储和略高于 p1 pods 的查询延迟，适用于具有中等或宽松延迟要求的大型索引。
P2 pod 类型 提供更大的查询吞吐量和更低的延迟。它们支持每个副本 200 QPS，并在少于 10ms 的时间内返回查询结果。这意味着对于低维向量 (<512D)，查询吞吐量和延迟均优于 s1 和 p1。
通常情况下，没有副本的单个p1 Pod可以处理每秒约20个QPS，其中每个QPS有1M个768维向量。根据元数据的大小、向量数量、向量的维度以及您的搜索的top_K值，可以获得更高或更低的速度。有关更多示例，请参见下表2。
表2：按Pod类型和top_k值分类的QPS
| Pod type | top_k 10 | top_k 250 | top_k 1000 |
|---|---|---|---|
| p1 | 30 | 25 | 20 |
| p2 | 150 | 50 | 20 |
| s1 | 10 | 10 | 10 |
*表2中的QPS值表示使用1M个向量和768维的基准QPS。
添加副本是增加QPS的最简单方法（如何提高吞吐量）。每个副本大致增加相同的QPS吞吐量，因此，使用p1 pod并添加5个副本可以实现150 QPS的目标。在应用程序中使用线程或多进程也很重要，因为依次发出单个查询仍然会受到任何潜在延迟的影响。使用Pinecone gRPC客户端也可以增加upsert的吞吐量。
元数据基数和大小
在计划索引时的最后一点考虑是元数据的基数和大小。虽然一千万个向量时增加很小，但随着向量数增加到数亿或数十亿，其影响是实实在在的。
具有非常高基数的索引（例如，每个向量存储唯一用户ID的索引）可能需要大量内存，导致 pod 中可以容纳的向量数量减少。此外，如果每个向量的元数据大小更大，则索引需要更多存储空间。使用选择性元数据索引来限制索引的元数据字段可以帮助降低内存使用。
Pod 大小
您还可以从较大的pod 大小开始，例如 p1.x2。每个 pod 大小的升级会将可用于您的向量的空间加倍。我们建议从 x1 pod 开始，并随着您的增长而扩展。这样，您就不会从太大的 pod 大小开始，并且在没有其他升级空间的情况下，不得不在准备好之前迁移到新的索引。
示例应用程序
以下示例将展示如何使用上述大小指南来选择适当类型、大小和数量的Pod来为您的索引服务。
示例1：新闻文章的语义搜索
在我们的第一个示例中，我们将使用我们文档中的语义搜索演示应用程序。在这种情况下，我们只处理204,135个向量。每个向量使用300个维度，远低于768个维度的一般度量标准。根据上面的经验法则，每个p1 Pod最多可容纳1M个向量，我们可以使用单个p1.x1 Pod轻松运行此应用程序。
例 2：面部识别
假设您正在构建一个用于安全银行应用的客户面部识别应用程序。面部识别可以使用至少 128 个维度，但在这种情况下，由于该应用程序将用于获取金融信息，我们希望确保使用它的人是正确的人。我们计划支持 1 亿客户，并使用每个向量的 2048 个维度。
我们知道根据上面的经验法则，1 百万个具有 768 个维度的向量可以完美地适配一个 p1.x1 pod。我们只需要将这些数字除以新目标，以获得我们需要的 pod 估计比例：
100M / 1M = 100 base p1 pods
2048 / 768 = 2.667 vector ratio
2.667 * 100 = 267 rounding up
所以我们需要 267 个 p1.x1 pods。我们可以通过转换为 s1 pods 来减少这个数量，但需要通过增加存储可用性来牺牲延迟。它们的存储容量是 p1.x1 的五倍，所以计算很简单：
267 / 5 = 54 rounding up
因此，我们估计我们需要 54 个 s1.x1 pods 来存储银行每个客户面部的高维数据。
更新于 2 个月前