阿里巴巴工程团队如何让pgvector在十亿向量规模下高效运行

自2023年以来，向量数据库经历了三个阶段：首先，支持向量类型和基本距离算子。接着出现了近似最近邻索引（如IVF和HNSW），将响应时间降至个位数毫秒。第三阶段, , 大规模生产就绪, , 被证明是最困难的。阿里云PolarDB for PostgreSQL团队在一篇技术文章中记录了其方法，详细解释了将开源pgvector扩展转化为能够存储数十亿向量并在毫秒内返回结果的引擎所需的具体工作。

量化：将更大向量装入更小空间

第一个瓶颈是存储和计算成本。一个768维的float32向量大约占用3 KB。乘以十亿，在建立索引之前原始数据就达到3 TB。PolarDB for PostgreSQL现在在IVF和HNSW索引旁支持三种量化方案：乘积量化（PQ）、标量量化（SQ）和随机位量化（RaBitQ）。每种方案将向量压缩到原始大小的四分之一到六十四分之一，同时保持精度可控。团队强调，没有一种方案适用于所有场景，正确选择取决于数据集大小、特征集中度和维度。PQ将向量分割成子段，并为每个段训练码本，压缩率高但训练成本高。SQ将每个float32维度线性映射到int8或int4，是最经济的选择。RaBitQ使用随机正交变换加1位量化，理论上具有可证明的精度下界。

性能增强：十亿规模下的I/O和空闲空间管理

标准pgvector上的索引构建遵循PostgreSQL缓冲区管理器：每个写入的页面都要经过共享缓冲区、获取锁、生成预写日志并异步刷新。当索引达到数百GB时，这一路径成为主要瓶颈。PolarDB引入了索引构建的批量读写和查询的预取窗口。内部测试显示，在十亿向量规模下，构建和查询速度提高了1.5到2倍。第二个痛点出现在持续插入时：当索引中出现空闲页面时，新插入必须顺序扫描数据页以找到可用空间。团队引入了高效的可用空间管理（FSM）机制。在十亿行规模持续插入的测试中，I/O争用减少了90%，p99写入延迟显著更稳定。结合重新设计的索引清理框架（将膨胀从线性增长转变为稳态），系统在高写入高删除工作负载下也能保持长期稳定性。

生态系统增强：polar_vectorboost自动化混合搜索

采用向量检索的团队通常需要手动编写大量融合查询逻辑：嵌入列、分词、回填数据、推荐索引，然后处理不一致的规模、缺少融合排序和召回稳定性问题。PolarDB的内部扩展polar_vectorboost将这些高频SQL操作压缩为单个函数调用。一次调用即可添加嵌入列、自动分词文本、回填数据、推荐索引并注册元数据。对于混合搜索，它支持两种融合算法：对规模不敏感的倒数排序融合（RRF），以及加权最小-最大归一化方法。它还会自动用OR连接tsquery词项，以避免plainto_tsquery默认AND连接导致的召回崩溃。一组诊断函数（检查列类型、维度一致性、索引状态以及NULL或零范数向量）帮助开发者在问题影响生产前捕获它们。

大规模场景：面向PB级容量的分布式pgvector

单节点存储最终会达到上限，写入吞吐量受限于单个CPU。PolarDB for PostgreSQL已完成pgvector的分布式适配。核心方法依赖三种机制：将向量数据分布到多个分片，每个分片拥有自己的索引；使用分散-聚集模式处理跨分片查询；支持动态分片再平衡。结果带来了三个质的改变：存储可水平扩展到PB级别；写入吞吐量大致随节点数线性增长；故障恢复变为分片级别而非整个数据库。团队指出，在向量场景中，分布式能力不仅仅关乎容量，它决定了系统在长期增长下是否可持续。

基础能力：如何达到生产级标准

向量检索能力依赖于数据库基础层。PolarDB for PostgreSQL的基础栈包括深度内核优化（物理复制、RDMA高速网络和分布式共享存储）。通过一写多读架构，支持秒级扩缩容，容量达TB级别。跨机器并行查询引擎协同执行SQL，加速分析查询。对于十亿级向量存储，热分片驻留高速层，冷分片移至对象存储，平衡成本与性能。团队认为，向量能力主要聚焦于检索层，而生产环境中的整体可用性取决于底层数据库基础。五个维度中的每一个都解决了一个关键的工程瓶颈，而非单一性能指标，它们共同将pgvector从开源扩展转变为集成的引擎，能够处理数十亿向量并实现毫秒级响应。