100 Milliarden Vektoren in einem Index, 200 Millisekunden p99-Latenz bei über 1.000 Abfragen pro Sekunde — mit diesen Zahlen hat turbopuffer seine Speicherarchitektur lange verteidigt. Jetzt wird sie umgebaut. In einem technischen Bericht beschreibt Dan Harrison, Engineer bei turbopuffer, warum der ANN-Index seinen Rang als Primärindex verliert und nur noch ein Sekundärindex unter vielen sein soll.
Wer heute eine Vektordatenbank auswählt, schaut meist auf Latenz und Preis pro Million Vektoren. Der Bericht zeigt, dass die wichtigere Frage woanders liegt: Welche Datenstruktur bestimmt das Layout, und was passiert, wenn eine Datenbank mehr können muss als reine Ähnlichkeitssuche? Das hier ist keine Produktankündigung, sondern eine Zwischenbilanz aus einem laufenden Umbau — inklusive der Stellen, an denen es noch hakt.
Von einer ID und einem Vektor zur geclusterten Ablage auf Objektspeicher
In der ersten Version von turbopuffer bestanden Dokumente nur aus einer ID und einem Vektor. Der damals übliche Ansatz waren graphenbasierte Vektorindizes, doch die vertragen sich schlecht mit Objektspeicher als Quelle der Wahrheit. Das Team setzte stattdessen auf einen hierarchischen Clustering-Index, zunächst SPANN, später SPFresh, um auch inkrementelles Indexieren zu ermöglichen. Vektoren werden dabei in Gruppen zusammengefasst, deren Zentroide wiederum geclustert werden — so oft, bis ein Baum mit einer einzigen Wurzel entsteht.
Umgesetzt ist das auf einer Speicherschicht, die sortierte, eindeutige Schlüssel-Wert-Paare speichert. Jeder Cluster bekommt eine ClusterId, jeder Vektor darin eine LocalId; zusammen bilden sie die ANN-Adresse. Alles, was zu einem Dokument gehört, liegt unter dieser Adresse. Man kann sich das wie eine Lagerhalle vorstellen, in der jedes Dokument seine Signatur nach dem Regalplatz erhält, an dem es steht. Die Adresse ist also nicht nur Fundstelle, sondern Ordnungsprinzip. Deshalb heißt der ANN-Index der Primärindex.
Attributfilterung und BM25-Volltextsuche als nachgerüstete Zweitindizes
Der Übergang zu v2 war informell und wurde durch zwei neue Abfragetypen markiert. Kunden wollten Attributwerte speichern und Vektorsuchen danach filtern. Damit das schnell und mit hoher Trefferquote funktioniert, modelliert turbopuffer diese Attributfilterung als invertierten Index, der einen Attributwert auf die ANN-Adressen der zugehörigen Dokumente abbildet. Für Projektionen wurden die Attributwerte zusätzlich neben ID und Vektor abgelegt.
Die BM25-Volltextsuche folgt demselben Muster. Sie sucht zuerst die Dokumente, in denen der Suchbegriff vorkommt, und ergänzt die für die BM25-Bewertung nötigen Angaben wie Begriffshäufigkeit und Dokumentlänge. Später kamen Aggregationen, Regex-Suche, Fuzzy-Matching, Sparse-Vektor-Suche und Attribut-Sortierung hinzu. All diese Abfragepläne hängen aber weiterhin an der Ablage, die um den ANN-Index herum gebaut ist. Darin liegt das Problem.
Speicherverstärkung und Schreibverstärkung: der Preis der ANN-Adresse als Schlüssel
Solange ein Dokument nur einen Vektor hat, arbeitet diese Ablage effizient. Sobald ein Dokument jedoch durch mehrere Vektoren repräsentiert wird — etwa bei verschachtelten Dokumenten oder Late-Interaction-Modellen —, landet der komplette Inhalt unter jeder dieser Adressen. Der Bericht nennt das Speicherverstärkung und führt darauf einige der unangenehmsten Limitierungen des Systems zurück.
Schwerer wiegt die Schreibverstärkung. Jede Einfüge-, Änderungs- oder Löschoperation kann SPFresh dazu veranlassen, Vektoren neu zu balancieren, damit die Cluster sauber bleiben und die Recall-Werte nicht einbrechen. Weil die vollständigen Dokumentinhalte und die invertierten Indizes an der ANN-Adresse hängen, wandert bei so einer Umsortierung alles mit. Das Ändern eines einzigen Vektors kann Hunderte Attribute und deren Indizes verschieben. Die Versuche, den Durchsatz beim Indexieren weiter zu steigern, stoßen laut Harrison inzwischen an abnehmende Erträge.
Blockgrößen: Warum die Vektorisierung an Clustergrenzen hängt
Moderne Abfrage-Engines arbeiten vektorisiert, sie laufen in engen Schleifen über Blöcke von Werten. Das amortisiert feste Kosten pro Block, komprimiert besser, hält die CPU-Pipeline gefüllt und öffnet die Tür zu SIMD. DuckDB arbeitet in Stapeln von 2.048 Zeilen, ClickHouse bis etwa 65.000, Lucenes Posting-Blöcke fassen 256 Dokumente. Der ANN-Index von turbopuffer funktioniert am besten mit Clustern von 100 bis 200 Dokumenten.
Weil die ANN-Adresse der Primärschlüssel ist, müssen sich alle anderen Abfragepläne dieser Größe unterwerfen. Ein Plan, der Blöcke mit Tausenden Dokumenten bräuchte, bleibt bei 100 bis 200 hängen. Wie viel das ausmacht, zeigt die Volltextsuche: In der ersten Version folgten die Posting-Listen den Clustergrenzen, der mittlere Block enthielt rund 1,5 Einträge. Mit festen Blöcken von etwa 256 Einträgen wurde der Index zehnmal kleiner und die Abfragen bis zu zwanzigmal schneller. Posting-Listen konnten das, weil sie getrennt liegen und auf Dokumente zeigen. Aggregationen und andere Scans lesen dagegen die Dokumente selbst, und die liegen weiterhin ein Block pro Cluster.
turbopuffer v3: nicht mehr auf die ANN-Adresse schlüsseln
Die Lösung lässt sich in einem Satz sagen, ist aber schwer umzusetzen: nicht mehr auf die ANN-Adresse schlüsseln. Das macht turbopuffer v3, die neue Speicherarchitektur. Der ANN-Index wird zu einem Sekundärindex unter anderen, das Dokument selbst bekommt eine eigene, stabile Identität. Damit lösen sich die drei Probleme strukturell, statt einzeln wegoptimiert zu werden. Der ANN-Index bleibt wichtig, bestimmt aber nicht mehr das Layout des ganzen Systems.
Ein erster Meilenstein steht: Seit Anfang des Monats laufen 100 Prozent der CI-Tests auf v3 durch. Allerdings fällt die neue Engine in der Leistung noch deutlich hinter die Produktionsversion zurück, was niemanden überraschen dürfte. Bisher ging es um grundlegendes Design und Korrektheit, mit dem Feintuning wurde gerade erst begonnen. Der Bericht ist als Auftakt einer Reihe angelegt, die den Umbau und seine Optimierungen begleiten soll.
Was der Umbau für den Betrieb bedeutet
Wer eine Vektordatenbank betreibt, merkt von einem solchen Umbau zunächst wenig. Entscheidend ist die Frage, welche Abfragetypen die Datenbank künftig ohne Umweg bedienen kann. Ein Dokument, das unabhängig von seinem Vektor eine stabile Adresse hat, erlaubt es, ANN-Index, BM25-Volltextsuche, Attributfilterung und Aggregationen jeweils in ihrer eigenen optimalen Blockgröße abzulegen. Erst damit taugt eine Vektordatenbank auch als Suchdatenbank im allgemeinen Sinn.
Zur Größenordnung: turbopuffer hostet nach eigenen Angaben über eine Billion Dokumente, verarbeitet mehr als zehn Millionen Schreibvorgänge pro Sekunde und bedient über 25.000 Abfragen pro Sekunde. Ob dieselbe Leistung mit dem neuen Layout gelingt, entscheidet sich in den kommenden Monaten. Wer einen Wechsel erwägt, sollte die Benchmark-Zahlen beobachten: Die alte Architektur hat ihre Grenze erreicht, die neue ist noch nicht so weit.
Quelle: turbopuffer.com
