Abweichungen bei Benchmark-Ergebnissen entmystifizieren: Milvus vs. Qdrant
Mit der zunehmenden Beliebtheit von GenAI sind immer mehr Vektordatenbanken auf den Markt gekommen. Anfang letzten Jahres haben wir VectorDB Bench eingeführt, um Einblicke in die Leistung aufkommender Vektordatenbank-Technologien zu bieten.
Kürzlich wandten sich Entwickler, die tief in diesem Bereich engagiert sind, an uns bei Zilliz, um die erheblichen Unterschiede zwischen Qdrants Benchmark-Ergebnissen und unseren Erkenntnissen in VectorDB Bench zu verstehen. Insbesondere benötigten sie eine Klärung zur schlechten Performance von Milvus in den Qdrant-Benchmark-Ergebnissen. Als Reaktion auf diese Anfragen leitete unser Engineering-Team bei Zilliz eine umfassende Untersuchung ein, um die Ursachen dieser Unterschiede aufzudecken.
Dieser Blogbeitrag bietet eine ausführliche technische Analyse der Benchmark-Unterschiede, mit besonderem Augenmerk auf die Performance-Diskrepanz von Milvus. Lassen Sie uns ohne weitere Verzögerung in die Details dieser Untersuchung eintauchen.
Grund #1: veraltete Milvus-Version
Die Unterschiede in den Benchmark-Ergebnissen ergeben sich hauptsächlich aus den unterschiedlichen Milvus-Versionen, die beim Testen verwendet wurden. Der Qdrant-Benchmark-Bericht, basierend auf Milvus v2.1 und veröffentlicht am 10. August 2022, erfasst die bedeutenden Fortschritte, die in späteren Versionen erzielt wurden, nicht vollständig. Sehen Sie sich die Rohdaten aus diesem Bericht an. Seitdem hat Milvus erhebliche Verbesserungen erfahren.
In Milvus v2.2.1 haben wir die Vektor-Engine (auch bekannt als Knowhere) aktualisiert und die Parallelisierungsstrategie überarbeitet. Nachfolgende Updates in v2.2.3 brachten weitere Verbesserungen der Suchleistung. Unser Whitepaper hebt diese Fortschritte hervor und zeigt, dass Milvus 2.2.3 in Bezug auf Abfrageleistung (Latenz und Durchsatz) und Skalierbarkeit (Milliarden-Skala-Collections und mehrere Replikas) viermal schneller ist als Milvus 2.0.
Darauf folgend verbesserte v2.2.9 die Performance der gefilterten Suche. In v2.2.12 führten wir eine bessere Sucheffizienz mit minimalem Overhead für große top-K-Werte ein, verbesserten die Schreibleistung in Szenarien mit aktiviertem Partitionsschlüssel oder mehreren Partitionen und optimierten die CPU-Auslastung für größere Maschinen. Außerdem markierte v2.3.2 eine bedeutende Performance-Verbesserung durch minimiertes Kopieren von Daten während des Ladens und bessere Bulk-Inserts.
Diese kontinuierlichen Verbesserungen haben die Fähigkeiten von Milvus erheblich verändert. Daher spiegeln Benchmarks, die auf Milvus 2.1 basieren, die aktuelle Leistung der Technologie nicht mehr genau wider. Um die neuesten Fähigkeiten von Milvus besser zu verstehen, werden Entwickler ermutigt, sich auf VectorDB Bench zu beziehen, das Milvus 2.3 für Tests verwendet.
Grund #2: unsachgemäße Verwendung von Milvus
Qdrants Benchmark zur Milvus-Performance ergibt sich teilweise daraus, dass er nur Growing Segments verwendet hat. Wie der Name schon sagt, optimiert Milvus mit zwei Segment-Typen: Growing und Sealed Segments. Growing Segments empfangen weiterhin Daten, bis ein vordefinierter Schwellenwert erreicht ist. Diese Segmente priorisieren schnelle Dateneingabe und verwenden eine Brute-Force-Suchstrategie, was zu einer langsameren Abfrageleistung führt.
Andererseits erhalten Sealed Segments keine Daten mehr und verfügen daher über einen Index, was zu erheblichen Leistungsgewinnen führt. Milvus versiegelt Growing Segments automatisch, wenn ein vordefinierter Schwellenwert erreicht wird, sodass auch diese Daten bei Verwendung mit einem Index von den Leistungsgewinnen profitieren können.
Der Qdrant-Benchmark konzentrierte sich ausschließlich auf die Verwendung von Growing Segments, was natürlich zu der gemeldeten langsameren Leistung führte. Sich nur auf Growing Segments zu konzentrieren, unterscheidet sich davon, wie Milvus in realen Anwendungen verwendet wird, und untergräbt den Zweck der in Milvus enthaltenen Segmentstrategie.
Darüber hinaus führte Milvus v2.3 Unterstützung für den IVF-FLAT-Index für wachsende Indizes ein, um Benutzern zu helfen, Datenaktualität und Sucheffizienz auszubalancieren. Zusätzlich führte Milvus v2.3.4 den Binlog-Index für Growing Segments ein. Dieses Update ermöglicht die Verwendung fortschrittlicher Indizes wie IVF oder Fast Scan in diesen Segmenten und kann die Suchleistung potenziell um das Zehnfache steigern. Infolgedessen hat diese Funktionsverbesserung die früheren Qdrant-Benchmark-Ergebnisse noch weniger relevant gemacht.
Grund #3: Benchmark-getriebene Optimierung für Qdrant
Qdrants außergewöhnliche Benchmark-Leistung gegenüber anderen Anbietern beruht auf der Verwendung von supergroßen Segmenten für das Benchmarking. Während diese Strategie in den Benchmarks bemerkenswerte Ergebnisse lieferte, ist ihre Anwendbarkeit in der Praxis fraglich. In Vektordatenbanken ist die Größe von Segmenten entscheidend. Qdrants Fokus auf große Segmente steigerte die Benchmark-Werte, könnte jedoch die betriebliche Flexibilität im täglichen Einsatz beeinträchtigen.
Effektive Vektordatenbanken müssen vielfältige Workloads und sich wandelnde Datenanforderungen bewältigen. Supergroße Segmente sind in Benchmarks zwar effektiv, können jedoch mit den vielfältigen Abfragen, die in realen Situationen typisch sind, Schwierigkeiten haben. Sie führen zu zusätzlicher Komplexität in der Verwaltung und könnten den Ressourcenbedarf erhöhen.
Während Qdrants Benchmark-getriebene Optimierungen, wie supergroße Segmente, beeindruckende Leistung zeigen, wirft ihre Praktikabilität in dynamischen, realen Umgebungen Bedenken auf. Dies stellt die allgemeine Relevanz solcher Benchmark-Ergebnisse in tatsächlichen Vektordatenbank-Bereitstellungen infrage.
Abschließende Gedanken: ein Weg zu fairen und fundierten Entscheidungen
Wenn es um Vektordatenbanken geht, ist vertrauenswürdiges und umfassendes Benchmarking entscheidend. VectorDB Bench, entwickelt von Zilliz, liefert Entwicklern Leistungsdaten aus der Praxis. Im Bewusstsein der Herausforderung, absolute Unparteilichkeit in Benchmarks zu erreichen, teilen wir unsere Erkenntnisse, um das kollektive Wissen in diesem Bereich zu bereichern.
Der ANN Benchmark ist ein wertvolles Tool für alle, die nach unparteiischen Bewertungen suchen, und bietet standardisierte Evaluierungen von Vektordatenbanken. Da die Technologie in diesem Bereich voranschreitet, betonen wir die Notwendigkeit klarer, transparenter und kollaborativer Benchmarking-Bemühungen. Entwickler müssen Zugang zu wahrheitsgemäßen und präzisen Benchmarks haben oder eigene Tests mit ihren Daten durchführen, um bei der Auswahl einer Vektordatenbank fundierte Entscheidungen zu treffen.
Weiterlesen
My Wife Wanted Dior. I Spent $600 on Claude Code to Vibe-Code a 2M-Line Database Instead.
Write tests, not code reviews. How a test-first workflow with 6 parallel Claude Code sessions turns a 2M-line C++ codebase into a daily shipping pipeline.
How Zilliz Saw the Future of Vector Databases—and Built for Production
An inside look at how Zilliz built vector databases for real-world use, focusing on scalability, stability, and running them reliably at scale.
How to Build an Enterprise-Ready RAG Pipeline on AWS with Bedrock, Zilliz Cloud, and LangChain
Build production-ready enterprise RAG with AWS Bedrock, Nova models, Zilliz Cloud, and LangChain. Complete tutorial with deployable code.