PGVector，PostgreSQL的向量扩展。

本文是踩坑总结与实战经验，包括安装配置、索引选择、参数调优、性能优化、常见问题，以及我的经验教训。

一、PGVector简介

1. 什么是PGVector

第一个：什么是PGVector。

  • PostgreSQL的扩展
  • 支持向量类型
  • 支持向量搜索
  • 支持相似度计算
  • 是向量数据库的选择

PGVector，是PostgreSQL的向量扩展。

2. 为什么用PGVector

第二个：为什么用PGVector。

  • 不用单独部署向量数据库
  • 复用PostgreSQL
  • 事务支持
  • 关系型和向量一起
  • 简单方便

为什么用，是因为简单。

3. 适用场景

第三个：适用场景。

  • 中小规模向量搜索
  • RAG应用
  • 推荐系统
  • 相似度匹配
  • 不想单独维护向量数据库

适用场景，是中小规模。

4. 不适用场景

第四个：不适用场景。

  • 超大规模向量搜索
  • 超高并发
  • 超高性能要求
  • 这些场景用专门的向量数据库
  • 比如Milvus、Qdrant

不适用，是超大规模。

二、安装配置

1. 安装

第一个：安装。

-- 安装扩展
CREATE EXTENSION vector;
  • PostgreSQL 12+
  • 安装扩展
  • 很简单
  • 是第一步

安装，很简单。

2. 创建向量列

第二个：创建向量列。

CREATE TABLE documents (
    id bigserial PRIMARY KEY,
    content text,
    embedding vector(1536)
);
  • 指定维度
  • 维度要和模型一致
  • 是基础

创建列，是基础。

3. 插入数据

第三个：插入数据。

INSERT INTO documents (content, embedding)
VALUES ('hello', '[1,2,3,...]');
  • 插入向量
  • 格式是数组字符串
  • 很简单
  • 是基础操作

插入，是基础。

4. 相似度查询

第四个：相似度查询。

-- L2距离
SELECT * FROM documents
ORDER BY embedding <=> '[1,2,3]'
LIMIT 10;

-- 内积
SELECT * FROM documents
ORDER BY embedding <#> '[1,2,3]'
LIMIT 10;

-- 余弦相似度
SELECT * FROM documents
ORDER BY embedding <=> '[1,2,3]'
LIMIT 10;
  • 支持多种距离
  • L2、内积、余弦
  • 根据需求选择
  • 是核心操作

查询，是核心。

三、索引选择

1. 索引类型

第一个：索引类型。

  • ivfflat：倒排文件
  • hnsw：层次化可导航小世界
  • 各有优缺点
  • 根据场景选择

索引类型，是关键。

2. ivfflat

第二个：ivfflat。

CREATE INDEX documents_embedding_idx
ON documents USING ivfflat (embedding vector_l2_ops)
WITH (lists = 100);
  • 适合大数据量
  • 查询快
  • 构建快
  • 但需要调参
  • 是常用选择

ivfflat，是常用选择。

3. hnsw

第三个：hnsw。

CREATE INDEX documents_embedding_idx
ON documents USING hnsw (embedding vector_l2_ops);
  • 精度高
  • 更新快
  • 查询稳定
  • 但构建慢
  • 占空间大

hnsw，是高精度选择。

4. 怎么选

第四个：怎么选。

  • 数据量小：不用索引
  • 数据量大：ivfflat或hnsw
  • 读多写少：ivfflat
  • 写多读多：hnsw
  • 根据场景

选择，看场景。

5. 索引参数

第五个：索引参数。

  • ivfflat的lists
  • hnsw的m、ef_construction
  • 查询时的probes、ef_search
  • 要调优
  • 影响精度和速度

参数，要调优。

四、踩坑总结

1. 坑一：维度不一致

第一个坑：维度不一致。

  • 列定义1536维
  • 插入768维
  • 报错
  • 要确保维度一致
  • 是常见坑

维度，要一致。

2. 坑二：索引没生效

第二个坑：索引没生效。

  • 建了索引
  • 但查询没用
  • 因为数据量小
  • 或者参数不对
  • 要检查执行计划

索引，要确认生效。

3. 坑三：lists参数不对

第三个坑：lists参数不对。

  • lists太大或太小
  • 影响查询性能
  • 一般是数据量/1000
  • 要根据数据量调整
  • 是常见坑

lists，要调优。

4. 坑四：向量没有归一化

第四个坑：向量没有归一化。

  • 用余弦相似度
  • 但向量没归一化
  • 结果不对
  • 要归一化
  • 是常见坑

归一化，要注意。

5. 坑五：内存不够

第五个坑：内存不够。

  • 向量索引占内存
  • 数据量大了
  • 内存不够
  • 查询变慢
  • 要监控

内存，要监控。

五、参数调优

1. work_mem

第一个：work_mem。

SET work_mem = '256MB';
  • 排序需要内存
  • 太小会用磁盘
  • 太慢
  • 要调大
  • 是关键参数

work_mem，是关键。

2. maintenanceworkmem

第二个：maintenanceworkmem。

SET maintenance_work_mem = '1GB';
  • 建索引需要内存
  • 大内存建索引快
  • 要调大
  • 是建索引时的参数

maintenanceworkmem，是建索引的参数。

3. ivfflat.probes

第三个：ivfflat.probes。

SET ivfflat.probes = 10;
  • 查询时搜索多少个list
  • 越大越精确
  • 但越慢
  • 要平衡
  • 是查询参数

probes，是查询参数。

4. hnsw.ef_search

第四个：hnsw.ef_search。

SET hnsw.ef_search = 40;
  • hnsw查询时的搜索宽度
  • 越大越精确
  • 但越慢
  • 要平衡
  • 是查询参数

ef_search，是查询参数。

5. 共享缓冲区

第五个：共享缓冲区。

shared_buffers = '4GB'
  • 缓存索引和数据
  • 大了性能好
  • 但不要超过内存的25%
  • 要根据机器调整

共享缓冲区，是基础参数。

六、性能优化

1. 优化一：选择合适的索引

第一个优化：选择合适的索引。

  • 根据场景选ivfflat或hnsw
  • 数据量小不用索引
  • 选对索引
  • 性能提升明显

索引，是基础。

2. 优化二：调优参数

第二个优化：调优参数。

  • work_mem
  • probes/ef_search
  • 共享缓冲区
  • 调优参数
  • 性能提升

参数，要调优。

3. 优化三：分区表

第三个优化：分区表。

  • 数据量大了
  • 分区表
  • 提升查询性能
  • 便于维护
  • 是架构优化

分区，是架构优化。

4. 优化四：预过滤

第四个优化：预过滤。

  • 先用其他条件过滤
  • 再做向量搜索
  • 减少向量搜索的数据量
  • 提升性能
  • 是常用技巧

预过滤，是技巧。

5. 优化五：缓存

第五个优化：缓存。

  • 缓存热门查询结果
  • 减少重复计算
  • 提升响应速度
  • 用Redis
  • 是常用技巧

缓存，是效率的保障。

七、常见问题

1. 问题一：查询慢

第一个问题：查询慢。

原因：

  • 没建索引
  • 索引参数不对
  • 内存不够
  • 数据量太大

解决：

  • 建索引
  • 调参数
  • 加内存
  • 分区

查询慢，是常见问题。

2. 问题二：结果不准确

第二个问题：结果不准确。

原因：

  • 索引是近似搜索
  • probes/ef_search太小
  • 向量没归一化

解决：

  • 调大probes/ef_search
  • 归一化向量
  • 用精确搜索（不用索引）

不准确，是近似搜索的代价。

3. 问题三：插入慢

第三个问题：插入慢。

原因：

  • 索引更新慢
  • hnsw更明显
  • 数据量大

解决：

  • 批量插入
  • 先插数据再建索引
  • 用ivfflat

插入慢，是索引的代价。

4. 问题四：占空间大

第四个问题：占空间大。

原因：

  • 向量本身占空间
  • 索引占空间
  • hnsw更占空间

解决：

  • 降维
  • 用ivfflat
  • 压缩

空间，是成本。

5. 问题五：和专门的向量数据库怎么选

第五个问题：和专门的向量数据库怎么选？

回答：

  • 中小规模用PGVector
  • 超大规模用专门的
  • 已经用PostgreSQL用PGVector
  • 追求性能用专门的
  • 看需求

选择，看需求。

八、经验教训

1. 教训一：先评估规模

第一个教训：先评估规模。

  • 先评估数据量
  • 评估查询量
  • 评估性能要求
  • 再选方案
  • 不要盲目

评估，是第一步。

2. 教训二：索引要调优

第二个教训：索引要调优。

  • 不是建了索引就好
  • 要调参数
  • 要测试
  • 要监控
  • 持续优化

索引，要调优。

3. 教训三：要监控

第三个教训：要监控。

  • 监控查询性能
  • 监控索引使用率
  • 监控数据量
  • 监控内存
  • 及时发现问题

监控，是保障。

4. 教训四：要有备选方案

第四个教训：要有备选方案。

  • PGVector不够用了
  • 要能迁移到专门的向量数据库
  • 要有备选
  • 不要锁死

备选，是安全网。

5. 教训五：持续学习

第五个教训：持续学习。

  • PGVector在更新
  • 新功能不断
  • 要持续学习
  • 要持续优化
  • 不要停止

持续学习，是必须的。

九、写在最后

PGVector，踩坑总结与实战经验。

简介：什么是PGVector、为什么用、适用场景、不适用场景。安装配置：安装、创建向量列、插入数据、相似度查询。索引选择：ivfflat、hnsw、怎么选、索引参数。踩坑总结：维度不一致、索引没生效、lists参数不对、向量没归一化、内存不够。参数调优：workmem、maintenanceworkmem、probes、efsearch、共享缓冲区。性能优化：选择合适的索引、调优参数、分区表、预过滤、缓存。

2023年了，向量搜索越来越流行，PGVector是其中的代表。它简单方便，复用PostgreSQL，适合中小规模。但也有坑，要调优，要监控，要有备选方案。

最后，用一句话总结："PGVector，简单方便，适合中小规模。但要调优，要监控，要评估规模。选对方案，才能发挥最大价值。"

希望我的踩坑总结和实战经验，能帮到你。