Vektor-Datenbank-Benchmarks zeigen große Unterschiede bei Build-Zeit und Nebenläufigkeit

Percona hat einen rigorosen Benchmark veröffentlicht, der die Leistungsfähigkeit der Vektorsuche über sechs Datenbank-Engines hinweg vergleicht. Dabei wurden erhebliche Diskrepanzen bei der Indizierungs-Geschwindigkeit, der Speichernutzung und der Handhabung von Nebenläufigkeit deutlich. Die Studie bewertete MariaDB, AliSQL, PostgreSQL mit pgvector, Valkey sowie Percona Search for MongoDB anhand eines Korpus von 990.000 OpenAI-Embeddings. Die Ergebnisse zeigen, dass zwar einige Engines durch schnelle Index-Erstellung glänzen, andere jedoch eine überlegene Speichereffizienz oder einen hohen Durchsatz bei parallelen Abfragen bieten. Dies liefert Ingenieuren, die Retrieval-Augmented Generation (RAG)-Systeme entwerfen, entscheidende Daten.

Was passiert ist

Der Benchmark lud 990.000 Vektoren mit 1.536 Dimensionen in jede Engine, erstellte einen HNSW-Index und maß fünf Schlüsselmetriken: Zeit bis zur Erstellung eines abfragbaren Index, Speicher- und RAM-Fußabdruck, Recall im Verhältnis zum Durchsatz, Leistung unter parallelen Clients sowie das Verhalten bei Datenänderungen (Data Churn). Alle Tests liefen auf identischer Hardware – einem Intel Xeon Gold 6230 Server mit 80 logischen CPUs und 187,5 GB RAM –, um einen fairen Vergleich zu gewährleisten. Der Orchestrator wandte konsistente Ressourcenlimits an, wie z. B. einen InnoDB Buffer Pool von 42,3 GB und spezifische Speicherzuweisungen für Graph-Caches, um Konfigurationsverzerrungen zu vermeiden.

Die Ergebnisse offenbarten unerwartete Variationen bei grundlegenden Operationen. Die Zeit bis zur Erstellung eines abfragbaren Index reichte von nur 1,9 Minuten für Percona Search bis hin zu 6,7 Stunden für AliSQL. Auch die Speichereffizienz variierte stark: MariaDB erzeugte den kleinsten Index mit 3,9 GiB, während Percona Search 15,1 GiB benötigte. Bemerkenswerterweise benötigte die Engine mit dem kleinsten Index am längsten für dessen Erstellung, was einen üblichen Kompromiss zwischen Komprimierung und Erstellungsgeschwindigkeit illustriert. Diese Erkenntnisse deuten darauf hin, dass die Wahl einer Vektor-Datenbank das Abwägen unmittelbarer operativer Bedürfnisse, wie der Häufigkeit der Re-Indizierung, gegen langfristige Speicherkosten erfordert.

Nebenläufigkeitstests deckten weitere Unterschiede auf. Unter einer Last von 32 parallelen Clients steigerte PostgreSQL mit pgvector seinen Durchsatz um das 21,7-fache im Vergleich zur Einzelclient-Leistung. Im Gegensatz dazu zeigten die drei auf InnoDB basierenden Engines – MariaDB 11.8, MariaDB 12.3 und AliSQL – kaum Skalierung und behielten einen Durchsatz von etwa 1x bei. Das Benchmark-Team zog jedoch spezifische Zahlen zur Nebenläufigkeits-Effizienz dieser drei Engines zurück, nachdem eine Einschränkung im Test-Harness entdeckt wurde. Der MariaDB Connector/C hielt während des Wartens auf Sockets den Python-Interpreter-Lock, was bedeutete, dass einige Clients auf den Lock warteten statt auf die Datenbank, was die "in service"-Metriken verfälschte.

Wie es funktioniert

Der Benchmark verwendete den Datensatz dbpedia-openai-1000k-angular, bestehend aus 990.000 float32-Vektoren. Jede Engine baute einen HNSW-Index mit M=16, einem Standardparameter, der die Konnektivität der Graphstruktur steuert. Die Abfrageleistung wurde mit verschiedenen ef_search-Werten gemessen, die bestimmen, wie viele Kandidaten während der Suche erkundet werden. Der Recall wurde unter Verwendung der Distanzschwellenwert-Definition aus ann-benchmarks berechnet, um die Vergleichbarkeit mit vorhandener Literatur sicherzustellen. Für gefilterte Abfragen wurde der Ground Truth per Brute Force nur über die Zeilen neu berechnet, die das Prädikat erfüllen, damit Engines nicht dafür bestraft werden, dass sie nicht übereinstimmende Elemente korrekt ausschließen.

Verschiedene Engines nutzen unterschiedliche Strategien für die gefilterte Suche. PostgreSQL mit pgvector verwendet einen Post-Filter-Ansatz, bei dem Kandidaten aus dem Graph gesammelt und dann jene verworfen werden, die das Prädikat nicht erfüllen. Wenn zu viele verworfen werden, stoppt die Suche frühzeitig, was potenziell weniger Ergebnisse als angefordert liefern kann. Percona Search nutzt eine Pre-Filter-Strategie, die bei enger werdenden Filtern einen höheren Durchsatz aufrechterhalten kann, aber möglicherweise Recall einbüßt. MariaDB und AliSQL filtern ebenfalls nachträglich, setzen die Suche jedoch fort, was den Recall erhält, aber die Latenz erheblich erhöhen kann, wenn die Selektivität des Filters sinkt. Diese architektonischen Entscheidungen wirken sich direkt darauf aus, wie gut jede Engine komplexe, reale Abfragen mit Metadaten-Filtern verarbeitet.

Wichtige Details

• Index-Build-Zeit: Percona Search war mit 1,9 Minuten am schnellsten, während AliSQL mit 6,7 Stunden am langsamsten war.
• Speichereffizienz: MariaDB 11.8 und 12.3 produzierten die kleinsten Indizes mit 3,9 GiB, im Vergleich zu 15,1 GiB für Percona Search.
• Einzelclient-Durchsatz: Bei 0,99 Recall führte MariaDB 12.3 mit 277 QPS, gefolgt von Valkey mit 264 QPS und PostgreSQL mit 210 QPS.
• Skalierung bei Nebenläufigkeit: Der Durchsatz von PostgreSQL stieg bei 32 Clients um das 21,7-fache, während auf InnoDB basierende Engines aufgrund von serverseitiger Queuing-Mechanismen minimale Skalierung zeigten.
• Gefilterte Suche: Die Standard-Post-Filter-Methode von PostgreSQL führte dazu, dass der Recall bei 1 % Selektivität auf 0,1034 fiel, da die Suche frühzeitig stoppte, nachdem nicht übereinstimmende Kandidaten verworfen worden waren.
• Datenänderungen (Data Churn): MHNSW und VIDX aktualisieren den Graph bei jedem Insert, wodurch ihre Ladezeit der Index-Build-Zeit entspricht, anders als bei pgvector, das Kopieren und Erstellen trennt.

Warum das wichtig ist

Für Software-Ingenieure, die KI-Anwendungen entwickeln, heben diese Benchmarks hervor, dass keine einzelne Engine alle Kategorien dominiert. Wenn Ihre Anwendung häufige Re-Indizierungen oder Modell-Updates erfordert, ist der Unterschied zwischen einer Build-Zeit von 40 Minuten für PostgreSQL und einem Fenster von 6,7 Stunden für AliSQL betrieblich signifikant. Umgekehrt bietet der kompakte 3,9-GiB-Index von MariaDB erhebliche Einsparungen gegenüber anderen Optionen, trotz seines langsameren Build-Prozesses, falls Speicherkosten die primäre Einschränkung sind. Das Verständnis dieser Trade-offs hilft Teams, Infrastruktur auszuwählen, die ihren spezifischen Arbeitslastmustern entspricht, unabhängig davon, ob sie Schreibgeschwindigkeit, Lesedurchsatz oder Speicherdichte priorisieren.

Die Ergebnisse zur Nebenläufigkeit sind besonders relevant für Dienste mit hohem Traffic. Die Fähigkeit von PostgreSQL und Valkey, den Durchsatz linear mit der Client-Anzahl zu skalieren, deutet darauf hin, dass sie besser für Umgebungen mit vielen gleichzeitigen Nutzern geeignet sind. Die flache Leistung der auf InnoDB basierenden Engines unter paralleler Last weist auf potenzielle Engpässe in ihren aktuellen Vektor-Implementierungen oder Connector-Bibliotheken hin. Ingenieure müssen diese Skalierungscharakteristiken beim Entwurf der Systemarchitektur berücksichtigen, was möglicherweise zusätzliche Load-Balancing- oder Connection-Pooling-Strategien für Engines erfordert, die nativ nicht gut skalieren.

Was Sie tun können

• Bewerten Sie Ihre Re-Indizierungs-Häufigkeit; wenn Sie Embeddings oft aktualisieren, priorisieren Sie Engines mit schnelleren Build-Zeiten wie PostgreSQL oder Valkey.
• Testen Sie die Leistung der gefilterten Suche mit Ihrer spezifischen Metadatenverteilung, da Standardkonfigurationen zu schlechtem Recall oder hoher Latenz führen können.
• Wägen Sie Speicherkosten gegen Build-Zeit ab; wenn Festplattenspeicher teuer ist, können die kleineren Indizes von MariaDB längere Build-Fenster rechtfertigen.
• Führen Sie Benchmarks zur Nebenläufigkeit für Ihre erwartete Nutzerlast durch, wobei Sie bedenken sollten, dass einige Engines mehr Instanzen benötigen, um parallele Abfragen effektiv zu verarbeiten.
• Überprüfen Sie Connector-Bibliotheken für sprachspezifische Clients, da Einschränkungen im Harness dieser Studie darauf hindeuten, dass Treiber-Level-Engpässe die Datenbankleistung verschleiern können.
• Überwachen Sie die Speichernutzung während der Index-Erstellung, da der Peak-RSS von 14,3 GB bis 48,8 GB variierte, was die Anforderungen an die Infrastruktur-Bereitstellung beeinflusst.