turbopuffer v3 放弃以向量为主的索引，转而采用二级 ANN 索引

TL;DR – turbopuffer v3 弃用了以向量为主的存储布局

turbopuffer v3 将 ANN 索引从主键改为二级结构，消除了巨大的存储和写入放大，并允许使用更大的向量化处理块，从而加速了向量搜索、全文搜索、聚合以及其他查询计划。

为什么 turbopuffer 要重新设计其存储架构

turbopuffer 的原始设计 (v1) 将每个文档存储为 ID + 向量，并使用 ANN 地址（集群 + 本地 ID）作为主键。这在对象存储上的近似最近邻 (ANN) 搜索中表现极佳，实现了单个索引超过 1000 亿个向量，在超过 1000 QPS 的情况下 p99 延迟为 200 ms。

然而，以向量为主的布局对于非向量工作负载产生了三个关键的低效问题：

存储放大 – 多向量文档（例如，后期交互模型）会为每个向量复制所有属性和文本负载，因为每个向量都有自己的 ANN 地址。
写入放大 – 插入、更新或删除会触发 SPFresh 的向量重平衡，这会移动整个文档负载以及指向旧 ANN 地址的每个倒排索引条目。
有限的向量化 – 现代查询引擎以大块（数千行）处理数据。由于 ANN 地址决定了块大小（每个集群约 100-200 个文档），所有其他查询计划被迫进入这些小块中，从而阻止了 CPU 流水线的充分利用。

这些问题阻碍了 turbopuffer 在属性过滤、全文搜索、聚合和正则表达式查询方面提供最先进的性能。

turbopuffer 查询能力的演进

v1 – 仅 ID + 向量

分层聚类索引 (SPANN → SPFresh) 将向量存储在质心树中。
键为 ClusterId + LocalId（例如 C0L1），构成了 ANN 地址。

v2 – 属性过滤和全文搜索

添加了将属性值或术语映射到 ANN 地址的倒排索引。
将文档属性与向量一起存储在同一个 ANN 键下。
支持 BM25、正则表达式、模糊匹配、稀疏向量和按属性排序——所有这些都建立在相同的以向量为主的布局之上。

核心问题：将 ANN 作为主索引

由于每个文档的负载都位于其 ANN 地址下，因此向量布局的任何更改都会迫使所有相关数据进行级联移动。这种设计反映了经典的 MySQL 风格主索引指向行的做法，其中二级索引指向稳定的主键，从而避免了更新时的大规模重写。相比之下，PostgreSQL 风格的设计将二级索引直接指向物理行位置，以牺牲巨大的写入放大为代价来优化读取时的查找。

涡轮增压器的原始设计实际上是搜索的 PostgreSQL 模型：出色的 ANN 查找性能，但对于其他查询形状而言，写入成本过高且块大小有限。

turbopuffer v3 的解决方案 – 将 ANN 作为二级索引

“不要以 ANN 地址为键” – turbopuffer v3 用传统的文档 ID 主索引替换了 ANN 地址主键。ANN 索引现在表现得像一个指向文档 ID 的二级索引，类似于 InnoDB 的二级索引到主键模型。

预期收益

减少存储放大 – 无论向量数量如何，文档属性在每个文档中仅存储一次。
降低写入放大 – 重平衡向量不再强制移动完整的文档负载或倒排索引；只需更新 ANN 索引条目。
更大的向量化处理块 – 查询引擎现在可以批量处理数千行以进行聚合、正则表达式和全文评分，从而解锁 SIMD 并提高 CPU 利用率。
改进的查询延迟 – 早期基准测试（例如 FTS v2）显示，一旦发布列表与 ANN 集群解耦，发布列表缩小了 10 倍，查询速度提高了 20 倍；v3 旨在将这些收益扩展到所有查询计划中。

社区反应与类比

gopalv 将此变化比作经典的 Postgres 与 MySQL 的权衡，并指出转向稳定的主键（MySQL 风格）减少了写入侧的放大。
blakeashleyjr 呼应了这一类比，强调阻止索引指向物理存储位置与 Uber 为 PostgreSQL 写入放大所描述的修复方法相同。
Tsarp 强调了 LanceDB 的方法，其中 ANN 是二级索引，行存在于不可变的片段中——这与 turbopuffer v3 的设计直接可比。
marekgalovic 和 gk1 认为“向量数据库”是一个营销术语；真正的转变是放弃以向量为主的存储布局。
sreekanth850 和 peterpanhead 主张在功能齐全的 SQL 引擎内提供原生向量支持，并指出单独的向量存储增加了操作复杂性。

turbopuffer v3 的下一步是什么？

正确性优先 – 团队已在新存储层上实现了 100% 的 CI 通过率。
性能对等 – 随着团队在保持现有 ANN 性能保证的同时优化速度，公共基准测试将在未来几周内发布。
发布计划 – 在达到对等水平后，turbopuffer v3 将部署到生产环境，承诺在大规模下实现更快的向量、文本和聚合查询。

总结

turbopuffer v3 的架构转型——将 ANN 作为二级索引并采用稳定的文档 ID 主键——直接解决了限制非向量查询性能的存储和写入放大问题。通过与经过验证的数据库索引策略保持一致，turbopuffer 旨在在保留其强大 ANN 功能的同时，为所有查询类型提供更快、更具可扩展性的搜索。