在向量检索系统中，pgvector 凭借其对 PostgreSQL 生态的无缝集成，已成为中小规模向量存储的首选方案。然而，当数据量突破亿级门槛时，HNSW 索引的内存占用会迅速成为系统瓶颈。本文将从内存占用建模出发，结合磁盘溢出策略，提供面向亿级向量的工程化落地方案。

一、HNSW 索引内存占用模型

理解 pgvector HNSW 的内存占用是进行容量规划的前提。HNSW（Hierarchical Navigable Small World）是一种基于图的多层索引结构，其内存消耗主要由三部分组成：原始向量数据、图结构邻接表以及元数据开销。

原始向量占用相对直观。以 768 维向量为例，float32 类型每条向量需要 768 × 4 = 3072 字节，约 3KB；采用 float16 压缩后可降至 1536 字节。pgvector 支持 vector(dim) 的存储方式，默认使用 float32，若对精度要求不是极致苛刻，可在应用层转换为 float16 存储以换取约 50% 的内存节省。

图结构开销是 HNSW 内存占用的核心部分。每条向量在构建索引时会被分配到某一层的多个邻居节点，参数 m 决定了每层最大的邻居数量。由于 HNSW 是双向图（每个连接都是双向的），实际存储的边数为 m × 2。在 PostgreSQL 内部，每条边需要 8 字节存储目标向量 ID，因此每条向量的邻接表开销约为 m × 2 × 8 字节。当 m=16 时，单条向量的邻接表开销为 256 字节；m=32 时为 512 字节。这一开销与向量维度无关，在高维向量场景下可能占据相当比例。

元数据开销包括 HNSW 的分页表（page table）、层级信息（level info）以及登入点（entry point）指针等。每条向量大约需要 16 到 24 字节的元数据，用于维护图结构的层级遍历逻辑。

综合以上三个部分，亿级向量的内存占用可以通过以下公式估算：总内存 = N × (向量字节数 + m × 2 × 8 + 20) + 索引构建临时内存，其中 N 为向量总数。以 1 亿条 768 维 float32 向量、m=16 为例：向量数据 300GB、邻接表 25.6GB、元数据 2GB，仅索引本身就需要约 328GB 内存，远超单机承载能力。

二、亿级向量场景的容量规划

面对如此庞大的内存需求，工程实践中需要采取分层策略。首先是向量压缩。pgvector 本身不直接支持 float16 索引，但可以在应用层将向量转换为 float16 后存入，再利用昆廷（quantization）技术进一步压缩。Facebook 的 Faiss 库提供了 Product Quantization（PQ）实现，可将向量压缩至原来的 1/8 到 1/32，这对于亿级向量场景至关重要。

其次是维度削减。如果业务场景允许一定的精度损失，主成分分析（PCA）或随机投影可以有效降低向量维度。768 维压缩至 128 维，内存占用直接降至原来的约六分之一，检索效果在多数语义搜索场景下仍在可接受范围内。

第三是参数调优。m 值直接影响搜索质量和内存占用。pgvector 默认 m=16，对于追求召回率的场景可提升至 32 或 64，但每提升一倍，邻接表内存翻倍。ef_construction 控制建索引时的搜索宽度，越大构建越慢但图质量越高，通常 64 到 200 是合理区间。ef_search 控制查询时的搜索宽度，值越大召回越高但延迟增加，实时查询建议 50 到 200，离线批处理可设到 500 以上。

三、磁盘溢出策略与工程实践

当内存无法容纳完整索引时，需要引入磁盘溢出策略。pgvector 支持三种核心策略，各有优劣。

** 分区策略（Partitioning）** 是最直接的方案。将 1 亿条向量按某个业务字段（例如用户 ID、类别标签）拆分为多个分区，每个分区独立构建 HNSW 索引。例如将 1 亿条拆成 10 个分区，每个分区 1000 万条向量，单个索引内存需求降至约 32GB，在 64GB 内存的机器上完全可以加载。查询时并行遍历所有分区并合并结果。pgvector 通过 PostgreSQL 的表分区机制实现这一策略，需要注意的是分区键的选择应保证查询时能下推过滤条件，否则需要扫描所有分区。

** 内存映射策略（mmap）** 依赖操作系统的虚拟内存管理。将整个索引文件映射为内存地址空间，操作系统会自动处理热数据的缓存和冷数据的换出。这种方式对应用层透明，无需修改代码，但需要确保 SSD 的随机读取性能足够（建议使用 NVMe SSD）。Linux 系统的 vm.swappiness 参数应设为较低值（如 10），避免过度使用交换分区。当索引文件超过可用内存 2 到 3 倍时，性能会出现明显下降，此时应结合分区策略共同使用。

外部存储与近实时查询是更激进的方案。将 HNSW 索引完全存储在 SSD 上，查询时按需加载部分图结构。Faiss 的 HNSW 实现支持基于内存限制的动态图遍历，可以设定每次查询最多加载多少 MB 的图数据。配合 SSD 的高吞吐（主流 NVMe SSD 随机读取可达 500K IOPS），可以在 10ms 级别延迟内完成亿级向量的近似最近邻搜索。这种方案的挑战在于需要维护独立的向量数据库或自建 Faiss 服务，与 PostgreSQL 的集成需要额外的数据同步机制。

四、监控指标与调优阈值

生产环境中需要密切关注以下指标：shared_buffers 命中率应保持在 95% 以上，低于此值说明索引数据未被有效缓存；idx_blks_hit 与 idx_blks_read 的比例反映了索引页的热度；Linux 的 free -m 可监控实际物理内存使用，若可用内存长期低于 10%，说明存在内存争用。

对于延迟敏感的业务，建议设置 work_mem 为 256MB 到 1GB，确保排序和哈希操作有足够内存；maintenance_work_mem 建议设为 4GB 到 8GB，用于索引构建和 VACUUM 操作。监控 pg_stat_statements 中的索引相关查询耗时，识别出 P99 延迟超过业务阈值的慢查询，针对性调高 ef_search 或优化分区键。

五、总结与建议

pgvector HNSW 在亿级向量场景下的内存挑战本质上是向量维度、图结构参数与存储成本的三方权衡。工程落地的核心思路是：压缩向量维度、合理选择 m 值、采用分区策略分散内存压力、利用 SSD 与 mmap 实现近实时查询。对于追求极致性能的团队，可以引入 Faiss 或 Milvus 等专用向量引擎作为检索层，pgvector 仅负责元数据存储和初步过滤。

在实际项目中，建议先进行小规模基准测试，测量单条向量在不同参数组合下的实际内存占用，再按比例推算亿级场景的资源需求。内存规划不应仅考虑索引本身，还需预留 shared_buffers、连接内存、操作系统缓存等开销，通常需要预留 20% 到 30% 的冗余。

参考资料