AnkündigungWir stellen MongoDB 8.0 vor, das schnellste MongoDB aller Zeiten! Mehr erfahren >
AnkündigungVoyage AI und MongoDB unterstützen ab sofort gemeinsam genauere und vertrauenswürdigere KI-Anwendungen auf Atlas. Mehr erfahren >
Blog home
arrow-left

Neue Benchmark-Tests decken entscheidende Faktoren für die Leistung der Vektorsuche auf

21. August 2025 | Updated: 20. August 2025

Die Suche im großen Maßstab ist eine Herausforderung. So leistungsfähig die Vektorsuche auch ist, kann es schwierig sein, wichtige Faktoren wie Genauigkeit, Kosten und Durchsatz für größere Workloads richtig abzuwägen. Wir haben kürzlich den MongoDB-Benchmark für Atlas Vector Search veröffentlicht, der wichtige Strategien zur Leistungsoptimierung für die Vektorsuche aufzeigt und einen umfassenden Leitfaden für das Erreichen optimaler Ergebnisse mit großen Datensätzen bietet. Das Hauptziel unseres Leitfadens ist es, die Hürden für Ihren ersten Vektortest im großen Maßstab (>10 Mio. Vektoren) bei der Leistungsbewertung für Atlas Vector Search erheblich zu reduzieren.

Mit diesem neuen Leitfaden liefern wir mehr Hintergrundinformationen zur Verwendung des Benchmarks, untersuchen den Datensatz (einschließlich der berücksichtigten Faktoren) und fassen die Ergebnisse zusammen und liefern Kontextinformationen dazu. Schauen wir uns das doch einmal genauer an!

Ein Hinweis zum Benchmarking von Daten

Zu jeder guten Präsentation gehört die obligatorische „Safe-Harbor“-Folie, wobei die Kunst und Wissenschaft des Benchmarkings da keine Ausnahme bildet. Die Umsetzung eines groß angelegten Vektor-Workloads kann erhebliche Hürden mit sich bringen, die auf einen Mangel an genauen Informationen und die mit ersten Benchmarks verbundenen Schwierigkeiten zurückzuführen sind. Zudem entwickelt sich der Bereich der Vektorsuch- und Einbettungsmodelle rasant weiter, sodass Informationen schnell veralten können und Benutzer auf ineffiziente oder falsche Wege geführt werden. Ohne klare, aktuelle Anleitungen können Benutzer Schwierigkeiten haben, das Systemverhalten vorherzusagen, Konfigurationen zu optimieren und Ressourcen sicher zuzuweisen.

Es ist außerdem anzumerken, dass zahlreiche Faktoren (Quantisierung, Dimensionalität, Filterung, Konfiguration der Suchknoten, Parallelität, Sharding und weitere) auf komplexe Weise miteinander interagieren. Das Verständnis dieser Wechselwirkungen und ihrer spezifischen Auswirkungen auf einen bestimmten Workload erfordert tiefgreifende und genaue Erkenntnisse. Ohne dies könnten Benutzer einen Aspekt optimieren und dabei unbeabsichtigt einen anderen verschlechtern.

Dieses Informationsvakuum – in Verbindung mit dem erheblichen Overhead für die Einrichtung, der komplexen Parameteroptimierung und den Kosten für die Experimente, die mit der Durchführung des ersten Benchmarks verbunden sind – stellt eine erhebliche Hürde für die Erprobung und Skalierung einer Lösung dar. Dennoch sind wir der Meinung, dass diese Benchmarks unseren Kunden Vertrauen in die POCs vermitteln und ihnen einen Ausgangspunkt für ihre Arbeit bieten (anstatt dass sie zunächst völlig orientierungslos sind).

Vor dem Hintergrund dieser Faktoren sehen wir uns nun einen Überblick über den Datensatz an.

Ein Blick auf den Datensatz

Im Mittelpunkt dieser Leistungsanalyse stehen Tests, die an Teilmengen des Datensatzes „Amazon Reviews 2023“ durchgeführt wurden, der 48 Millionen Artikelbeschreibungen aus 33 Produktkategorien umfasste. Der Datensatz wurde ausgewählt, da er ein realistisches, groß angelegtes E-Commerce-Szenario bietet und zudem umfangreiche Daten enthält, darunter Benutzerbewertungen (Bewertungen, Text, Hilfreiche-Bewertungen), Artikelmetadaten (Preis, Bilder) sowie detaillierte Artikelnamen und -beschreibungen, die sich ideal für Suchanfragen eignen. Für die Tests mit variabler Dimension wurden Teilmengen von 5,5 Millionen Elementen verwendet, die mit „voyage-3-large“ eingebettet wurden, um 2048-dimensionale Vektoren zu erzeugen.. Anschließend wurden Ansichten erstellt, um diese in 1024-, 512- und 256-dimensionale Vektoren zu zerlegen und so verschiedene Dimensionalitäten zu testen. Für den groß angelegten, hochdimensionalen Test wurde eine Teilmenge mit 15,3 Millionen Elementen verwendet, die ebenfalls mit 2048-dimensionalen Vektoren aus „voyage-3-large“ eingebettet war.

Eine der wichtigsten Erkenntnisse aus dem Bericht ist, dass bei höchster Dimensionalität (15,3 Millionen Vektoren unter Verwendung von „voyage-3-large“-Einbettungen mit 2048 Dimensionen) die Atlas-Vektorsuche mit konfigurierter skalarer oder binärer Quantisierung eine Genauigkeit von 90–95 % bei einer Abfragelatenz von weniger als 50 ms beibehält. Bemerkenswert ist, dass die binäre Quantisierung eine höhere Latenz aufweisen kann, wenn die Anzahl der angeforderten Kandidaten im dreistelligen Bereich liegt, da die Neubewertung mit Vektoren in voller Auflösung zusätzliche Kosten verursacht. Dennoch könnte sie aufgrund ihrer Kosteneffizienz für viele groß angelegte Workloads vorteilhaft sein.

Abbildung mit vier Graphen, die die Leistung der binären Quantisierung im Vergleich zur skalaren Quantisierung darstellen. Der Graph oben links mit dem Titel „limit 10-recall“ zeigt, dass der skalare Recall bei einer geringen Anzahl von Kandidaten höher ist als der binäre, sich die Werte jedoch annähern, wenn die Anzahl der Kandidaten steigt. Der Graph oben rechts mit dem Titel „Limit 100-Recall“ zeigt die gleiche Art von Daten. Der Graph unten links („limit 10-latency“) zeigt, dass beide Verfahren bei niedrigem Recall starten, wobei „binär“ mit steigender Anzahl der Kandidaten deutlich besser abschneidet als „skalar“. Im letzten Graph unten rechts („limit 100-latency“) schneidet „binär“ von einer geringen bis zu einer hohen Anzahl von Kandidaten als die Version mit dem besseren Recall ab.
Abbildung 1. Leistungsvergleich zwischen binärer und skalarer Quantisierung.

Methodik: Benchmarking mit dem Amazon-Bewertungsdatensatz

Nachdem wir nun ein wenig über die Daten selbst und die darin enthaltenen Informationen gesprochen haben, wollen wir einige der wichtigsten Faktoren skizzieren, die die Leistung von Atlas Vector Search beeinflussen, und erläutern, wie wir unseren Benchmark konfiguriert haben, um diese zu testen. Es ist auch wichtig zu verstehen, warum diese Variablen kritisch sind: Nicht jeder Kunde wird seine Suche auf die gleiche Weise optimieren. Vor diesem Hintergrund werden wir auch versuchen, das Zusammenspiel und die Zielkonflikte zwischen ihnen zu ermitteln.

Auch wenn diese Liste nicht vollständig ist (weitere Einzelheiten finden Sie im kompletten Bericht), sehen wir uns doch einige der wichtigsten Leistungsfaktoren an:

  • Recall: Der Recall (ein Maß für die Suchgenauigkeit) wird durch die Quantisierung und die Vektordimensionalität erheblich beeinflusst. Der Bericht hebt hervor, dass die skalare Quantisierung zwar im Allgemeinen mit einem höheren Recall beginnt, die binäre Quantisierung jedoch durch Erhöhung von „numCandidates“ ähnliche Genauigkeitsniveaus erreichen kann, was allerdings aufgrund eines zusätzlichen Rescoring-Schritts oft mit einer höheren Latenz einhergeht. Darüber hinaus weisen höherdimensionale Vektoren (1024d und 2048d) im Vergleich zu niedrigeren Dimensionen (256d und 512d) – bei denen der Recall kaum über 70–80 % hinausgeht – durchweg einen besseren Recall auf, insbesondere bei größeren Datensätzen und bei Quantisierung.

  • Dimensionierung und Kosten: Die Tabelle im Benchmark gibt einen Überblick über die erforderlichen Ressourcen (RAM, Speicherplatz) und die damit verbundenen Kosten für verschiedene Suchknoten-Ebenen auf der Grundlage von drei unterschiedlichen Testfällen mit variierenden Datensatzgrößen, Vektordimensionen und Quantisierungsmethoden (skalar oder binär). Der Leitfaden enthält ein Beispiel für einen Beispieldatensatz, aus dem hervorgeht, dass der Ressourcenbedarf linear skaliert und die Quantisierung den Speicherbedarf erheblich reduziert.

  • Parallelität und Durchsatz: Der Durchsatz wird bei parallel ausgeführten Anforderungen bewertet. Die skalare Quantisierung erzielt im Allgemeinen höhere Abfragen pro Sekunde (QPS) über verschiedene Grenzwerte hinweg, da pro Abfrage weniger Arbeit anfällt und keine Neubewertung erforderlich ist. Engpässe bei der Parallelität werden häufig beobachtet, was darauf hindeutet, dass eine höhere Latenz auftreten kann. Es wird empfohlen, die Anzahl der Suchknoten zu skalieren oder die verfügbaren vCPUs zu erhöhen, um diese Engpässe zu beheben und höhere QPS zu erzielen.

Abbildung einer Tabelle, in der die Knotenebenen für verschiedene Testfälle dargestellt sind. Die erste Spalte enthält den Testfall, die zweite Spalte die erforderlichen Ressourcen (RAM, Speicherplatz), die dritte Spalte die RAM-, Festplatten- und vCPU-Ressourcen der Suchknoten-Ebene und die letzte Spalte den Preis für 2 Knoten. Die erste Zeile bezieht sich auf den Testfall mit mittlerem Datensatz (5,5 Mio. Vektoren, alle Dimensionen) und skalarer Quantisierung. Der Ressourcenbedarf beträgt 22, 104,5 GB, der Arbeitsspeicher der Suchknoten-Ebene ist „s50-storage-optimized“ mit 32 GB, 843 GB und 4 vCPUs, und der Preis liegt bei 1,04 $/Stunde. Die zweite Zeile bezieht sich auf den Testfall mit einem mittelgroßen Datensatz (5,5 Mio. Vektoren, alle Dimensionen) und binärer Quantisierung. Der Ressourcenbedarf beträgt 3,43 RAM und 104,5 GB Speicherplatz; die Suchknoten-Ebene ist „s30-high-cpu“ mit 8 GB, 213 GB und 4 vCPUs; der Preis beträgt 0,24 $/Stunde. Die dritte Zeile bezieht sich auf den Testfall mit großem Datensatz (15,3 Mio. Vektoren, 2048 Dimensionen) und skalarer Quantisierung; der Ressourcenbedarf beträgt 32,64 RAM und 155,04 GB Speicherplatz; die Suchknoten-Ebene ist „s50-storage-optimized“ mit 32 GB, 843 GB und 4 vCPUs; der Preis beträgt 1,04 $/Stunde. Der Testfall in der vierten Zeile umfasst einen großen Datensatz (15,3 Millionen Vektoren, 2048 Dimensionen) mit binärer Quantisierung; der Ressourcenbedarf beträgt 5,1 RAM und 155,04 GB Speicherplatz; die Suchknoten-Ebene ist „s30-high-cpu“ mit 8 GB, 213 GB und 4 vCPUs; der Preis beträgt 0,24 $/Stunde.
Abbildung 2: Knotenebenen für verschiedene Testfälle.

Optimierung der Leistung Ihrer Vektorsuche

Dieser Benchmark-Bericht untersucht eingehend die Leistung von MongoDB Atlas Vector Search in verschiedenen Konfigurationen und mit großen Datensätzen, insbesondere mit dem Datensatz „Amazon Reviews 2023“. Es untersucht die Auswirkungen von Faktoren wie Quantisierung (skalar und binär), Vektordimensionalität, Filterung, Konfigurationen von Suchknoten, binData-Komprimierung, Parallelität und Sharding auf Recall, Latenz und Durchsatz.

Zwar gibt es keine „Patentlösung“, da jeder eine andere Vorstellung davon hat, was „Erfolg“ bei der Suche bedeutet, doch wollten wir einige der verschiedenen Hebel und Methoden aufzeigen, die Sie berücksichtigen sollten, um das Beste aus Ihrer eigenen Implementierung herauszuholen. Unser Ziel ist es, Ihnen einige wichtige Überlegungen zur Bewertung und Verbesserung der Leistung Ihrer eigenen Vektorsuche an die Hand zu geben und Ihnen dabei zu helfen, die entscheidenden Faktoren richtig abzuwägen und in den richtigen Kontext zu setzen. Bereit zur Optimierung Ihrer Vektorsuche?

megaphone

Erkunden Sie den Leitfaden in unserer Dokumentation.

Führen Sie ihn selbst mit unserem GitHub-Repository aus.

MongoDB-Ressourcen
Atlas Learning Hub|Fallstudien von Kunden|KI-Lernhub|Dokumentation|MongoDB University