好消息,MemFire Cloud应用开发新版本中已支持pgvector 0.6.0版本!!
pgvector 0.6.0版本带来了一个重大改进:为HNSW索引引入了并行构建功能。对于未记录的表(unlogged tables),构建HNSW索引的速度现在快了高达30倍。
这个版本的发布对pgvector来说是向前迈出的一大步,使得调整HNSW构建参数、提高搜索准确性和性能变得更加容易。
pgvector中的HNSW索引
在之前的文章中探讨过 HNSW的工作原理,现在简单回顾一下: HNSW 是一种用于近似最近邻搜索的算法。它使用近邻图,由两部分组成:分层和可导航的小世界。它在具有不同密度或节点间距离的多个层上运行,其中层代表节点间不同的连接长度。因此,HNSW 可以在线性时间内完成搜索、插入和删除。
pgvector并行索引构建
在0.6.0版本之前,pgvector只支持使用单线程构建索引——这对大型数据集来说是一个很大的瓶颈。例如,为1536个维度的100万个向量建立索引大约需要1小时27分钟(使用'm'=16, 'ef_construction'=200
参数)。
使用并行索引构建,可以在9.5分钟内为相同的数据集构建索引——速度快了9倍:
性能对比:pgvector 0.5与0.6
使用dbpedia-entities-openai-1M数据集(100万个向量,1536个维度)测试索引构建时间,以比较并行和单线程索引HNSW构建的性能。同时,我们验证了结果索引在准确性和每秒查询数(QPS)方面是相同的。
在不同数据库大小上运行基准测试,以查看并行构建的影响:
- 4XL实例(16核心 64GB RAM)
- 16XL实例(64核心 256GB RAM)
4XL实例(16核 64GB RAM)
此基准测试使用了以下参数:
0.5.1 | 0.6.0 | |
---|---|---|
mainenance_work_mem | 30GB | 30GB |
max_parallel_maintenance_workers | - | 15 |
max_parallel_maintenance_workers
控制用于构建索引的并行线程数量。在后续章节中,我们将提到包括领导者在内的总工作线程数量。
0.6.0版本的索引构建时间快了7-9倍,而两个版本的每秒查询数和准确性保持不变:
v0.5.1
:所有基准测试的平均QPS为938,准确性为0.963。v0.6.0
:所有基准测试的平均QPS为950,准确性为0.963。
16XL实例(64核 256GB RAM)
您可以使用更强大的实例(这些参数最高可达 13.5 倍)进一步提高索引构建性能。
索引构建时间与使用的内核数不是线性比例关系。max_parallel_maintenance_workers
的一个合理默认值是CPU数量 / 2
,这是我们在MemFire Cloud平台上设置的默认值。准确性和QPS不受max_parallel_maintenance_workers
的影响。
使用未记录的表进行嵌入
使用未记录的表可以进一步减少构建时间。
在 Postgres 中,未记录的表是指其修改未记录在预写日志(WAL)中的表(为了性能牺牲数据可靠性)。未记录的表是嵌入的绝佳选择,因为原始数据通常单独存储,并且可以随时从源数据重新创建嵌入。
索引创建的一个步骤是最终扫描和WAL写入。这通常是很短暂的,但不可并行化。使用未记录的表可以跳过WAL,影响显著:
ef_construction | 构建时间:v0.5.1 | 构建时间:v0.6.0((unlogged)) | 改进 |
---|---|---|---|
64 | 38m 08s | 1m 38s | 23倍 |
100 | 1h 06m 59s | 2m 10s | 31倍 |
200 | 1h 27m 45s | 3m 37s | 24倍 |
如何开始使用
pgvector 0.6.0已经发布,并已经在MemFire Cloud应用开发中可用,具体教程可以参考:pgvector: 嵌入向量和向量相似性 。
作者:Egor Romanov 原文地址:https://supabase.com/blog/pgvector-fast-builds
更多参考:
https://supabase.com/blog/increase-performance-pgvector-hnsw#how-does-hnsw-work