turbopuffer v3 放棄以向量為主（vector-primary）的索引，改採次要 ANN 索引

TL;DR – turbopuffer v3 捨棄了以向量為主的儲存佈局

turbopuffer v3 將 ANN 索引改為次要結構，而非主鍵，這消除了大量的儲存與寫入放大問題，並允許更大的向量化處理區塊，從而加速向量搜尋、全文檢索、聚合運算及其他查詢計畫。

為什麼 turbopuffer 要重新設計其儲存架構

turbopuffer 的原始設計 (v1) 將每個文件儲存為 ID + 向量，並使用 ANN 位址（叢集 + 本地 ID）作為主鍵。這對於物件儲存上的近似最近鄰 (ANN) 搜尋非常有效，能夠在 >1k QPS 下實現 >100B 向量的單一索引，且 p99 延遲低於 200ms。

然而，以向量為主的佈局對於非向量工作負載產生了三個關鍵的低效率問題：

儲存放大 – 多向量文件（例如：後期互動模型）會為每個向量複製所有的屬性和文字負載，因為每個向量都有自己的 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 風格的設計讓次要索引直接指向實體資料列位置，以犧牲嚴重的寫入放大為代價來優化讀取時的查詢。

turbopuffer 的原始設計實際上是搜尋領域的 PostgreSQL 模型：具備出色的 ANN 查詢效能，但對於其他查詢形式而言，寫入成本過高且區塊大小受限。

turbopuffer v3 的解決方案 – 將 ANN 作為次要索引

「不要以 ANN 位址作為鍵值」 – turbopuffer v3 用傳統的文件 ID 主索引取代了 ANN 位址主鍵。現在 ANN 索引的行為就像一個指向文件 ID 的次要索引，類似於 InnoDB 的次要索引指向 PK 的模型。

預期效益

減少儲存放大 – 無論向量數量多少，文件屬性每個文件僅儲存一次。
降低寫入放大 – 重新平衡向量不再需要移動完整的文件負載或倒排索引；僅需更新 ANN 索引條目。
更大的向量化處理區塊 – 查詢引擎現在可以批次處理數千行資料以進行聚合、正規表示式和全文檢索評分，從而釋放 SIMD 並提升 CPU 利用率。
改善查詢延遲 – 早期基準測試（例如 FTS v2）顯示，一旦將發佈列表（posting lists）與 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 能力。