Contexte et évolution de Turbopuffer

Le service Turbopuffer a débuté avec une architecture dite v1 où chaque document ne contenait qu’un ID et un vecteur. L’index principal était un arbre hiérarchique de centroids, implémenté d’abord avec SPANN puis migré vers SPFresh pour permettre l’indexation incrémentale. Cette structure reposait sur un stockage clé‑valeur où chaque vecteur était adressé par un ClusterId et un LocalId (ex. C0L1), ce que l’équipe désigne comme « adresse ANN ».

// leaf vectors
K:: Vector (C0L0) = vec! [ 0.45 , 0.32 , ...]
K:: Id (C0L0) = 7
K:: Vector (C0L1) = vec! [-0.28 , 0.96 , ...]
K:: Id (C0L1) = 13

La version v2 a introduit deux nouveaux plans de requête : le filtrage d’attributs et la recherche plein texte (BM25). Le filtrage s’appuie sur un index inversé qui associe chaque valeur d’attribut à l’adresse ANN du document ; la recherche plein texte stocke, pour chaque terme, le tuple (adresse ANN, fréquence, longueur du document).

// attribut index
K:: AttrIndex ("family", "Alcidae") -> vec![C0L3, C1L2, ...]
// FTS index
K:: FTS ("description", "Atlantic") -> vec![(C0L0, 2, 37), (C9L4, 1, 42), ...]

Limites de l’index ANN primaire

Malgré son succès (plus de 100 milliards de vecteurs servis avec un temps de lecture p99 de 200 ms à plus de 1 k QPS), l’index ANN reste le goulot d’étranglement pour les requêtes non‑vectorielles. Trois problèmes majeurs sont identifiés : amplification du stockage, amplification des écritures et vectorisation limitée. L’amplification du stockage apparaît lorsqu’un même document possède plusieurs vecteurs ; chaque vecteur duplique l’ensemble des métadonnées et du texte, ce qui conduit à des limites de capacité observées par les utilisateurs. L’amplification des écritures résulte du rééquilibrage de SPFresh : toute mise à jour d’un vecteur peut entraîner le déplacement de centaines de clés associées, y compris les index inversés d’attributs et de texte, augmentant ainsi le coût I/O. Enfin, la conception actuelle ne profite pas pleinement des instructions SIMD modernes, limitant la vitesse de calcul des distances.

Nouvelle architecture v3

Le projet « turbopuffer v3 » propose de renverser la hiérarchie des index : l’ANN devient un index secondaire, tandis qu’un nouveau index primaire, encore non nommé, gérera les documents de façon plus générique. Cette refonte implique de séparer les données vectorielles des métadonnées, réduisant ainsi la duplication lors de l’utilisation de représentations multi‑vecteurs. Le nouveau moteur stockera les attributs et le texte de façon indépendante, ce qui diminue l’amplification du stockage et limite les déplacements massifs lors d’une mise à jour. En outre, l’architecture sera conçue pour exploiter les pipelines SIMD et les caches NVMe/DRAM, améliorant la vectorisation des calculs de distance.

Implications et défis

Passer d’un index ANN primaire à un modèle multi‑index soulève plusieurs défis. D’abord, il faut garantir que les performances de recherche ANN ne se dégradent pas ; les tests internes visent à maintenir le même seuil de 200 ms p99 pour 100 B+ vecteurs. Ensuite, la cohérence entre les index secondaires (ANN, attribut, FTS) doit être assurée lors des opérations de rééquilibrage, ce qui nécessite des protocoles de transaction plus sophistiqués. Enfin, la migration des bases existantes vers v3 devra être effectuée sans interruption de service, probablement via une réplication en lecture‑écriture progressive. Si ces contraintes sont maîtrisées, Turbopuffer pourra proposer une gamme plus large de plans de requête à grande échelle tout en conservant son modèle économique basé sur le stockage objet et les caches NVMe.