《向量数据库指南》：向量数据库Pinecone类型和数量
目录
概览
向量数量
向量的维度
每秒查询数 (QPS)
元数据基数和大小
Pod 大小
示例应用程序
示例1：新闻文章的语义搜索
例 2：面部识别
在进行Pinecone部署规划时，请掌握向量大致所需存储空间的信息，以便辅助您选择合适的Pod类型和适当数量。本页面旨在提供关于尺寸相关指导的信息，请您做好部署准备。
如同其他相关指南所述，在大多数情况下这些考虑因素具有普遍性 但它们可能并不完全符合您的特定需求 我们推荐您在实际应用中进行测试 并选择的索引配置应与您的应用需求相匹配
集合功能通过简便的方式使创建不同Pod类型和大小的新版本索引变得容易，并建议尝试不同的配置方案以适应需求变化。本指南仅为大小因素提供简要介绍，请避免将其视为具体操作指南
建议不同版本的用户联系支持人员...以获取有关大小和测试的支持信息。
概览
配置Pinecone索引时需要考虑五个主要因素：
改写说明
每个因素都需要对索引大小、Pod类型和复制策略有所要求。
向量数量
首要考虑要素是在确定大小时的关键问题之一——即您所选择的向量数量。每个p1Pod通常可容纳大约 向量数量 为 1,000,000 左右；每个s1Pod则可容纳约 5,000,000 个这样的数据点（单位视具体情况而定）。然而，在实际应用中，这可能受到其他关键参数的影响——如维度设置和元数据配置等参数——这些相关参数及其影响将在后续内容中详细阐述
向量的维度
因此，在规划存储空间时需要特别考虑这一点
在单个向量中，在于每个维度占用4个字节的内存与存储空间。鉴于此假设，在拥有768维且规模为一百万条的数据集中，则总共将消耗约三吉byte的空间（未计及元数据及其他潜在开销）。基于此基准值，在于估算所需 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类型]是最关键的因素之一。这是因为不同的[Pod类型]都是根据特定场景的方法进行了专门优化设计的。
P1 pods 作为性能优化的选择，在查询延迟方面表现出色] —— 但它们在存储容量上相对有限] [S1 pods 则通过改进存储机制实现了更大的容量] —— 并在查询效率上仅略逊于 P1 pods] [ Pinecone Indexes 提供了几种不同的 pod 型号以适应各种应用场景]
P2 pod 类型 支持更高的查询吞吐效率和显著降低的系统延迟。该架构通过优化设计实现了更高的查询吞吐效率和显著降低的系统延迟。每个副本均能达到200次每秒（QPS）处理能力，并能在不到10毫秒的时间内完成响应。这表明在处理低于512维的数据时（如向量维度<512D），该架构不仅提升了吞吐效率更有效地降低了响应时间。
一般情况下，在无副本的情况下运行单实例p1Pod可处理约20 QPS（Queries Per Second），每个QPS包含1百万个768维向量。元数据规模、向量数量及维度等因素将影响搜索速度上限和下限。具体说明请参考表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（每秒请求数）最简单有效的方式（如何提高吞吐量）。通过部署p1 pod并复制5个实例即可实现将吞吐能力提升至150 QPS的目标。在应用层上采用多线程或多进程机制同样不可或缺，因为按顺序执行单次查询可能无法规避潜在的时间延迟问题。为了进一步优化读写性能，在实际操作中建议结合Pinecone官方提供的gRPC客户端工具（如...），可以在提升读写性能方面发挥重要作用。
元数据基数和大小
元数据规模与结构在索引规划中占据着重要考量。然而当向量数量达到1\text{亿}或10\text{亿}级别时，具体影响则变得显著起来。
具有高容量的索引（例如每个向量存储唯一用户ID）会导致pod中可容纳的向量数量减少此外如果每个向量的元数据规模更大则会占用更多存储空间因此采用选择性元数据索引来限定元数据字段有助于降低内存消耗
Pod 大小
建议从较小规模的pod开始（例如选择p1.x2配置），每个pod大小的升级会将可用的空间容量翻倍（...）。按照建议从x1 pod规模开始，并根据实际需求逐步扩展（例如考虑升级到x2.x4等更大的配置）。这样设计的好处在于您可以避免一开始就选择过大规模的pod，并且当现有资源无法支持更大规模时，在准备就绪之前迁移到新的索引。
示例应用程序
以下示例将详细阐述如何应用上述大小指南来选择适当类型、大小和数量的Pod以构建您的索引系统。
示例1：新闻文章的语义搜索
在我们的第一个案例中, 我们将采用该文档中的语义搜索演示应用程序1. 在这种情况下, 我们将管理约204,135个向量. 每个向量占据300维空间, 这一数量明显少于768维的标准. 根据经验法则是这样的: 每台p1 Pod最多可容纳1百万向量. 因此, 我们只需配置一个p1.x1 Pod就能轻松执行该应用.
例 2：面部识别
假设您正在开发一套用于金融安全系统的客户面部识别应用。该系统采用至少128维特征进行面部识别。由于该应用旨在收集与金融活动相关的数据，并且特意设计以确保所有认证用户均为真实身份。我们的目标用户规模预计将达到一亿，并且每个用户的面部特征将被编码为2048维向量。
我们遵循上面的经验法则，在特定条件下（如向量维度为768），1 百万这样的向量能够精确匹配到p1.x1 pod结构。通过将这些数值与目标平台的特征进行对比分析，我们可以计算出相应的pod 估计比例：具体操作方法是将这些数值按照比例进行归一化处理即可。
必须部署 267 个 p₁ₓ₁ pods。通过将 pod 转换为 s₁ pods 可以减少数量，在牺牲延迟的同时，必须通过增加存储可用性。这些pod的存储容量等于 p₁ₓ₁ 的五倍：所以计算很简单：
因此，我们估计我们需要 54 个 s1.x1 pods 来存储银行每个客户面部的高维数据。