4-让十亿级向量搜索回到单机-周金晶.pdf

1、周金晶 从用户增长到向量增长：1B 规模并不遥远为什么 1B 向量会来得比想象中更快？现有方案很难平滑承接规模增长Billion 级向量检索挑战DEEP-1B 案例：单机下的十亿向量索引构建在 PostgreSQL 上构建向量数据库有哪些问题？-基于 Page 的抽象-8kb 对于向量来说太小了，只能支撑 2000 维的向量-需要额外处理大于 2000 维的向量，存储及一致性-语法问题-SQL 对于很多用户来说，比直接包装的 SDK 和基于 REST API 更复杂，上手更困难-语义并不一致，向量索引都是近似的，但是 SELECT xxx ORDER BY distance 上并没有表现出近似

2、的语义在 PostgreSQL 上构建向量数据库有哪些问题？-缺少类似于 Compaction 的抽象-受限于向量索引的特征，最好的做法是定期大批量更新数据到索引，而不是针对每一个插入都直接插入原有索引结构中-传统数据的索引例如 B-Tree 处理的数据量级很小（几十 Bytes），但是对于向量来说动辄就几 Kb 到十几 Kb，更新压力直接变大-GIN index 倒排索引中有个 fast_update 的选项会将插入数据攒批，在某一个插入时候批量更新，但是对于向量数据来说仍然不够高效-数据库本身额外开销-SQL 解析-多进程模型额外开销等PostgreSQL 帮助我们解决了哪些构建向量数据库

3、的问题？-资源管理-良好的 Buffer 抽象-Page 的使用计数-先进并且经过仔细调试的 I/O 路径-io_uring(PG18)/async worker/parallel worker-同样的 API 随着 PG 版本的升级 I/O 能直接获得提升-带过滤的向量搜索-PG 提供了完美的抽象，我们只要聚焦在向量索引上就能实现任何形式的 Query为什么 PostgreSQL 比其他专有向量数据库更好？-几乎所有的开源向量数据库都基于 mmap，而不是更好的内存管理抽象-Andy Pavlo:In this way,MMAP and DBMSs are like coffee and spicy food:an unfortunate combination that becomes obvious after the fact.-无法对内存中的内容进行细粒度的控制-无法真正实现基于磁盘的向量索引-因为没法控制具体的数据换入换出，只能依赖系统层面的调度算法-导致一旦数据量超过内存大小，就会导致整个集群极不稳定