宣布 PlanetScale Vectors 公测启动
我们很高兴地宣布,PlanetScale 的向量搜索和存储功能现已开放公测!借助 PlanetScale 的向量支持,你可以将向量数据与应用程序的关系型 MySQL 数据一同存储——无需再使用单独的专用向量数据库。
PlanetScale 向量搜索和存储的独特之处
当我们决定在 PlanetScale 的 MySQL 分支中添加向量支持时,就意识到这将是一场漫长的旅程,因为我们需确保这一解决方案符合我们对性能和可扩展性的高标准要求。
一个关键部分是设计一种既能保证快速性能又能支持大规模的搜索算法。PlanetScale 的向量搜索基于 Microsoft Research 的两篇创新研究论文:SPANN(Space-Partitioned Approximate Nearest Neighbors) 和 SPFresh。我们对该解决方案进行了额外的开发,使其能够完全无缝集成到 InnoDB 和 Vitess 中,从而支持事务操作、确保数据一致性,并高效管理 TB 级向量索引。这使我们的向量搜索解决方案非常适合处理大型数据库。
除此之外,我们还确保了我们的实现具备以下功能:
- 预过滤和后过滤(Pre-filtering 和 Post-filtering);
- 完整的 SQL 语法支持——包括
JOIN
,WHERE
和子查询; - ACID(原子性、一致性、隔离性、持久性)事务规则的完全遵守。
我们的基础实现已经满足了以上所有要求,并且我们将持续提升性能,直至正式全量发布(GA)。
向量搜索算法的选择
用于实现向量搜索的常用算法有几个,例如 HNSW(Hierarchical Navigable Small Worlds) 和 DiskANN 是最流行的两种。但这些算法存在技术上的权衡,我们发现它们并不适合我们的实现需求:
- HNSW 查询性能非常优秀,但扩展性较差,因为它需要将整个数据集加载到 RAM 中。最重要的是,HNSW 索引无法进行增量更新,因此它需要定期重新构建索引。这对于关系型数据库来说不是一个理想的选择。
- DiskANN 扩展性很好,但查询性能更差。而虽然 DiskANN 可以被修改以支持增量更新,但效率不高,并且难以与 SQL 的事务语义相匹配。
由于 PlanetScale 专为处理大规模数据库提供卓越性能而设计,我们知道这些实现并不适合我们的需求。因此,我们决定寻找更好的解决方案。
PlanetScale 的向量搜索基于 Microsoft Research 的两篇最先进的论文中的新型实现:SPANN 和 SPFresh。
- SPANN 是一种混合型向量索引和搜索算法,结合了图结构和树结构,专为需要使用 SSD 的超大规模(超过 RAM)索引设计。
- SPFresh 扩展了 SPANN 的设计,添加了一组并行的后台维护操作,使得索引能够在持续更新的同时不丧失快速查询性能或召回能力(recall)。
在我们的实现中,我们进一步扩展了 SPFresh,为其所有操作添加了事务支持,并将其完全集成到 InnoDB(MySQL 的默认存储引擎)中。这意味着:
- 向量数据的插入、更新和删除操作会作为 SQL 事务的一部分立即反映到向量索引中;
- 支持事务级的批量提交和回滚。
由于索引由 InnoDB 的磁盘管理和存储,它始终与表中的向量数据保持同步,能够在进程崩溃时提供强一致性的保证;而且无需定期重建,能像任何其他 MySQL 表一样扩展到 TB 级别。与 PlanetScale 的分片层 Vitess 相结合,这使得能够构建和高效查询与数据库中全部关系型数据完全集成的超大规模向量索引。你可以同时使用 JOIN
和 WHERE
子句,并在底层向量数据持续更新时查询这些数据。
注意事项
对于常见的向量搜索算法和索引的比较,可参考我们的向量数据库术语和索引文档。
如何启用向量支持
要开始使用,请进入数据库设置页面:
- 点击“Beta features”;
- 找到“Vectors”,点击“Enroll”。
向量支持是以分支级别启用的,因此选择你希望加入向量 Beta 的分支。然后点击分支页面上的齿轮图标,并切换“Enable vectors”选项即可。
PlanetScale 的向量搜索和存储功能不仅消除了对专门向量数据库的依赖,还通过高性能架构和与关系型 SQL 的深度集成,为开发者提供了一个强大、灵活且简化的解决方案。现在,你可以轻松地将向量数据存储与传统关系型数据结合,实现更高效的查询和大规模数据分析能力。
关注公众号:程序新视界,一个让你软实力、硬技术同步提升的平台
除非注明,否则均为程序新视界原创文章,转载必须以链接形式标明本文链接