Auswahl einer Vektordatenbank für die ANN-Suche bei Reddit

Dieser Beitrag wurde von Chris Fournie, dem Staff Software Engineer bei Reddit, verfasst und ursprünglich auf Redditveröffentlicht und wird hier mit Genehmigung wiederveröffentlicht.

Im Jahr 2024 verwendeten die Reddit-Teams eine Vielzahl von Lösungen, um die ANN-Vektorsuche (Approximate Nearest Neighbour) durchzuführen. Von der Vertex AI Vector Search von Google und dem Experimentieren mit der ANN-Vektorsuche von Apache Solr für einige größere Datensätze bis hin zur FAISS-Bibliothek von Facebook für kleinere Datensätze (die in vertikal skalierten Seitenwagen gehostet werden). Immer mehr Teams bei Reddit wünschten sich eine breit unterstützte ANN-Vektorsuchlösung, die kostengünstig ist, die gewünschten Suchfunktionen bietet und auf Daten in der Größe von Reddit skaliert werden kann. Um diesen Bedarf zu decken, haben wir 2025 die ideale Vektordatenbank für Reddit-Teams gesucht.

In diesem Beitrag wird der Prozess beschrieben, den wir zur Auswahl der besten Vektordatenbank für die heutigen Anforderungen von Reddit verwendet haben. Er beschreibt weder die beste Vektordatenbank insgesamt noch die wichtigsten funktionalen und nicht-funktionalen Anforderungen für alle Situationen. Es wird beschrieben, worauf Reddit und seine technische Kultur bei der Auswahl einer Vektordatenbank Wert gelegt haben und welche Prioritäten sie gesetzt haben. Dieser Beitrag kann als Inspiration für Ihre eigene Anforderungserhebung und -bewertung dienen, aber jedes Unternehmen hat seine eigene Kultur, seine eigenen Werte und Bedürfnisse.

Evaluierungsprozess

Insgesamt waren die Auswahlschritte:

1. Sammeln des Kontexts von Teams

2. Qualitative Bewertung der Lösungen

3. Quantitative Bewertung der Top-Anwärter

4. Endgültige Auswahl

1. Sammeln von Kontext von Teams

Von Teams, die an einer ANN-Vektorsuche interessiert sind, wurden drei Kontextinformationen gesammelt:

• Funktionale Anforderungen (z. B. Hybride Vektor- und lexikalische Suche? Bereichs-Suchanfragen? Filtern nach Nicht-Vektor-Attributen?)

• Nicht-funktionale Anforderungen (z. B. Unterstützung von 1B-Vektoren? Kann eine P99-Latenzzeit von <100ms erreicht werden?)

• Vektordatenbanken, an denen die Teams bereits interessiert waren

Die Befragung von Teams nach Anforderungen ist nicht trivial. Viele werden ihre Bedürfnisse so beschreiben, wie sie derzeit ein Problem lösen, und Ihre Herausforderung besteht darin, diese Voreingenommenheit zu verstehen und zu beseitigen.

Ein Beispiel: Ein Team verwendete bereits FAISS für die ANN-Vektorsuche und gab an, dass die neue Lösung effizient 10.000 Ergebnisse pro Suchaufruf liefern muss. Nach weiterer Diskussion stellte sich heraus, dass der Grund für die 10K Ergebnisse darin lag, dass sie eine Post-hoc-Filterung durchführen mussten und FAISS keine Filterung von ANN-Ergebnissen zur Abfragezeit bietet. Ihr eigentliches Problem bestand darin, dass sie eine Filterung brauchten, so dass jede Lösung, die eine effiziente Filterung bot, ausreichte, und die Rückgabe von 10K Ergebnissen war lediglich ein Workaround, der erforderlich war, um ihre Trefferquote zu verbessern. Idealerweise würden sie gerne die gesamte Sammlung vorfiltern, bevor sie die nächsten Nachbarn finden.

Die Frage nach den Vektordatenbanken, die die Teams bereits nutzen oder an denen sie interessiert sind, war ebenfalls sehr hilfreich. Wenn mindestens ein Team seine aktuelle Lösung positiv bewertet, ist dies ein Zeichen dafür, dass die Vektordatenbank eine nützliche Lösung für das gesamte Unternehmen sein könnte. Wenn die Teams nur negative Ansichten über eine Lösung hatten, sollten wir sie nicht als Option in Betracht ziehen. Die Aufnahme von Lösungen, an denen die Teams interessiert waren, war auch eine Möglichkeit sicherzustellen, dass sich die Teams in den Prozess einbezogen fühlten, und half uns dabei, eine erste Liste führender Kandidaten für die Bewertung zu erstellen; es gibt zu viele ANN-Vektorsuchlösungen in neuen und bestehenden Datenbanken, um alle erschöpfend zu testen.

2. Qualitative Bewertung der Lösungen

Ausgehend von der Liste der Lösungen, an denen die Teams interessiert waren, haben wir eine qualitative Bewertung der ANN-Vektorsuchlösung vorgenommen, die unseren Anforderungen am besten entspricht:

• Wir haben jede Lösung untersucht und bewertet, wie gut sie jede Anforderung im Vergleich zur gewichteten Wichtigkeit dieser Anforderung erfüllt.

• Ausschluss von Lösungen auf der Grundlage qualitativer Kriterien und Diskussionen

• Wir wählten die N besten Lösungen aus, um sie quantitativ zu testen.

Unsere Ausgangsliste der ANN-Vektorsuchlösungen umfasste:

• Milvus

• Qdrant

• Weviate

• Offene Suche

• Pgvector (verwendet bereits Postgres als RDBMS)

• Redis (wird bereits als KV-Speicher und Cache verwendet)

• Cassandra (wird bereits für die nicht-ANN-Suche verwendet)

• Solr (bereits für lexikalische Suche verwendet und mit Vektorsuche experimentiert)

• Vespa

• Pinecone

• Vertex AI (bereits für die ANN-Vektorsuche verwendet)

Wir haben dann alle funktionalen und nicht-funktionalen Anforderungen, die von den Teams genannt wurden, plus einige weitere Einschränkungen, die unsere technischen Werte und Ziele repräsentieren, in eine Tabelle eingetragen und gewichtet, wie wichtig sie waren (von 1 bis 3; siehe die verkürzte Tabelle unten).

Für jede Lösung, die wir verglichen, bewerteten wir (auf einer Skala von 0 bis 3), wie gut jedes System diese Anforderung erfüllte (wie in der Tabelle unten dargestellt). Da diese Bewertung etwas subjektiv war, wählten wir ein System aus und gaben Beispiele für die Bewertung mit schriftlicher Begründung an, auf die sich die Prüfer beziehen sollten. Außerdem gaben wir die folgenden Hinweise für die Vergabe der einzelnen Punktwerte: Vergeben Sie diesen Wert, wenn:

• 0: Keine Unterstützung/Nachweis der Unterstützung von Anforderungen

• 1: Einfache oder unzureichende Unterstützung der Anforderung

• 2: Die Anforderung wird angemessen unterstützt

• 3: Robuste Anforderungsunterstützung, die über vergleichbare Lösungen hinausgeht

Anschließend wurde eine Gesamtbewertung für jede Lösung erstellt, indem die Summe des Produkts aus der Anforderungsbewertung einer Lösung und der Wichtigkeit dieser Anforderung gebildet wurde (z. B. erhielt Qdrant die Punktzahl 3 für die Neueinstufung/Kombination von Anforderungen, die eine Wichtigkeit von 2 haben, also 3 x 2 = 6; wiederholen Sie dies für alle Zeilen und addieren Sie die Werte). Am Ende erhalten wir eine Gesamtpunktzahl, die als Grundlage für die Einstufung und Diskussion von Lösungen und der wichtigsten Anforderungen dienen kann (beachten Sie, dass die Punktzahl nicht für eine endgültige Entscheidung, sondern als Diskussionsgrundlage verwendet wird).

Anmerkung des Herausgebers: Diese Bewertung basierte auf Milvus 2.4. Inzwischen haben wir Milvus 2.5 und 2.6 auf den Markt gebracht, und Milvus 3.0 steht vor der Tür, so dass einige Zahlen möglicherweise nicht mehr aktuell sind. Dennoch bietet der Vergleich immer noch gute Einblicke und ist nach wie vor sehr hilfreich.

Kategorie	Wichtigkeit	Qdrant	Milvus (2.4)	Kassandra	Weviate	Solr	Vertex AI
Art der Suche
Hybride Suche	1	3	2	0	2	2	2
Schlüsselwortsuche	1	2	2	2	2	3	1
Näherungsweise NN-Suche	3	3	3	2	2	2	2
Bereich Suche	1	3	3	2	2	0	0
Umreihung/Punktekombination	2	3	2	0	2	2	1
Indizierungsmethode
HNSW	3	3	3	2	2	2	0
Unterstützt mehrere Indizierungsmethoden	3	0	3	1	2	1	1
Quantisierung	1	3	3	0	3	0	0
Lokalitätssensitives Hashing (LSH)	1	0	0Hinweis: Milvus 2.6 unterstützt dies.	0	0	0	0
Daten
Andere Vektortypen als Float	1	2	2	0	2	2	0
Metadatenattribute auf Vektoren (unterstützt mehrere Attribute, eine große Datensatzgröße usw.)	3	3	2	2	2	2	1
Filteroptionen für Metadaten (kann nach Metadaten filtern, hat Vor-/Nachfilterung)	2	3	2	2	2	3	2
Metadaten-Attribut-Datentypen (robustes Schema, z. B. bool, int, string, json, arrays)	1	3	3	2	2	3	1
Grenzwerte für Metadatenattribute (Bereichsabfragen, z. B. 10 < x < 15)	1	3	3	2	2	2	1
Diversität der Ergebnisse nach Attributen (z. B. nicht mehr als N Ergebnisse aus jedem Subreddit in einer Antwort)	1	2	1	2	3	3	0
Maßstab
Hunderte von Millionen Vektorindex	3	2	3		1	2	3
Milliarden-Vektor-Index	1	2	2		1	2	2
Stützvektoren mit mindestens 2k	2	2	2	2	2	1	1
Stützvektoren größer als 2k	2	2	2	2	1	1	1
P95 Latenzzeit 50-100ms @ X QPS	3	2	2	2	1	1	2
P99 Latenz <= 10ms @ X QPS	3	2	2	2	3	1	2
99,9% Verfügbarkeit Abruf	2	2	2	3	2	2	2
99,99% Verfügbarkeit Indizierung/Speicherung	2	1	1	3	2	2	2
Speicherbetrieb
Hostfähig in AWS	3	2	2	2	2	3	0
Multi-Region	1	1	2	3	1	2	2
Upgrades ohne Ausfallzeiten	1	2	2	3	2	2	1
Multi-Cloud	1	3	3	3	2	2	0
APIs/Bibliotheken
gRPC	2	2	2	2	2	0	2
RESTful API	1	3	2	2	2	1	2
Go Bibliothek	3	2	2	2	2	1	2
Java-Bibliothek	2	2	2	2	2	2	2
Python	2	2	2	2	2	2	2
Andere Sprachen (C++, Ruby, usw.)	1	2	2	3	2	2	2
Laufzeit-Operationen
Prometheus-Metriken	3	2	2	2	3	2	0
Grundlegende DB-Operationen	3	2	2	2	2	2	2
Upserts	2	2	2	2	1	2	2
Kubernetes-Betreiber	2	2	2	2	2	2	0
Seitennummerierung der Ergebnisse	2	2	2	2	2	2	0
Einbettung der Suche nach der ID	2	2	2	2	2	2	2
Rückgabe der Einbettungen mit Kandidaten-ID und Kandidaten-Bewertungen	1	3	2	2	2	2	2
Vom Benutzer bereitgestellte ID	2	2	2	2	2	2	2
In der Lage, in einem großen Batch-Kontext zu suchen	1	2	1	1	2	1	2
Backups / Snapshots: unterstützt die Möglichkeit, Backups der gesamten Datenbank zu erstellen	1	2	2	2	3	3	2
Effiziente Unterstützung großer Indizes (Unterscheidung zwischen kalter und heißer Speicherung)	1	3	2	2	2	1	2
Unterstützung/Gemeinschaft
Neutralität des Anbieters	3	3	2	3	2	3	0
Robuste Api-Unterstützung	3	3	3	2	2	2	2
Unterstützung durch den Anbieter	2	2	2	2	2	2	0
Gemeinschaftliche Geschwindigkeit	2	3	2	2	2	2	0
Produktion Benutzerbasis	2	3	3	2	2	1	2
Gemeinschaftsgefühl	1	3	2	2	2	2	1
Github-Sterne	1	2	2	2	2	2	0
Konfiguration
Geheimnisse Handhabung	2	2	2	2	1	2	2
Quelle
Offene Quelle	3	3	3	3	2	3	0
Sprache	2	3	3	2	3	2	0
Freigaben	2	3	3	2	2	2	2
Vorgelagerte Prüfung	1	2	3	3	2	2	2
Verfügbarkeit der Dokumentation	3	3	3	2	1	2	1
Kosten
Kosteneffektiv	2	2	2	2	2	2	1
Leistung
Unterstützung für die Optimierung der Ressourcenauslastung von CPU, Speicher und Festplatte	3	2	2	2	2	2	2
Sharding mit mehreren Knoten (Pod)	3	2	2	3	2	2	2
die Möglichkeit haben, das System so einzustellen, dass ein Gleichgewicht zwischen Latenz und Durchsatz besteht	2	2	2	3	2	2	2
Benutzerdefinierte Partitionierung (Schreiben)	1	3	2	3	1	2	0
Multi-Tenant	1	3	2	1	3	2	2
Unterteilung	2	2	2	3	2	2	2
Replikation	2	2	2	3	2	2	2
Redundanz	1	2	2	3	2	2	2
Automatische Ausfallsicherung	3	2	0 Hinweis: Milvus 2.6 unterstützt dies.	3	2	2	2
Lastausgleich	2	2	2	3	2	2	2
GPU-Unterstützung	1	0	2	0	0	0	0
		Qdrant	Milvus	Kassandra	Weviate	Solr	Vertex AI
Gesamtbewertung der Lösung		292	281	264	250	242	173

Wir diskutierten die Gesamt- und Anforderungsbewertungen der verschiedenen Systeme und versuchten zu verstehen, ob wir die Wichtigkeit der Anforderungen angemessen gewichtet hatten und ob einige Anforderungen so wichtig waren, dass sie als Kernanforderungen betrachtet werden sollten. Eine dieser Anforderungen war die Frage, ob die Lösung quelloffen war oder nicht, denn wir wünschten uns eine Lösung, an der wir uns beteiligen, zu der wir beitragen und kleine Probleme schnell beheben konnten, wenn sie in unserem Umfang auftraten. Die Mitwirkung an und die Verwendung von Open-Source-Software ist ein wichtiger Bestandteil der Reddit-Entwicklungskultur. Damit schieden die nur gehosteten Lösungen (Vertex AI, Pinecone) aus unserer Überlegung aus.

Im Laufe der Gespräche stellten wir fest, dass einige andere Schlüsselanforderungen für uns von überragender Bedeutung waren:

• Skalierbarkeit und Zuverlässigkeit: Wir wollten Beweise sehen, dass andere Unternehmen die Lösung mit 100 Mio. oder sogar 1 Mrd. Vektoren betreiben.

• Gemeinschaft: Wir wollten eine Lösung mit einer gesunden Community, die in diesem sich schnell entwickelnden Bereich eine große Dynamik aufweist

• Ausdrucksstarke Metadatentypen und Filterung, um mehr unserer Anwendungsfälle zu ermöglichen (Filterung nach Datum, Booleschen Werten usw.)

• Unterstützung für mehrere Indextypen (nicht nur HNSW oder DiskANN), um die Leistung für unsere vielen einzigartigen Anwendungsfälle zu verbessern

Als Ergebnis unserer Diskussionen und der Festlegung der wichtigsten Anforderungen entschieden wir uns für einen quantitativen Test (in dieser Reihenfolge):

1. Qdrant

2. Milvus

3. Vespa, und

4. Weviate

Leider erfordern Entscheidungen wie diese Zeit und Ressourcen, und keine Organisation verfügt über unbegrenzte Mengen von beidem. In Anbetracht unseres Budgets beschlossen wir, Qdrant und Milvus zu testen und Vespa und Weviate als Stretch Goal zu betrachten.

Qdrant gegen Milvus war auch ein interessanter Test zweier unterschiedlicher Architekturen:

• Qdrant: Homogene Knotentypen, die alle ANN-Vektor-Datenbankoperationen durchführen

• Milvus: Heterogene Knotentypen (Milvus; einer für Abfragen, ein anderer für die Indizierung, ein weiterer für den Dateningest, ein Proxy usw.)

Welches war einfach einzurichten (ein Test der Dokumentation)? Welche war einfach auszuführen (ein Test der Ausfallsicherheitsfunktionen und des Feinschliffs)? Und welche Lösung eignet sich am besten für die Anwendungsfälle und den Umfang, die uns wichtig waren? Diese Fragen versuchten wir zu beantworten, als wir die Lösungen quantitativ verglichen.

3. Quantitative Bewertung der Top-Anwärter

Wir wollten besser verstehen, wie skalierbar die einzelnen Lösungen sind, und dabei erfahren, wie die Einrichtung, Konfiguration, Wartung und Ausführung der einzelnen Lösungen im großen Maßstab aussehen würde. Dazu sammelten wir drei Datensätze mit Dokumenten- und Abfragevektoren für drei verschiedene Anwendungsfälle, richteten jede Lösung mit ähnlichen Ressourcen innerhalb von Kubernetes ein, luden Dokumente in jede Lösung und schickten identische Abfragelasten unter Verwendung von Grafanas K6 mit einem Ramping Arrival Rate Executor, um die Systeme aufzuwärmen, bevor sie dann einen Zieldurchsatz (z. B. 100 QPS) erreichten.

Wir testeten den Durchsatz, die Belastungsgrenze jeder Lösung, das Verhältnis zwischen Durchsatz und Latenz und wie sie auf den Verlust von Knoten unter Last reagieren (Fehlerrate, Auswirkungen auf die Latenz usw.). Von besonderem Interesse war die Auswirkung der Filterung auf die Latenz. Wir führten auch einfache Ja/Nein-Tests durch, um zu überprüfen, ob eine in der Dokumentation beschriebene Funktion auch wirklich so funktioniert (z. B. Upserts, Löschen, Get by ID, Benutzerverwaltung usw.) und um die Ergonomie dieser APIs zu testen.

Die Tests wurden mit Milvus v2.4 und Qdrant v1.12 durchgeführt. Aus Zeitgründen haben wir nicht alle Arten von Indexeinstellungen erschöpfend abgestimmt oder getestet; bei jeder Lösung wurden ähnliche Einstellungen verwendet, mit einer Tendenz zu hohem ANN-Recall, und die Tests konzentrierten sich auf die Leistung von HNSW-Indizes. Auch die CPU- und Speicherressourcen waren bei jeder Lösung ähnlich.

Bei unseren Experimenten stellten wir einige interessante Unterschiede zwischen den beiden Lösungen fest. In den folgenden Experimenten hatte jede Lösung etwa 340M Reddit-Post-Vektoren mit jeweils 384 Dimensionen, für HNSW, M=16 und efConstruction=100.

In einem Experiment stellten wir fest, dass bei gleichem Abfragedurchsatz (100 QPS ohne gleichzeitige Ingestion) das Hinzufügen von Filtern die Latenz von Milvus stärker beeinflusste als die von Qdrant.

Abfragelatenz mit Filterung

Außerdem stellten wir fest, dass die Interaktion zwischen Ingestion und Abfragelast bei Qdrant viel stärker war als bei Milvus (siehe unten bei konstantem Durchsatz). Dies ist wahrscheinlich auf die Architektur zurückzuführen: Milvus verteilt einen Großteil des Ingestion-Verkehrs auf verschiedene Knotentypen, während Qdrant sowohl Ingestion- als auch Query-Verkehr über dieselben Knoten abwickelt.

Abfragelatenz bei 100 QPS während des Ingests

Beim Testen der Ergebnisvielfalt nach Attributen (z. B. nicht mehr als N Ergebnisse aus jedem Subreddit in einer Antwort) haben wir festgestellt, dass Milvus bei gleichem Durchsatz eine schlechtere Latenz aufweist als Qdrant (bei 100 QPS).

Post-Query-Latenz mit Ergebnisvielfalt

Wir wollten auch sehen, wie effektiv jede Lösung skaliert, wenn mehr Datenreplikate hinzugefügt werden (d. h. der Replikationsfaktor RF wurde von 1 auf 2 erhöht). Zunächst konnte Qdrant bei RF=1 eine zufriedenstellende Latenz bei höherem Durchsatz als Milvus erzielen (höhere QPS werden nicht angezeigt, da die Tests nicht fehlerfrei abgeschlossen wurden).

Qdrant liefert RF=1 Latenzzeit bei unterschiedlichem Durchsatz

Milvus erreicht RF=1 Latenzzeit bei unterschiedlichem Durchsatz

Bei Erhöhung des Replikationsfaktors verbesserte sich die p99-Latenz von Qdrant, aber Milvus konnte einen höheren Durchsatz als Qdrant bei akzeptabler Latenz aufrechterhalten (Qdrant 400 QPS nicht gezeigt, da der Test aufgrund hoher Latenz und Fehler nicht abgeschlossen werden konnte).

Milvus erreicht eine Latenz von RF=2 bei unterschiedlichen Durchsätzen

Qdrant zeigt RF=2-Latenz bei unterschiedlichem Durchsatz

Aus Zeitgründen hatten wir nicht genug Zeit, um die ANN-Recall-Werte zwischen Lösungen auf unseren Datensätzen zu vergleichen, aber wir haben die ANN-Recall-Messungen für Lösungen berücksichtigt, die von https://ann-benchmarks.com/ auf öffentlich verfügbaren Datensätzen bereitgestellt wurden.

4. Endgültige Auswahl

In Bezug auf die Leistung schien Qdrant ohne große Anpassungen und nur unter Verwendung von HNSW in vielen Tests eine bessere rohe Latenzzeit zu haben als Milvus. Milvus schien jedoch mit zunehmender Replikation besser skalieren zu können und wies aufgrund seiner Architektur mit mehreren Knoten eine bessere Isolierung zwischen Ingestion und Abfragelast auf.

Trotzder Komplexität der Milvus-Architektur (mehrere Knotentypen, ein externes Write-Ahead-Protokoll wie Kafka und ein Metadatenspeicher wie etcd) war es für uns einfacher, Milvus zu debuggen und zu reparieren als Qdrant, wenn eine der beiden Lösungen in einen schlechten Zustand geriet. Milvus verfügt außerdem über einen automatischen Ausgleich, wenn der Replikationsfaktor einer Sammlung erhöht wird, wohingegen bei der Open-Source-Lösung Qdrant der Replikationsfaktor nur durch manuelles Erstellen oder Löschen von Shards erhöht werden kann (eine Funktion, die wir selbst hätten entwickeln oder die Nicht-Open-Source-Version verwenden müssen).

Milvus ist eine eher "Reddit-förmige" Technologie als Qdrant; sie weist mehr Ähnlichkeiten mit dem Rest unseres Tech-Stacks auf. Milvus ist in Golang geschrieben, unserer bevorzugten Backend-Programmiersprache, und daher für uns einfacher zu unterstützen als Qdrant, das in Rust geschrieben ist. Milvus hat im Vergleich zu Qdrant eine hervorragende Projektgeschwindigkeit für sein Open-Source-Angebot und erfüllte mehr unserer Hauptanforderungen.

Letztendlich erfüllten beide Lösungen die meisten unserer Anforderungen, und in einigen Fällen hatte Qdrant einen Leistungsvorteil, aber wir hatten das Gefühl, dass wir Milvus weiter skalieren konnten, dass wir uns beim Betrieb wohler fühlten und dass es besser zu unserer Organisation passte als Qdrant. Wir wünschten, wir hätten mehr Zeit gehabt, um Vespa und Weaviate zu testen, aber auch sie wurden möglicherweise aufgrund ihrer organisatorischen Eignung (Vespa ist Java-basiert) und ihrer Architektur (Weaviate ist ein Single-Node-System wie Qdrant) ausgewählt.

Die wichtigsten Erkenntnisse

• Hinterfragen Sie die Anforderungen, die Sie erhalten haben, und versuchen Sie, bestehende Lösungsvorurteile zu beseitigen.

• Bewerten Sie die in Frage kommenden Lösungen und nutzen Sie diese Ergebnisse, um die Diskussion über die wesentlichen Anforderungen zu führen, nicht um sie als das A und O zu betrachten.

• Bewerten Sie die Lösungen quantitativ, aber achten Sie dabei auch darauf, wie es ist, mit der Lösung zu arbeiten.

• Entscheiden Sie sich für die Lösung, die unter den Gesichtspunkten Wartung, Kosten, Benutzerfreundlichkeit und Leistung am besten in Ihr Unternehmen passt, und nicht nur, weil eine Lösung am besten funktioniert.

Danksagung

Diese Evaluierungsarbeit wurde von Ben Kochie, Charles Njoroge, Amit Kumar und mir durchgeführt. Unser Dank gilt auch anderen, die zu dieser Arbeit beigetragen haben, darunter Annie Yang, Konrad Reiche, Sabrina Kong und Andrew Johnson, für die qualitative Lösungsforschung.

Anmerkungen der Redaktion

Wir möchten dem Reddit-Engineering-Team ein aufrichtiges Dankeschön aussprechen - nicht nur dafür, dass sie Milvus für ihre Vektorsuch-Workloads ausgewählt haben, sondern auch dafür, dass sie sich die Zeit genommen haben, eine so detaillierte und faire Bewertung zu veröffentlichen. Es ist selten, dass man ein derartiges Maß an Transparenz beim Vergleich von Datenbanken durch echte Entwicklungsteams sieht, und ihr Bericht wird für jeden in der Milvus-Gemeinschaft (und darüber hinaus) hilfreich sein, der versucht, sich einen Überblick über die wachsende Landschaft der Vektordatenbanken zu verschaffen.

Wie Chris in seinem Beitrag erwähnt, gibt es nicht die eine "beste" Vektordatenbank. Entscheidend ist, ob ein System zu Ihrer Arbeitsbelastung, Ihren Einschränkungen und Ihrer Arbeitsphilosophie passt. Der Vergleich von Reddit spiegelt diese Realität gut wider. Milvus schneidet nicht in jeder Kategorie am besten ab, was angesichts der Kompromisse zwischen den verschiedenen Datenmodellen und Leistungszielen durchaus zu erwarten ist.

Eine Sache sollte klargestellt werden: Bei der Bewertung auf Reddit wurde Milvus 2.4 verwendet, das zu diesem Zeitpunkt die stabile Version war. Einige Funktionen - wie LSH und verschiedene Indexoptimierungen - existierten entweder noch nicht oder waren in 2.4 noch nicht ausgereift, so dass einige Bewertungen natürlich diese ältere Basis widerspiegeln. Seitdem haben wir Milvus 2.5 und dann Milvus 2.6 veröffentlicht, und es ist ein ganz anderes System in Bezug auf Leistung, Effizienz und Flexibilität. Die Reaktion der Community war sehr positiv, und viele Teams haben bereits aufgerüstet.

Hier ein kurzer Blick auf die Neuerungen in Milvus 2.6:

• Bis zu 72 % geringere Speichernutzung und 4× schnellere Abfragen mit RaBitQ 1-Bit-Quantisierung

• 50% Kostenreduzierung mit intelligentem Tiered Storage

• 4× schnellere BM25-Volltextsuche im Vergleich zu Elasticsearch

• 100× schnellere JSON-Filterung mit dem neuen Path Index

• Eine neue Zero-Disk-Architektur für eine frischere Suche bei geringeren Kosten

• Ein einfacherer "Data-in, Data-out"-Workflow für die Einbindung von Pipelines

• Unterstützung für 100K+ Sammlungen zur Handhabung großer mandantenfähiger Umgebungen

Wenn Sie eine vollständige Aufschlüsselung wünschen, finden Sie hier ein paar gute Folgeartikel:

• Blog: Einführung von Milvus 2.6: Erschwingliche Vektorsuche im Milliardenmaßstab

• Milvus 2.6 Versionshinweise:

• VDBBench 1.0: Real-World Benchmarking für Vektordatenbanken - Milvus Blog

Haben Sie Fragen oder möchten Sie eine Funktion genauer kennenlernen? Treten Sie unserem Discord-Kanal bei oder melden Sie Probleme auf GitHub. Sie können auch eine 20-minütige Einzelsitzung buchen, um Einblicke, Anleitung und Antworten auf Ihre Fragen über die Milvus Office Hours zu erhalten.