turbopuffer はサーバーレスの検索エンジンとして立ち上げられ、近似最近傍 (ANN) 検索に最適化されたベクトルデータベースとして始動しました。1 兆以上のドキュメントと毎秒 1000 万回以上の書き込みを処理しています。最初の 2 つのバージョンでは、階層クラスタリングインデックス (SPFresh) から導出される ANN アドレスによってキー付けされたすべてのドキュメントデータを格納しており、これにより ANN インデックスがプライマリインデックスとなり、属性フィルタリング、全文検索、その他のクエリプランがその周りで構成されていました。
この画像は turbopuffer のロゴを示しており、記事で議論されているベクトルファーストからセカンダリインデックスへのアーキテクチャ変更を行う企業を表しています。
この設計により、主に 3 つの制限が生じました。ストレージ増幅：マルチベクトルドキュメントでは、各ベクトルの ANN アドレスごとに非ベクトルデータを重複させる必要がありました。書き込み増幅：アップデート時のベクトルの再バランスによって、フルドキュメントおよび関連する属性インデックスと全文検索インデックスの移動を強いられました。ベクトル化の制限：ANN インデックスの最適なクラスターサイズが 100〜200 ドキュメントであるため、その他のクエリプランのブロックサイズが制約され、効率的な CPU 利用が妨げられました。これは turbopuffer v2 で全文検索を固定 256 ドキュメントブロックに再設計されるまで続きました。
turbopuffer v3 では、ドキュメントストレージと ANN インデックスを切り離し、ANN を単なるセカンダリインデージとして扱うことで、各クエリタイプごとに最適なストレージとインデックスを可能にしています。ブログ記事によれば、v3 は継続的インテグレーションで 100% の成功率を達成しており、チームは現在パフォーマンス向上に注力しています。来週以降にパフォーマンスベンチマーク結果を公開し、本番リリースに向けてパフォーマンスパリティを達成し、それを上回ることを目指しています。