Turbopuffer – Schnelle Suchtechnologie auf Objektspeicher

• Ende 2022 wollte Readwise beim Ausbau seiner Infrastruktur Funktionen für Artikelempfehlungen und semantische Suche mit Vektor-Embeddings ergänzen
• Die Kosten für die relationale Datenbank lagen bei 5.000 US-Dollar pro Monat, die Kosten für die Vektorsuche jedoch bei über 20.000 US-Dollar pro Monat, sodass die Umsetzung der Funktion wegen der hohen Kosten aufgegeben wurde
• Bestehende Suchmaschinen sind teuer und schwer zu betreiben: Durch Fortschritte bei Objektspeicher, NVMe-SSDs, KI und Vektortechnologien wird eine neue Suchmaschine benötigt
• Bestehende Vektor-Datenbanken verwenden In-Memory-Speicher und sind dadurch teuer
  • Mit Objektspeicher (S3, GCS) und SSD-Caching lassen sich die Kosten deutlich senken
  • Beispiel: In-Memory-Speicher kostet über 2 US-Dollar/GB, Objektspeicher 0,02 US-Dollar/GB

Das Design von turbopuffer

• Entwicklung einer Suchmaschine für die heutige Zeit
• Erreicht sowohl Kosteneffizienz als auch Leistung durch Objektspeicher und intelligentes Caching
• Kann Dutzende Milliarden Vektoren und mehrere Millionen Tenants verarbeiten
• Auf Objektspeicher basierende Suchmaschine
  • Bestehende Suchmaschinen verwenden die replizierte Disk-Architektur relationaler Datenbanken
  • Suchmaschinen erfordern hohen Schreibdurchsatz und tolerieren lockere Schreiblatenzen
  • Durch Objektspeicher und SSD-/Speicher-Caching werden die Kosten gesenkt, während die Leistung erhalten bleibt
• Native Datenbankimplementierung für Objektspeicher
  • Aufbau einer Datenbank, die standardmäßig auf Objektspeicher setzt
  • Bietet hohe Zuverlässigkeit und unbegrenzte Skalierbarkeit
  • Hohe Verfügbarkeit durch Multi-Tenancy und Sharding
• Kundenbeispiele
  • Cursor: KI-Code-Editor, verwaltet Dutzende Milliarden Vektoren und senkt die Kosten um das Zehnfache
  • Suno: Radiofunktion
  • Dot: Erinnerungsfunktion
  • Shapes: Erinnerungsfunktion

Zusammenfassung von GN⁺

• turbopuffer verbessert die Kosteneffizienz und Leistung von Suchmaschinen deutlich durch Objektspeicher und intelligentes Caching
• Ziel ist es, die hohen Kosten und die schwierige Betriebsführung bestehender Suchmaschinen zu lösen
• Eine neue Suchmaschine wurde passend zu den Fortschritten bei KI- und Vektortechnologien entworfen
• Frühe Kundenbeispiele wie Cursor belegen Kostensenkungen und Leistungsverbesserungen
• Ähnliche Projekte mit vergleichbaren Funktionen sind ElasticSearch und Vector DBs

[GN⁺]

Hacker-News-Kommentare

• Ich habe mit Simon zusammengearbeitet, und er versteht sein Handwerk

  • Wir haben bei Shopify gemeinsam an der Suche gearbeitet und viele Gespräche über den idealen Search-Stack geführt
  • Gewünscht ist ein ideales System, das Ranking in der Cloud über eine Search-API ausdrückt und mithilfe von DataFrame-Mathematik über verschiedene Attribute Boosting ermöglicht

• Es wäre wünschenswert, wenn Turbopuffer wie ein Polars-DataFrame funktionieren würde, sodass sich Ranking in einer Search-API ausdrücken lässt

  • Gewünscht ist die Möglichkeit, mit DataFrame-Mathematik den First Pass auszuführen und anschließend ein Re-Ranking-Modell laufen zu lassen

• Das Website-Design von Fixie.ai gefällt mir ebenfalls sehr gut

  • Fixie.ai ist einer der Kunden von Turbopuffer

• Bei Hetzner kosten RAM-Ressourcen $200/TB/Monat und sind damit 18-mal günstiger als anderswo

  • Wenn man die Komplexität reduziert, kann man das Ziel schneller erreichen

• pg_vector gab es schon vor 2022, und In-Memory-Storage ist nicht erforderlich

  • Vektorsuche kann für mehr als 100 Millionen Dokumente ausgeführt werden

• Ich frage mich, ob es möglich ist, mit Lucene einen Ansatz zu bauen, bei dem SSD-Cache-Nodes vor dem Object Storage stehen

  • Ich habe große Elasticsearch-Deployments erlebt, und es wäre erstaunlich, wenn man alles in S3 ablegen könnte

• Klingt wie eine Closed-Source-Version von Quickwit

  • Quickwit-Link

• Ich frage mich, ob es eine allgemeine Lösung gibt, um große schreibgeschützte Datenbanken in S3 zu speichern und direkt abzufragen

  • DuckDB kann Parquet-Dateien per HTTP öffnen und abfragen, löst dabei aber viele kleine Requests aus
  • Gewünscht sind eine einzelne Datei und ein cachebarer Index, um Millionen von Objekten zu verwalten

• Die Leselatenz von ClickHouse liegt unter 100 ms, die Schreiblatenz unter 1 Sekunde

  • ClickHouse eignet sich auch für Logging, Echtzeit-Analytik und RAG

• Ich kenne mich mit Vektordatenbanken nicht gut aus, glaube aber, dass sie hauptsächlich für RAG und andere KI-bezogene Aufgaben verwendet werden

  • Ich sollte mich tiefer damit beschäftigen

• Ich denke, ein Object-Storage-First-Ansatz passt auf natürliche Weise zur Cloud