Ankündigung von VDBBench 1.0: Open-Source-VectorDB-Benchmarking mit Ihren realen Produktions-Workloads
Die meisten Benchmarks für Vektordatenbanken testen mit statischen Daten und vorab erstellten Indizes. Produktionssysteme funktionieren jedoch nicht so – Daten fließen kontinuierlich, während Nutzer Abfragen ausführen, Filter Indizes fragmentieren und sich Leistungsmerkmale unter gleichzeitigen Lese-/Schreiblasten dramatisch verändern.
Heute veröffentlichen wir VDBBench 1.0, einen Open-Source-Benchmark, der von Grund auf dafür entwickelt wurde, Vektordatenbanken unter realistischen Produktionsbedingungen zu testen: Streaming-Dateningestion, Metadatenfilterung mit variierender Selektivität und gleichzeitige Workloads, die tatsächliche Systemengpässe aufdecken.
VDBBench 1.0 herunterladen → | Leaderboard ansehen →
Warum aktuelle Benchmarks irreführend sind
Seien wir ehrlich – in unserer Branche gibt es ein merkwürdiges Phänomen. Alle sprechen davon, „Benchmarks nicht zu manipulieren“, und doch beteiligen sich viele genau an diesem Verhalten. Seit der Markt für Vektordatenbanken 2023 explodiert ist, haben wir zahlreiche Beispiele für Systeme gesehen, die „in Benchmarks hervorragend abschneiden“, aber in der Produktion „kläglich scheitern“, wodurch Entwicklungszeit verschwendet und die Glaubwürdigkeit von Projekten beschädigt wird.
Wir haben diese Diskrepanz aus erster Hand erlebt. Elasticsearch beispielsweise wirbt mit Abfragegeschwindigkeiten im Millisekundenbereich, doch im Hintergrund kann es über 20 Stunden dauern, nur um den Index zu optimieren. Welches Produktionssystem kann eine solche Ausfallzeit tolerieren?
Das Problem beruht auf drei grundlegenden Schwächen:
Veraltete Datensätze: Viele Benchmarks verlassen sich noch immer auf Legacy-Datensätze wie SIFT (128 Dimensionen), während moderne Embeddings zwischen 768 und 3.072 Dimensionen liegen. Die Leistungsmerkmale von Systemen, die mit 128D- gegenüber 1024D+-Vektoren arbeiten, unterscheiden sich grundlegend – Speicherzugriffsmuster, Indexeffizienz und Rechenkomplexität verändern sich alle dramatisch.
Eitelkeitsmetriken: Benchmarks konzentrieren sich auf durchschnittliche Latenz oder Spitzen-QPS und erzeugen dadurch ein verzerrtes Bild. Ein System mit 10 ms durchschnittlicher Latenz, aber 2 Sekunden P99-Latenz schafft eine schreckliche Nutzererfahrung. Der über 30 Sekunden gemessene Spitzendurchsatz sagt Ihnen nichts über die nachhaltige Leistung.
Zu stark vereinfachte Szenarien: Die meisten Benchmarks testen grundlegende Workflows nach dem Muster „Daten schreiben, Index erstellen, abfragen“ – im Grunde Tests auf „Hello World“-Niveau. Die reale Produktion umfasst kontinuierliche Dateningestion während der Bedienung von Abfragen, komplexe Metadatenfilterung, die Indizes fragmentiert, und gleichzeitige Lese-/Schreiboperationen, die um Ressourcen konkurrieren.
Was ist neu in VDBBench 1.0?
VDBBench iteriert nicht einfach über veraltete Benchmarking-Philosophien – es baut das Konzept von Grund auf neu auf, mit einer leitenden Überzeugung: Ein Benchmark ist nur dann wertvoll, wenn er das tatsächliche Produktionsverhalten vorhersagt.
Wir haben VDBBench so entwickelt, dass es reale Bedingungen über drei kritische Dimensionen hinweg zuverlässig nachbildet: Datenauthentizität, Workload-Muster und Methoden zur Leistungsmessung.
Werfen wir einen genaueren Blick darauf, welche neuen Funktionen geboten werden.
🚀 Neu gestaltetes Dashboard mit produktionsrelevanten Visualisierungen
Die meisten Benchmarks konzentrieren sich nur auf die Ausgabe von Rohdaten, doch entscheidend ist, wie Engineers diese Ergebnisse interpretieren und darauf reagieren. Wir haben die Benutzeroberfläche neu gestaltet, um Klarheit und Interaktivität in den Vordergrund zu stellen – damit Sie Leistungslücken zwischen Systemen erkennen und schnelle Infrastrukturentscheidungen treffen können.
Das neue Dashboard visualisiert nicht nur Leistungskennzahlen, sondern auch die Beziehungen zwischen ihnen: wie QPS bei unterschiedlichen Filterselektivitätsstufen abnimmt, wie Recall während der Streaming-Ingestion schwankt und wie Latenzverteilungen Stabilitätsmerkmale des Systems offenlegen.
VDBbench dashboard
Wir haben große Vektordatenbank-Plattformen einschließlich Milvus, Zilliz Cloud, Elastic Cloud, Qdrant Cloud, Pinecone und OpenSearch mit ihren neuesten Konfigurationen und empfohlenen Einstellungen erneut getestet, um sicherzustellen, dass alle Benchmark-Daten die aktuellen Fähigkeiten widerspiegeln. Alle Testergebnisse sind im VDBBench Leaderboard verfügbar.
🏷️ Tag-Filtering: Der versteckte Performance-Killer
Abfragen in der realen Welt erfolgen selten isoliert. Anwendungen kombinieren Vektorähnlichkeit mit Metadaten-Filtering („finde Schuhe, die wie dieses Foto aussehen, aber weniger als 100 $ kosten“). Diese gefilterte Vektorsuche schafft einzigartige Herausforderungen, die die meisten Benchmarks vollständig ignorieren.
Gefilterte Suchen führen in zwei kritischen Bereichen zu Komplexität:
Filter Complexity: Mehr skalare Felder und komplexe logische Bedingungen erhöhen die Rechenanforderungen und können zu unzureichendem Recall und Fragmentierung des Graph-Index führen.
Filter Selectivity: Dies ist der „versteckte Performance-Killer“, den wir in der Produktion wiederholt bestätigt haben. Wenn Filterbedingungen hochselektiv werden (99 %+ der Daten herausfiltern), können die Abfragegeschwindigkeiten um Größenordnungen schwanken, und der Recall kann instabil werden, da Indexstrukturen mit spärlichen Ergebnismengen zu kämpfen haben.
VDBBench testet systematisch verschiedene Filterselektivitätsstufen (von 50 % bis 99,9 %) und liefert ein umfassendes Performance-Profil unter diesem kritischen Produktionsmuster. Die Ergebnisse zeigen oft dramatische Performance-Klippen, die in traditionellen Benchmarks niemals sichtbar würden.
Beispiel: In Cohere-1M-Tests hielt Milvus über alle Filterselektivitätsstufen hinweg konstant hohen Recall aufrecht, während OpenSearch eine instabile Performance zeigte, bei der der Recall unter verschiedenen Filterbedingungen erheblich schwankte—und in vielen Fällen unter 0,8 Recall fiel, was für die meisten Produktionsumgebungen inakzeptabel ist.
Abbildung: QPS und Recall von Milvus und OpenSearch über verschiedene Filterselektivitätsstufen hinweg (Cohere-1M-Test).
🌊 Streaming-Lesen/Schreiben: Über statisches Index-Testing hinaus
Produktionssysteme genießen selten den Luxus statischer Daten. Neue Informationen fließen kontinuierlich ein, während Suchen ausgeführt werden—ein Szenario, in dem viele ansonsten beeindruckende Datenbanken unter dem doppelten Druck zusammenbrechen, die Such-Performance aufrechtzuerhalten und gleichzeitig kontinuierliche Schreibvorgänge zu verarbeiten.
Die Streaming-Szenarien von VDBBench simulieren echte parallele Operationen und helfen Entwicklern, die Systemstabilität in Umgebungen mit hoher Nebenläufigkeit zu verstehen, insbesondere wie das Schreiben von Daten die Abfrage-Performance beeinflusst und wie sich die Performance entwickelt, wenn das Datenvolumen zunimmt.
Um faire Vergleiche zwischen verschiedenen Systemen sicherzustellen, verwendet VDBBench einen strukturierten Ansatz:
Kontrollierte Schreibraten konfigurieren, die Ziel-Produktionsworkloads widerspiegeln (z. B. 500 Zeilen/Sek. verteilt auf 5 parallele Prozesse)
Suchoperationen nach jeweils 10 % der Datenaufnahme auslösen, abwechselnd im seriellen und gleichzeitigen Modus
Umfassende Metriken aufzeichnen: Latenzverteilungen (einschließlich P99), nachhaltige QPS und Recall-Genauigkeit
Die Performance-Entwicklung im Zeitverlauf verfolgen, während Datenvolumen und Systembelastung zunehmen
Dieses kontrollierte, inkrementelle Lasttesting zeigt, wie gut Systeme Stabilität und Genauigkeit bei laufender Aufnahme aufrechterhalten—etwas, das traditionelle Benchmarks selten erfassen.
Beispiel: In Cohere-10M-Streaming-Tests hielt Pinecone im Vergleich zu Elasticsearch während des gesamten Schreibzyklus höhere QPS und höheren Recall aufrecht. Bemerkenswerterweise verbesserte sich die Performance von Pinecone nach Abschluss der Aufnahme deutlich, was eine starke Stabilität unter anhaltender Last demonstriert, während Elasticsearch während aktiver Aufnahmephasen ein unregelmäßigeres Verhalten zeigte.
Abbildung: QPS und Recall von Pinecone vs. Elasticsearch im Cohere-10M-Streaming-Test (Aufnahmerate 500 Zeilen/s).
VDBBench geht noch weiter, indem es einen optionalen Optimierungsschritt unterstützt, der es Nutzern ermöglicht, die Streaming-Suchleistung vor und nach der Indexoptimierung zu vergleichen. Außerdem verfolgt und meldet es die tatsächlich für jede Phase aufgewendete Zeit und bietet so tiefere Einblicke in die Systemeffizienz und das Verhalten unter produktionsähnlichen Bedingungen.
Abbildung: QPS und Recall von Pinecone vs. Elasticsearch im Cohere-10M-Streaming-Test nach der Optimierung (Ingestionsrate von 500 Zeilen/s)
Wie unsere Tests zeigen, übertraf Elasticsearch Pinecone bei QPS—nach der Indexoptimierung. Wenn die x-Achse jedoch die tatsächlich verstrichene Zeit widerspiegelt, wird deutlich, dass Elasticsearch deutlich länger brauchte, um diese Leistung zu erreichen. In der Produktion spielt diese Verzögerung eine Rolle. Dieser Vergleich offenbart einen zentralen Zielkonflikt: Spitzendurchsatz vs. Time-to-Serve.
🔬 Moderne Datensätze, die aktuelle KI-Workloads widerspiegeln
Wir haben die für das Benchmarking von Vektordatenbanken verwendeten Datensätze vollständig überarbeitet. Statt veralteter Testsets wie SIFT und GloVe verwendet VDBBench Vektoren, die von hochmodernen Embedding-Modellen wie OpenAI und Cohere generiert werden, die heutige KI-Anwendungen antreiben.
Um Relevanz sicherzustellen, insbesondere für Anwendungsfälle wie Retrieval-Augmented Generation (RAG), haben wir Korpora ausgewählt, die reale Unternehmens- und domänenspezifische Szenarien widerspiegeln:
| Korpus | Embedding-Modell | Dimensionen | Größe | Anwendungsfall |
|---|---|---|---|---|
| Wikipedia | Cohere V2 | 768 | 1M / 10M | Allgemeine Wissensbasis |
| BioASQ | Cohere V3 | 1024 | 1M / 10M | Domänenspezifisch (biomedizinisch) |
| C4 | OpenAI | 1536 | 500K / 5M | Web-Scale-Textverarbeitung |
| MSMarco V2 | udever-bloom-1b1 | 1536 | 1M / 10M / 138M | Suche in großem Maßstab |
Diese Datensätze simulieren die heutigen hochvolumigen, hochdimensionalen Vektordaten besser und ermöglichen realistische Tests der Speichereffizienz, Abfrageleistung und Abrufgenauigkeit unter Bedingungen, die modernen KI-Workloads entsprechen.
⚙️ Unterstützung für benutzerdefinierte Datensätze für branchenspezifische Tests
Jedes Unternehmen ist einzigartig. Die Finanzbranche benötigt möglicherweise Tests, die auf Transaktions-Embeddings ausgerichtet sind, während soziale Plattformen stärker an Vektoren zum Nutzerverhalten interessiert sind. Mit VDBBench können Sie Benchmarks mit Ihren eigenen Daten durchführen, die aus Ihren spezifischen Embedding-Modellen für Ihre spezifischen Workloads generiert wurden.
Sie können anpassen:
Vektordimensionen und Datentypen
Metadatenschema und Filtermuster
Datenvolumen und Ingestionsmuster
Abfrageverteilungen, die Ihrem Produktions-Traffic entsprechen
Schließlich erzählt kein Datensatz eine bessere Geschichte als Ihre eigenen Produktionsdaten.
Wie VDBBench misst, was in der Produktion wirklich zählt
Produktionsorientiertes Metrikdesign
VDBBench priorisiert Metriken, die reale Leistung widerspiegeln, nicht nur Laborergebnisse. Wir haben das Benchmarking rund um das neu gestaltet, was in Produktionsumgebungen wirklich zählt: Zuverlässigkeit unter Last, Eigenschaften der Tail-Latenz, nachhaltiger Durchsatz und Erhaltung der Genauigkeit.
P95/P99-Latenz für echte Nutzererfahrung: Durchschnittliche/mediane Latenz verschleiert die Ausreißer, die echte Nutzer frustrieren und auf zugrunde liegende Systeminstabilität hinweisen können. VDBBench konzentriert sich auf Tail-Latenz wie P95/P99 und zeigt auf, welche Leistung 95 % oder 99 % Ihrer Abfragen tatsächlich erreichen werden. Dies ist entscheidend für die SLA-Planung und das Verständnis der schlechtesten Nutzererfahrung.
Nachhaltiger Durchsatz unter Last: Ein System, das 5 Sekunden lang gut funktioniert, reicht in der Produktion nicht aus. VDBBench erhöht schrittweise die Parallelität, um die maximal nachhaltigen Abfragen pro Sekunde (
max_qps) Ihrer Datenbank zu ermitteln—nicht den Spitzenwert unter kurzen, idealen Bedingungen. Diese Methodik zeigt, wie gut Ihr System über die Zeit standhält, und hilft bei einer realistischen Kapazitätsplanung.Recall im Gleichgewicht mit Performance: Geschwindigkeit ohne Genauigkeit ist bedeutungslos. Jede Performance-Zahl in VDBBench wird mit Recall-Messungen kombiniert, sodass Sie genau wissen, wie viel Relevanz Sie für Durchsatz eintauschen. Dies ermöglicht faire, direkte Vergleiche zwischen Systemen mit sehr unterschiedlichen internen Kompromissen.
Testmethodik, die die Realität widerspiegelt
Eine zentrale Innovation im Design von VDBBench ist die Trennung von seriellen und nebenläufigen Tests, die dabei hilft zu erfassen, wie sich Systeme unter verschiedenen Lastarten verhalten, und Performance-Eigenschaften sichtbar macht, die für unterschiedliche Anwendungsfälle wichtig sind.
Trennung der Latenzmessung:
serial_latency_p99misst die System-Performance unter minimaler Last, wobei jeweils nur eine Anfrage gleichzeitig verarbeitet wird. Dies stellt das Best-Case-Szenario für Latenz dar und hilft, grundlegende Systemfähigkeiten zu identifizieren.conc_latency_p99erfasst das Systemverhalten unter realistischen Bedingungen mit hoher Nebenläufigkeit, bei denen mehrere Anfragen gleichzeitig eintreffen und um Systemressourcen konkurrieren.
Zweiphasige Benchmark-Struktur:
Serieller Test: Ein Single-Process-Lauf mit 1.000 Abfragen, der Basis-Performance und Genauigkeit etabliert und sowohl
serial_latency_p99als auch Recall ausgibt. Diese Phase hilft, die theoretische Performance-Obergrenze zu identifizieren.Nebenläufigkeitstest: Simuliert eine Produktionsumgebung unter anhaltender Last mit mehreren zentralen Innovationen:
Realistische Client-Simulation: Jeder Testprozess arbeitet unabhängig mit seiner eigenen Verbindung und seinem eigenen Abfragesatz, wodurch Interferenzen durch gemeinsamen Zustand vermieden werden, die Ergebnisse verfälschen könnten
Synchronisierter Start: Alle Prozesse beginnen gleichzeitig, wodurch sichergestellt wird, dass die gemessenen QPS die angegebenen Nebenläufigkeitsstufen genau widerspiegeln
Unabhängige Abfragesätze: Verhindert unrealistische Cache-Trefferquoten, die die Abfragevielfalt in der Produktion nicht widerspiegeln
Diese sorgfältig strukturierten Methoden stellen sicher, dass die von VDBBench gemeldeten Werte für max_qps und conc_latency_p99 sowohl genau als auch produktionsrelevant sind und aussagekräftige Erkenntnisse für Produktionskapazitätsplanung und Systemdesign liefern.
Erste Schritte mit VDBBench 1.0
VDBBench 1.0 stellt einen grundlegenden Wandel hin zu produktionsrelevantem Benchmarking dar. Durch die Abdeckung kontinuierlichen Datenschreibens, Metadata Filtering mit variierender Selektivität und Streaming-Lasten unter nebenläufigen Zugriffsmustern bietet es die derzeit beste Annäherung an tatsächliche Produktionsumgebungen.
Die Lücke zwischen Benchmark-Ergebnissen und realer Performance sollte kein Ratespiel sein. Wenn Sie planen, eine Vektordatenbank in der Produktion einzusetzen, lohnt es sich zu verstehen, wie sie über idealisierte Labortests hinaus performt. VDBBench ist Open Source, transparent und darauf ausgelegt, aussagekräftige, direkte Vergleiche zu unterstützen.
Lassen Sie sich nicht von beeindruckenden Zahlen beeinflussen, die sich nicht in Produktionswert übersetzen lassen. Nutzen Sie VDBBench 1.0, um Szenarien zu testen, die für Ihr Unternehmen relevant sind, mit Ihren Daten und unter Bedingungen, die Ihre tatsächliche Workload widerspiegeln. Die Ära irreführender Benchmarks in der Bewertung von Vektordatenbanken geht zu Ende — es ist an der Zeit, Entscheidungen auf Basis produktionsrelevanter Daten zu treffen.
Testen Sie VDBBench mit Ihren eigenen Workloads: https://github.com/zilliztech/VectorDBBench
Sehen Sie sich Testergebnisse großer Vektordatenbanken an: VDBBench-Bestenliste
Haben Sie Fragen oder möchten Sie Ihre Ergebnisse teilen? Beteiligen Sie sich an der Diskussion auf GitHub oder vernetzen Sie sich mit unserer Community auf Discord.
Weiterlesen
We spent 8 years making vector databases faster. Then we stopped.
Rarely queried embeddings still need to stay searchable. See how Vector Lakebase enables on-demand vector search without always-on compute costs.
Zilliz Cloud Introduces Advanced BYOC-I Solution for Ultimate Enterprise Data Sovereignty
Explore Zilliz Cloud BYOC-I, the solution that balances AI innovation with data control, enabling secure deployments in finance, healthcare, and education sectors.
The Great AI Agent Protocol Race: Function Calling vs. MCP vs. A2A
Compare Function Calling, MCP, and A2A protocols for AI agents. Learn which standard best fits your development needs and future-proof your applications.