turbopuffer v3がベクトルプライマリインデックスを廃止し、セカンダリANNインデックスを採用

TL;DR – turbopuffer v3がベクトルプライマリのストレージレイアウトを廃止

turbopuffer v3では、ANNインデックスをプライマリキーではなくセカンダリ構造にすることで、大幅なストレージと書き込みの増幅を解消しました。これにより、より大きなベクトル化処理ブロックが可能となり、ベクトル検索、全文検索、集計、その他のクエリプランが高速化されます。

turbopufferがストレージアーキテクチャを再設計する理由

turbopufferの当初の設計（v1）では、各ドキュメントを ID + ベクトル として保存し、ANNアドレス（クラスタ + ローカルID）をプライマリキーとして使用していました。これはオブジェクトストレージ上での近似最近傍（ANN）検索において非常に優れた性能を発揮し、1000億以上のベクトルを持つ単一インデックスで、200msのp99レイテンシ、1000 QPS以上を実現していました。

しかし、ベクトルプライマリのレイアウトは、ベクトル以外のワークロードに対して3つの重大な非効率性を生み出します。

ストレージの増幅 – マルチベクトルドキュメント（例：late-interactionモデル）では、各ベクトルが独自のANNアドレスを持つため、すべての属性とテキストのペイロードがベクトルごとに重複して保存されます。
書き込みの増幅 – 挿入、更新、削除のたびにSPFreshによるベクトルの再配置がトリガーされ、ドキュメントの全ペイロードと、古いANNアドレスを指すあらゆる転置インデックスエントリが移動します。
ベクトル化の制限 – 最新のクエリエンジンはデータを大きなブロック（数千行）で処理します。ANNアドレスがブロックサイズ（1クラスタあたり約100〜200ドキュメント）を決定するため、他のすべてのクエリプランはこれらの小さなブロックに強制され、CPUパイプラインを最大限に活用できません。

これらの問題により、turbopufferは属性フィルタリング、全文検索、集計、正規表現クエリにおいて最先端のパフォーマンスを提供できなくなっていました。

turbopufferのクエリ機能の進化

v1 – ID + ベクトルのみ

階層型クラスタリングインデックス（SPANN → SPFresh）が、重心のツリー内にベクトルを保存。
キーは ClusterId + LocalId（例：C0L1）であり、これが ANNアドレス を形成。

v2 – 属性フィルタリングと全文検索

属性値や用語をANNアドレスにマッピングする転置インデックスを追加。
ドキュメント属性をベクトルと同じANNキーの下に保存。
BM25、正規表現、あいまい検索、スパースベクトル、属性による並べ替えをサポート。これらはすべて同じベクトルプライマリレイアウト上に構築。

核心的な問題：ANNをプライマリインデックスとすること

すべてのドキュメントのペイロードがそのANNアドレスの下に存在するため、ベクトルレイアウトを変更すると、関連するすべてのデータが連鎖的に移動せざるを得ません。この設計は、古典的な MySQLスタイル の「プライマリインデックスが直接行を指す」アプローチとは対照的です。MySQLスタイルでは、セカンダリインデックスが安定したプライマリキーを指すため、更新時の大規模な書き換えを回避できます。対照的に、PostgreSQLスタイル の設計では、セカンダリインデックスが物理的な行の場所を直接指すため、読み取り時のルックアップは最適化されますが、書き込みの増幅が激しくなります。

turbopufferの当初の設計は、検索におけるPostgreSQLモデルそのものでした。ANNルックアップのパフォーマンスは優れていますが、書き込みコストが法外であり、他のクエリ形状に対するブロックサイズが制限されていました。

turbopuffer v3の解決策 – ANNをセカンダリインデックスにする

「ANNアドレスをキーにするな」 – turbopuffer v3は、ANNアドレスのプライマリキーを、従来のドキュメントIDプライマリインデックスに置き換えます。ANNインデックスは、InnoDBのセカンダリインデックスからPKを参照するモデルと同様に、ドキュメントIDを指すセカンダリインデックスとして機能するようになります。

期待される利点

ストレージ増幅の削減 – ドキュメント属性は、ベクトルの数に関係なく、ドキュメントごとに1回だけ保存されます。
書き込み増幅の低減 – ベクトルの再配置を行っても、ドキュメントの全ペイロードや転置インデックスを移動させる必要はなく、ANNインデックスのエントリのみを更新すれば済みます。
より大きなベクトル化処理ブロック – クエリエンジンは、集計、正規表現、全文検索のスコアリングのために数千行をバッチ処理できるようになり、SIMDの活用とCPU効率の向上が実現します。
クエリレイテンシの改善 – 初期ベンチマーク（FTS v2など）では、ポスティングリストをANNクラスタから分離することで、リストが10分の1に縮小し、クエリが最大20倍高速化しました。v3では、これらの利点をすべてのクエリプランに拡大することを目指しています。

コミュニティの反応と類似点

gopalv は、この変更を古典的なPostgres対MySQLのトレードオフになぞらえ、安定したプライマリキー（MySQLスタイル）への移行が書き込み側の増幅を低減させると指摘しました。
blakeashleyjr もこの例えに同意し、インデックスが物理的なストレージ場所を指すのをやめることは、UberがPostgreSQLの書き込み増幅に対して説明した修正と同じであると強調しました。
Tsarp は、ANNがセカンダリインデックスであり、行が不変のフラグメント内に存在するLanceDBのアプローチを強調し、turbopuffer v3の設計と直接比較しました。
marekgalovic と gk1 は、「ベクトルデータベース」はマーケティング用語であり、真の転換点はベクトルプライマリのストレージレイアウトを放棄することにあると主張しました。
sreekanth850 と peterpanhead は、個別のベクトルストアは運用上の複雑さを増すため、フル機能のSQLエンジン内でのネイティブなベクトルサポートを提唱しました。

turbopuffer v3の今後の展望

正確性を最優先 – チームは新しいストレージレイヤーで100%のCI通過率を達成しました。
パフォーマンスの同等性 – 既存のANNパフォーマンス保証を維持しつつ速度を最適化しており、今後数週間で公開ベンチマークがリリースされる予定です。
ロールアウト計画 – 同等性に達した後、turbopuffer v3は本番環境にデプロイされ、大規模なベクトル、テキスト、集計クエリの高速化が期待されます。

結論

turbopuffer v3のアーキテクチャの転換（ANNをセカンダリインデックスにし、安定したドキュメントIDプライマリキーを採用すること）は、これまでベクトル以外のクエリパフォーマンスを制限していたストレージと書き込みの増幅に直接対処するものです。実証済みのデータベースインデックス戦略に合わせることで、turbopufferは強力なANN機能を維持しながら、あらゆるクエリタイプにおいてより高速でスケーラブルな検索を提供することを目指しています。