Das Unternehmen hinter turbopuffer, einer serverlosen Vektordatenbank, die vor Jahren als spezialisiertes Suchwerkzeug auf den Markt kam, hat angekündigt, sein gesamtes Kernprodukt von Grund auf neu aufzubauen. Es informiert alle darüber. Die Änderung, die das Unternehmen „turbopuffer v3“ nennt, wird die Suche allgemein beschleunigen – einschließlich der Vektorsuche – und den Weg für schnellere SQL-Abfragen ebnen. Das Unternehmen ist nicht subtil, was es aufgibt; es bezeichnet das alte Design mit einem unmissverständlichen Begriff: RIP, Vektordatenbank.
Diese Offenbarung unterscheidet sich von dem, was die meisten Unternehmen tun. Typischerweise hüten Unternehmen ihre interne Architektur sorgfältig, insbesondere bei einer Überarbeitung der Grundlagen. Aber turbopuffer hat beschlossen, die Türen zu öffnen und es den Anhängern zu ermöglichen, den Prozess zu beobachten, während er stattfindet. Das erste Update legt den Grundstein, indem es die Geschichte des Produkts nachzeichnet, von der ersten Version bis zum heutigen Tag.
Von ID und Vektor zu Allem Anderen
Als turbopuffer Version 1 startete, waren Dokumente einfach: eine ID und ein Vektor. Der Vektor repräsentierte Bedeutung, und die ID wies darauf hin. Die Speicherarchitektur basierte auf einem hierarchischen Clustering-Index, der mit SPANN begann und später zu SPFresh migrierte, um inkrementelle Indizierung zu unterstützen. Vektoren wurden in Cluster gruppiert, deren Zentroiden wiederum gruppiert wurden, wodurch ein Baum mit einer einzigen Wurzel entstand.
In der Ankündigung legte das Unternehmen das vollständige Design dar, wobei der Wurzelzentroid am Gipfel thront und absteigende Äste durch Ebenen von Blattzentroiden reichen, die jeweils auf ihre eigenen Vektoren zeigen. Jede Gruppierung erhält eine ClusterId, und jedes Element innerhalb einer Gruppe erhält eine LocalId. Zusammengefügt bilden diese beiden Labels die ANN-Adresse – die Hauptkennung für die gesamte Anordnung.
Die Vektorsuche über Objektspeicher funktionierte zunächst reibungslos, das System erreichte aber schnell seine Grenzen. Als Kunden die Möglichkeit forderten, Attributwerte hinzuzufügen und Suchvorgänge anhand dieser Attribute zu filtern, musste turbopuffer einen Invertierten Index erstellen. Dieser Index verbindet einen Attributwert mit den ANN-Adressen der Dokumente, die ihn enthalten. Das Unternehmen präsentierte mehrere Beispiele dafür, wie dies funktioniert.
K::AttrIndex("family", "Alcidae") -> vec![C0L3, C1L2, C1L3, ...]
K::AttrIndex("genus", "Fratercula") -> vec![C0L3, C1L2, C1L9, ...]
Die Postings selbst wurden zum Ausgangspunkt für die Volltextsuche anstelle der Dokumente, auf die sie verwiesen. Eine Abfrage würde die Postings finden, die ihren Begriff enthalten, und dann würden den Postings Metadaten hinzugefügt, um BM25-Bewertungen zu ermöglichen, einschließlich Begriffshäufigkeiten und Dokumentlängen. Hier ist eine weitere Illustration:
Der Aufruf K::FTS(„description“, „Atlantic“) erzeugt einen Vektor mit Paaren, die jeweils einen Bezeichner wie C0L0 oder C9L4 gefolgt von zwei Werten, darunter 2, 37, 1 und 42, enthalten. Die zweite Zeile, K::Attr(C0L0, „description“), liefert ein einzelnes Ergebnis: „Ein scharf gekleidertes schwarz-weißes Seevogel mit einem riesigen, bunten Schnabel, der Atlantikpuffin wird oft als Clown des Meeres bezeichnet. Er brütet in Burrows auf Inseln im Nordatlantik und verbringt den Winter auf See.“
Warum das Alte Design Bestand hatte
Der primäre Index, der auf dem ANN-Design basiert, erwies sich als äußerst effektiv für die ANN-Suche auf Objektspeicher. Das Unternehmen hat diese Architektur inzwischen erweitert, um einzelne Indizes zu unterstützen, die mehr als 100 Milliarden Vektoren enthalten, mit einer Latenzzeit von 200 Millisekunden für p99-Lesevorgänge und der Verarbeitung von mehr als 1.000 Abfragen pro Sekunde. Aufgrund dessen birgt jede größere Änderung ein reales Risiko, die ANN-Leistung zu beeinträchtigen.
Das Design hielt das Unternehmen hinter den Erwartungen zurück, wenn es um die von ihm unterstützten nicht-vektorbezogenen Abfrageformen geht. Drei wesentliche Probleme stechen hervor: Speichererweiterung, Schreibgeschwindigkeit und begrenzte Vektorisierung.
Der gesamte Inhalt jedes Dokuments befindet sich unterhalb seiner ANN-Adresse, was die Speicherverstärkung verursacht. Mit nur einem Vektor werden die Nicht-Vektordaten nur einmal gespeichert, zusammen damit. Wenn ein Dokument jedoch mehrere Vektoren enthält – durch Dokument-Verschachtelung oder spätere Interaktion – muss das Unternehmen diese Inhalte für jeden Vektor duplizieren. Diese Duplizierung erklärt einige seiner bedauerlicheren Einschränkungen.
SPFresh kann Vektoren neu ausbalancieren, wenn ein Dokument hinzugefügt, geändert oder entfernt wird, um sie gut zu gruppieren. Da alle Dokumentdaten unter Verwendung der ANN-Adresse des Vektors des Dokuments als Schlüssel gespeichert werden, verschiebt diese Neuabwägung den gesamten Dokumentinhalt zusammen mit allen invertierten (Attribut- und FTS-) Indizes, die darauf verweisen.
Der neue primäre Index
Das Unternehmen verschiebt seinen Hauptindex auf einen neuen, während es ANN als „nur einen weiteren“ unterstützenden Index beibehält. Diese Anordnung hat eingeschränkt, wie bestimmte Abfragepläne funktionieren, wie z. B. GROUP BY und Aggregationen. Das Unternehmen hat das Vektor-Primärdesign so weit wie möglich vorangetrieben und ist nun bereit für eine Veränderung.
Diese Änderung beschleunigt die Suche insgesamt, einschließlich der Vektorsuche, für turbopuffer. Außerdem werden die Grundlagen geschaffen, um viel mehr SQL-Abfragen auf turbopuffer zu verschieben und sie mit voller Geschwindigkeit auszuführen. Die Ankündigung präsentiert die Bewegung als einen logischen Schritt vorwärts von turbopuffer v1 zu v2, wobei die Hinzufügung von zwei neuen Abfrageplänen – Attributfilterung und Volltextsuche – die Übergang markiert.
Turbopuffer versorgt die ersten Kunden des Unternehmens, darunter Cursor und Notion, und validierte den Wert dieser Kompromisse. Lineares Synchronisierungsmodul für Aufgaben, die keine Suche beinhalten, während die Abfrageengine gewachsen ist, um alle diese Abfragepläne zu berücksichtigen. Das Speicherdesign ist jedoch weitgehend gleich geblieben.
Was das Unternehmen als Nächstes Baut
Das Unternehmen verschiebt sich jetzt auf seinen neuen Hauptindex. Die Eröffnungsbeschreibung erklärt die Gründe für diese Entscheidung vollständig. Das Unternehmen hält es für eine angenehme Aussicht, die Türen zu öffnen und den Followern zu erlauben, mitzumachen.
Der Vergleich unten zeigt die beiden Architekturen nebeneinander.
| Architektur | Primärer Index | Wesentliche Einschränkung |
|---|---|---|
| Alt (vektor-primär) | ANN-Vektorindex | Speicherverstärkung, Schreibverstärkung, begrenzte Vektorisierung |
| Neu (nicht spezifiziert) | Nicht spezifiziert primär | Nicht angegeben |
Seit ihrer Gründung hat das Unternehmen eine Reihe zusätzlicher Indexierungssysteme und Abfrage-Tools veröffentlicht, darunter Aggregationen, reguläre Ausdruckssuchen, approximatives Matching, sparse Vektorsuche und Attributsortierung – alle mit dem gleichen vektororientierten Speicherdesign im Kern. Der ANN-Primärindex ist bis jetzt weitgehend unverändert geblieben, und das aus einem einfachen Grund: Er funktioniert wirklich, wirklich gut für ANN-Suchen auf Objektspeicher.
Unsere Einschätzung der Ankündigung
Das Unternehmen hat die Kosten des bisherigen Designs und die Gründe für dessen Aufgabe offengelegt. Es war auch ungewöhnlich offen über die Einschränkungen, die seine Wahl prägten.
Das Unternehmen setzt auf die neue Architektur, um schnellere SQL-Abfragen zu liefern, ohne die Geschwindigkeit der Vektorsuche zu beeinträchtigen. Es ist ein großes Wette. Das Unternehmen räumt das Risiko einer Regression bei der ANN-Performance ein, ein Signal dafür, dass das Code-Überholung weit mehr als nur einfach ist.
Die Kunden des Unternehmens nutzen bereits „turbopuffer“ für nicht-Suchzwecke, darunter Linear’s Synchronisierungs-Engine. Das Unternehmen hat seit den frühen Tagen mehrere andere Indexstrukturen und Abfrage-Engines ausgeliefert: Aggregationen, Regex-Suche, Fuzzy-Matching, sparse Vektorsuche und Attributsortierung – alle aufbauend auf dem gleichen vektor-primären Speicherlayout.
Die Erklärung zeigt, dass das Unternehmen über die Grenzen seiner bestehenden Produkte hinausblickt. Der neue Hauptindex wird deutlich mehr SQL-Abfragen verarbeiten können als zuvor.
Das System wurde von frühen Nutzern wie Cursor und Notion übernommen, und es wird aktuell von Linear verwendet, um seinen Synchronisierungs-Engine anzutreiben. Die aktuelle ANN-Performance liegt bei über 100 Milliarden Vektoren, wobei die Lesezeiten bei 200 ms p99 liegen und ein Durchsatz von 1.000+ Abfragen pro Sekunde unterstützt wird. Zu den Abfragefunktionen gehören Vektorsuche, Attributfilterung, Volltextsuche, Aggregationen, Regex-Suche, Fuzzy-Matching, spärliche Vektorsuche und Attributsortierung.
Dieses Unternehmen befindet sich inmitten eines Wandels. Der ursprüngliche Bericht erklärt die Gründe für die Änderung vollständig. Das Unternehmen hält es für angenehm, seine Türen zu öffnen und Followern die Teilnahme zu ermöglichen. Das Unternehmen hat sein vektordominantes Design an seine Grenzen getrieben, und jetzt ist es an der Zeit, weiterzumachen.
Harte Zahlen
- Alte Bauweise: ANN-Vektorindex als primär
- Aktuelle ANN-Größe: Einzelne Indizes, die über 100 Milliarden Vektoren unterstützen
- Latenzzeit: 200 ms p99
- Durchsatz: 1.000+ Abfragen pro Sekunde
- Neue Bauweise: Unspezifizierte primäre Struktur mit ANN als sekundär
- Abfragefunktionen: Vektorsuche, Attributfilterung, Volltextsuche, Aggregationen, Regex-Suche, Fuzzy-Matching, spärliche Vektorsuche, Attributsortierung
Quellenmaterial: „RIP, Vektordatenbank“, turbopuffer.com.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.