Home
Blog
Einführung von AISAQ in Milvus: Milliardenfache Vektorsuche ist jetzt 3.200x billiger im Speicher

Einführung von AISAQ in Milvus: Milliardenfache Vektorsuche ist jetzt 3.200x billiger im Speicher

Engineering

December 10, 2025

Martin Li

Vektordatenbanken sind zu einer zentralen Infrastruktur für unternehmenskritische KI-Systeme geworden, und ihre Datenmengen wachsen exponentiell - oft erreichen sie Milliarden von Vektoren. Bei dieser Größenordnung wird alles schwieriger: niedrige Latenzzeiten, Genauigkeit, Zuverlässigkeit und der Betrieb über Replikate und Regionen hinweg. Eine Herausforderung taucht jedoch schon früh auf und dominiert die Architekturentscheidungen: die Kosten.

Um eine schnelle Suche zu ermöglichen, speichern die meisten Vektordatenbanken wichtige Indizierungsstrukturen in DRAM (Dynamic Random Access Memory), der schnellsten und teuersten Speicherebene. Dieses Design ist zwar leistungsfähig, aber schlecht skalierbar. Die DRAM-Nutzung skaliert eher mit der Datengröße als mit dem Abfrageverkehr, und selbst bei Komprimierung oder teilweisem SSD-Offloading müssen große Teile des Indexes im Speicher verbleiben. Wenn die Datensätze wachsen, werden die Speicherkosten schnell zu einem begrenzenden Faktor.

Milvus unterstützt bereits DISKANN, einen festplattenbasierten ANN-Ansatz, der die Speicherbelastung durch Verlagerung eines Großteils des Index auf SSD reduziert. Allerdings ist DISKANN immer noch auf DRAM für komprimierte Darstellungen angewiesen, die während der Suche verwendet werden. Milvus 2.6 geht mit AISAQ, einem von DISKANN inspirierten festplattenbasierten Vektorindex, noch einen Schritt weiter. Die von KIOXIA entwickelte AiSAQ-Architektur wurde mit einer "Zero-DRAM-Footprint-Architektur" konzipiert, die alle suchkritischen Daten auf der Festplatte speichert und die Datenplatzierung zur Minimierung der E/A-Operationen optimiert. Bei einer Arbeitslast von einer Milliarde Vektoren reduziert dies die Speichernutzung von 32 GB auf etwa 10 MB - eine 3.200-fache Reduzierung - beigleichbleibender praktischer Leistung.

In den folgenden Abschnitten wird erläutert, wie die graphenbasierte Vektorsuche funktioniert, woher die Speicherkosten kommen und wie AISAQ die Kostenkurve für die Vektorsuche in Milliardenhöhe umgestaltet.

Wie die herkömmliche graphenbasierte Vektorsuche funktioniert

Bei derVektorsuche geht es darum, Datenpunkte zu finden, deren numerische Repräsentationen einer Abfrage in einem hochdimensionalen Raum am nächsten kommen. "Am nächsten" bedeutet einfach den kleinsten Abstand gemäß einer Abstandsfunktion, z. B. Kosinusabstand oder L2-Abstand. Auf einer kleinen Skala ist dies ganz einfach: Berechnen Sie den Abstand zwischen der Abfrage und jedem Vektor und geben Sie dann die nächstgelegenen zurück. Auf einer großen Skala, z. B. in Milliardenhöhe, wird dieser Ansatz jedoch schnell zu langsam, um praktikabel zu sein.

Um erschöpfende Vergleiche zu vermeiden, stützen sich moderne ANNS-Systeme (Approximate Nearest Neighbour Search) auf graphbasierte Indizes. Anstatt eine Abfrage mit jedem Vektor zu vergleichen, organisiert der Index die Vektoren in einem Graphen. Jeder Knoten stellt einen Vektor dar, und die Kanten verbinden Vektoren, die numerisch nahe beieinander liegen. Durch diese Struktur kann das System den Suchraum drastisch einschränken.

Der Graph wird im Voraus erstellt und basiert ausschließlich auf den Beziehungen zwischen den Vektoren. Er hängt nicht von Abfragen ab. Wenn eine Abfrage eintrifft, besteht die Aufgabe des Systems darin, effizient durch den Graphen zu navigieren und die Vektoren mit dem geringsten Abstand zur Abfrage zu identifizieren - ohne den gesamten Datensatz zu durchsuchen.

Die Suche beginnt an einem vordefinierten Einstiegspunkt im Graphen. Dieser Startpunkt kann weit von der Abfrage entfernt sein, aber der Algorithmus verbessert seine Position Schritt für Schritt, indem er sich zu Vektoren bewegt, die näher an der Abfrage liegen. Während dieses Prozesses unterhält die Suche zwei interne Datenstrukturen, die zusammenarbeiten: eine Kandidatenliste und eine Ergebnisliste.

Und die beiden wichtigsten Schritte während dieses Prozesses sind die Erweiterung der Kandidatenliste und die Aktualisierung der Ergebnisliste.

Erweitern der Kandidatenliste

Die Kandidatenliste zeigt an, wo die Suche als nächstes ansetzen kann. Es handelt sich dabei um eine nach Prioritäten geordnete Menge von Graphknoten, die aufgrund ihrer Entfernung zur Suchanfrage vielversprechend erscheinen.

Bei jeder Iteration wählt der Algorithmus:

Er wählt den nächstgelegenen Kandidaten aus, der bisher entdeckt wurde. Aus der Kandidatenliste wählt er den Vektor mit dem geringsten Abstand zur Abfrage aus.
Er ruft die Nachbarn dieses Vektors aus dem Graphen ab. Diese Nachbarn sind Vektoren, die während der Indexerstellung als nahe am aktuellen Vektor liegend identifiziert wurden.
Bewertet die nicht besuchten Nachbarn und fügt sie der Kandidatenliste hinzu. Für jeden Nachbarn, der noch nicht erforscht wurde, berechnet der Algorithmus seine Entfernung zur Abfrage. Zuvor besuchte Nachbarn werden übersprungen, während neue Nachbarn in die Kandidatenliste aufgenommen werden, wenn sie vielversprechend erscheinen.

Durch wiederholtes Erweitern der Kandidatenliste erforscht die Suche zunehmend relevante Regionen des Graphen. So kann der Algorithmus immer bessere Antworten finden, während er nur einen kleinen Teil aller Vektoren untersucht.

Aktualisieren der Ergebnisliste

Gleichzeitig führt der Algorithmus eine Ergebnisliste, in der die besten bisher gefundenen Kandidaten für die endgültige Ausgabe festgehalten werden. Während die Suche fortschreitet, wird:

Verfolgt die nächstgelegenen Vektoren, die während der Durchquerung gefunden wurden. Dazu gehören sowohl Vektoren, die zur Erweiterung ausgewählt wurden, als auch andere, die auf dem Weg dorthin untersucht wurden.
Speichert ihre Entfernungen zur Abfrage. Dies ermöglicht es, die Kandidaten in eine Rangfolge zu bringen und die aktuellen Top-K-Nächsten Nachbarn zu erhalten.

Im Laufe der Zeit, wenn mehr Kandidaten bewertet und weniger Verbesserungen gefunden werden, stabilisiert sich die Ergebnisliste. Sobald es unwahrscheinlich ist, dass eine weitere Graphenuntersuchung zu näheren Vektoren führt, wird die Suche beendet und die Ergebnisliste als endgültige Antwort zurückgegeben.

Vereinfacht ausgedrückt, steuert die Kandidatenliste die Erkundung, während die Ergebnisliste die besten bisher gefundenen Antworten festhält.

Der Kompromiss bei der graphenbasierten Vektorsuche

Dieser graphenbasierte Ansatz macht eine groß angelegte Vektorsuche überhaupt erst praktisch. Indem das System durch den Graphen navigiert, anstatt jeden Vektor zu scannen, kann es hochwertige Ergebnisse finden, während es nur einen kleinen Teil des Datensatzes berührt.

Diese Effizienz gibt es jedoch nicht umsonst. Bei der graphenbasierten Suche gibt es einen grundlegenden Kompromiss zwischen Genauigkeit und Kosten.

Die Suche nach mehr Nachbarn verbessert die Genauigkeit, da ein größerer Teil des Graphen abgedeckt und die Wahrscheinlichkeit, dass echte nächste Nachbarn übersehen werden, verringert wird.
Gleichzeitig bedeutet jede zusätzliche Erweiterung mehr Arbeit: mehr Abstandsberechnungen, mehr Zugriffe auf die Graphenstruktur und mehr Lesungen von Vektordaten. Je tiefer oder weiter die Suche geht, desto mehr Kosten fallen an. Je nachdem, wie der Index konzipiert ist, zeigen sie sich in Form von höherer CPU-Auslastung, erhöhtem Speicherbedarf oder zusätzlichen Festplatten-E/A.

Das Ausbalancieren dieser gegensätzlichen Kräfte - hohe Wiederauffindbarkeit und effiziente Ressourcennutzung - ist von zentraler Bedeutung für das Design einer graphbasierten Suche.

Sowohl DISKANN als auch AISAQ bauen auf diesem Spannungsfeld auf, treffen aber unterschiedliche architektonische Entscheidungen darüber, wie und wo diese Kosten zu tragen sind.

Wie DISKANN die plattenbasierte Vektorsuche optimiert

DISKANN ist die bisher einflussreichste plattenbasierte ANN-Lösung und dient als offizielle Grundlage für den NeurIPS Big ANN-Wettbewerb, einem globalen Benchmark für die Vektorsuche in Milliardenhöhe. Seine Bedeutung liegt nicht nur in der Leistung, sondern auch in dem, was er bewiesen hat: Graphenbasierte ANN-Suche muss nicht ausschließlich im Speicher stattfinden, um schnell zu sein.

Durch die Kombination von SSD-basiertem Speicher mit sorgfältig ausgewählten In-Memory-Strukturen hat DISKANN gezeigt, dass eine groß angelegte Vektorsuche eine hohe Genauigkeit und eine geringe Latenzzeit auf handelsüblicher Hardware erreichen kann, ohne dass ein großer DRAM-Footprint erforderlich ist. Dies wird erreicht, indem neu überlegt wird , welche Teile der Suche schnell sein müssen und welche Teile einen langsameren Zugriff tolerieren können.

DISKANN behält die Daten, auf die am häufigsten zugegriffen wird, im Speicher, während größere Strukturen, auf die weniger häufig zugegriffen wird, auf die Festplatte verlagert werden. Dieses Gleichgewicht wird durch mehrere wichtige Designentscheidungen erreicht.

1. Verwendung von PQ-Distanzen zum Erweitern der Kandidatenliste

Das Erweitern der Kandidatenliste ist die häufigste Operation bei der graphbasierten Suche. Jede Erweiterung erfordert eine Abschätzung der Distanz zwischen dem Abfragevektor und den Nachbarn eines Kandidatenknotens. Die Durchführung dieser Berechnungen mit vollständigen, hochdimensionalen Vektoren würde häufige zufällige Lesevorgänge von der Festplatte erfordern - ein teurer Vorgang sowohl rechnerisch als auch in Bezug auf die E/A.

DISKANN vermeidet diese Kosten, indem es die Vektoren in Produktquantisierungscodes (PQ-Codes) komprimiert und diese im Speicher hält. PQ-Codes sind viel kleiner als vollständige Vektoren, enthalten aber immer noch genügend Informationen, um die Entfernung annähernd zu schätzen.

Während der Kandidatenexpansion berechnet DISKANN die Abstände unter Verwendung dieser PQ-Codes im Speicher, anstatt vollständige Vektoren von der SSD zu lesen. Dies reduziert die Festplattenein- und -ausgabe während der Graphenüberquerung drastisch und ermöglicht es der Suche, Kandidaten schnell und effizient zu erweitern, während der meiste SSD-Verkehr vom kritischen Pfad ferngehalten wird.

2. Gemeinsame Unterbringung von vollständigen Vektoren und Nachbarlisten auf der Festplatte

Nicht alle Daten können komprimiert oder ungefähr abgerufen werden. Sobald vielversprechende Kandidaten identifiziert worden sind, benötigt die Suche für genaue Ergebnisse immer noch Zugriff auf zwei Arten von Daten:

Nachbarlisten, um die Durchquerung des Graphen fortzusetzen
Vollständige (unkomprimierte) Vektoren für das endgültige Reranking

Auf diese Strukturen wird weniger häufig zugegriffen als auf die PQ-Codes, daher speichert DISKANN sie auf SSD. Um den Festplatten-Overhead zu minimieren, platziert DISKANN die Nachbarliste eines jeden Knotens und seinen vollständigen Vektor in derselben physischen Region auf der Festplatte. Dadurch wird sichergestellt, dass ein einziger SSD-Lesevorgang beides abrufen kann.

Durch die gemeinsame Platzierung verwandter Daten reduziert DISKANN die Anzahl der während der Suche erforderlichen zufälligen Festplattenzugriffe. Diese Optimierung verbessert sowohl die Expansions- als auch die Rerankingeffizienz, insbesondere bei großem Umfang.

3. Parallele Knotenexpansion für bessere SSD-Nutzung

Die graphbasierte ANN-Suche ist ein iterativer Prozess. Wenn jede Iteration nur einen Kandidatenknoten erweitert, gibt das System jeweils nur einen einzigen Festplattenlesevorgang aus, wodurch der größte Teil der parallelen SSD-Bandbreite ungenutzt bleibt. Um diese Ineffizienz zu vermeiden, erweitert DISKANN in jeder Iteration mehrere Kandidaten und sendet parallele Leseanforderungen an die SSD. Dieser Ansatz nutzt die verfügbare Bandbreite wesentlich besser aus und reduziert die Gesamtzahl der erforderlichen Iterationen.

Der Parameter beam_width_ratio steuert, wie viele Kandidaten parallel expandiert werden: Balkenbreite = Anzahl der CPU-Kerne × beam_width_ratio. Ein höheres Verhältnis verbreitert die Suche - was die Genauigkeit verbessern kann -, erhöht aber auch den Rechenaufwand und die Festplatten-E/A.

Um dies auszugleichen, führt DISKANN eine search_cache_budget_gb_ratio ein, die Speicher reserviert, um Daten, auf die häufig zugegriffen wird, zwischenzuspeichern, wodurch wiederholte SSD-Lesevorgänge reduziert werden. Gemeinsam helfen diese Mechanismen DISKANN dabei, Genauigkeit, Latenz und E/A-Effizienz auszugleichen.

Warum dies wichtig ist - und wo die Grenzen liegen

Das Design von DISKANN ist ein großer Schritt vorwärts für die plattenbasierte Vektorsuche. Da PQ-Codes im Speicher verbleiben und größere Strukturen auf die SSD verlagert werden, wird der Speicherbedarf im Vergleich zu vollständig speicherinternen Graphenindizes erheblich reduziert.

Gleichzeitig ist diese Architektur für suchkritische Daten nach wie vor auf permanent verfügbaren DRAM angewiesen. PQ-Codes, Caches und Kontrollstrukturen müssen im Speicher verbleiben, damit das Traversal effizient bleibt. Wenn die Datensätze auf Milliarden von Vektoren anwachsen und Implementierungen Replikate oder Regionen hinzufügen, kann dieser Speicherbedarf zu einem begrenzenden Faktor werden.

Dies ist die Lücke, die AISAQ schließen soll.

Wie AISAQ funktioniert und warum es wichtig ist

AISAQ baut direkt auf den Kernideen von DISKANN auf, führt aber eine entscheidende Änderung ein: Es macht die Speicherung von PQ-Daten im DRAM überflüssig. Anstatt komprimierte Vektoren als suchkritische, immer im Speicher befindliche Strukturen zu behandeln, verschiebt AISAQ sie auf SSD und gestaltet die Anordnung der Graphdaten auf der Festplatte neu, um eine effiziente Traversierung zu gewährleisten.

Damit dies funktioniert, reorganisiert AISAQ den Knotenspeicher so, dass die bei der Graphensuche benötigten Daten - vollständige Vektoren, Nachbarlisten und PQ-Informationen - auf der Festplatte in Mustern angeordnet werden, die für die Zugriffslokalität optimiert sind. Das Ziel besteht nicht nur darin, mehr Daten auf die kostengünstigere Festplatte zu verschieben, sondern auch darin, dies zu tun , ohne den zuvor beschriebenen Suchprozess zu unterbrechen.

Um unterschiedlichen Anwendungsanforderungen gerecht zu werden, bietet AISAQ zwei plattenbasierte Speichermodi: Leistung und Skalierung. Aus technischer Sicht unterscheiden sich diese Modi vor allem darin, wie PQ-komprimierte Daten gespeichert werden und wie auf sie während der Suche zugegriffen wird. Aus der Anwendungsperspektive sprechen diese Modi zwei unterschiedliche Arten von Anforderungen an: Anforderungen an eine niedrige Latenzzeit, wie sie für semantische Online-Such- und Empfehlungssysteme typisch sind, und Anforderungen an einen extrem hohen Umfang, wie er für RAG typisch ist.

AISAQ-Leistung: Optimiert für Geschwindigkeit

AISAQ-Performance speichert alle Daten auf der Festplatte und hält den E/A-Overhead durch Daten-Colocation niedrig.

In diesem Modus:

Der vollständige Vektor jedes Knotens, die Kantenliste und die PQ-Codes seiner Nachbarn werden zusammen auf der Festplatte gespeichert.
Der Besuch eines Knotens erfordert immer noch nur einen einzigen SSD-Lesezugriff, da alle Daten, die für die Kandidatenerweiterung und -bewertung benötigt werden, kolokalisiert sind.

Aus der Sicht des Suchalgorithmus entspricht dies weitgehend dem Zugriffsmuster von DISKANN. Die Kandidatenexpansion bleibt effizient, und die Laufzeitleistung ist vergleichbar, obwohl alle suchkritischen Daten jetzt auf der Festplatte liegen.

Der Kompromiss ist der Speicher-Overhead. Da die PQ-Daten eines Nachbarn in den Plattenseiten mehrerer Knoten erscheinen können, führt dieses Layout zu Redundanz und erhöht die Gesamtgröße des Index erheblich.

Daher hat im AISAQ-Performance-Modus eine geringe E/A-Latenz Vorrang vor der Festplatteneffizienz. Aus der Anwendungsperspektive kann der AiSAQ-Performance-Modus Latenzzeiten im Bereich von 10 mSek. bieten, wie sie für die semantische Online-Suche erforderlich sind.

AISAQ-Skala: Optimiert für Speichereffizienz

AISAQ-Scale verfolgt den entgegengesetzten Ansatz. Er wurde entwickelt, um die Festplattennutzung zu minimieren und dennoch alle Daten auf SSD zu speichern.

In diesem Modus:

Die PQ-Daten werden separat auf der Festplatte gespeichert, ohne Redundanz.
Dadurch wird die Redundanz eliminiert und die Indexgröße drastisch reduziert.

Der Nachteil ist, dass der Zugriff auf die PQ-Codes eines Knotens und seiner Nachbarn möglicherweise mehrere SSD-Lesevorgänge erfordert, was die E/A-Vorgänge während der Kandidatenerweiterung erhöht. Ohne Optimierung würde dies die Suche erheblich verlangsamen.

Um diesen Overhead zu kontrollieren, führt der AISAQ-Scale-Modus zwei zusätzliche Optimierungen ein:

PQ-Datenumordnung, die PQ-Vektoren nach Zugriffspriorität ordnet, um die Lokalisierung zu verbessern und zufällige Lesevorgänge zu reduzieren.
Ein PQ-Cache im DRAM (pq_read_page_cache_size), der häufig aufgerufene PQ-Daten speichert und wiederholte Festplattenlesungen für heiße Einträge vermeidet.

Mit diesen Optimierungen erreicht der AISAQ-Scale-Modus eine wesentlich bessere Speichereffizienz als AISAQ-Performance, wobei die praktische Suchleistung erhalten bleibt. Diese Leistung bleibt unter der von DISKANN, aber es gibt keinen Speicher-Overhead (die Indexgröße ist ähnlich wie bei DISKANN) und der Speicherbedarf ist erheblich geringer. Aus der Anwendungsperspektive bietet AiSAQ die Möglichkeit, die RAG-Anforderungen in ultrahohem Maßstab zu erfüllen.

Die wichtigsten Vorteile von AISAQ

Durch die Verlagerung aller suchkritischen Daten auf die Festplatte und die Neugestaltung des Zugriffs auf diese Daten ändert AISAQ das Kosten- und Skalierbarkeitsprofil der graphbasierten Vektorsuche grundlegend. Sein Design bietet drei wesentliche Vorteile.

1. Bis zu 3.200× geringere DRAM-Nutzung

Die Produktquantisierung reduziert die Größe von hochdimensionalen Vektoren erheblich, aber bei einer Milliarde Vektoren ist der Speicherbedarf immer noch beträchtlich. Selbst nach der Komprimierung müssen PQ-Codes während der Suche in herkömmlichen Designs im Speicher gehalten werden.

Bei SIFT1B, einem Benchmark mit einer Milliarde 128-dimensionaler Vektoren, benötigen die PQ-Codes allein etwa 30-120 GB DRAM, je nach Konfiguration. Die Speicherung der vollständigen, unkomprimierten Vektoren würde zusätzliche ~480 GB erfordern. Während PQ die Speichernutzung um das 4-16fache reduziert, ist der verbleibende Platzbedarf immer noch groß genug, um die Infrastrukturkosten zu dominieren.

Mit AISAQ entfällt diese Anforderung vollständig. Durch die Speicherung von PQ-Codes auf SSD anstelle von DRAM wird der Speicher nicht mehr durch persistente Indexdaten beansprucht. DRAM wird nur noch für leichtgewichtige, flüchtige Strukturen wie Kandidatenlisten und Kontroll-Metadaten verwendet. In der Praxis reduziert sich dadurch die Speichernutzung von mehreren Dutzend Gigabyte auf etwa 10 MB. In einer repräsentativen Konfiguration im Milliardenmaßstab sinkt der DRAM von 32 GB auf 10 MB, was einer 3.200-fachen Reduzierung entspricht.

Angesichts der Tatsache, dass SSD-Speicher im Vergleich zu DRAM etwa 1/30 des Preises pro Kapazitätseinheit kostet, hat diese Verschiebung direkte und dramatische Auswirkungen auf die Gesamtsystemkosten.

2. Kein zusätzlicher E/A-Overhead

Die Verlagerung von PQ-Codes vom Speicher auf die Festplatte würde normalerweise die Anzahl der E/A-Operationen während der Suche erhöhen. AISAQ vermeidet dies durch eine sorgfältige Kontrolle des Datenlayouts und der Zugriffsmuster. Anstatt verwandte Daten über die Festplatte zu verstreuen, platziert AISAQ PQ-Codes, vollständige Vektoren und Nachbarlisten gemeinsam, so dass sie zusammen abgerufen werden können. Dadurch wird sichergestellt, dass die Kandidatenerweiterung keine zusätzlichen zufälligen Lesevorgänge mit sich bringt.

Um den Benutzern die Kontrolle über den Kompromiss zwischen Indexgröße und E/A-Effizienz zu geben, führt AISAQ den Parameter inline_pq ein, der bestimmt, wie viele PQ-Daten inline mit jedem Knoten gespeichert werden:

Niedriger inline_pq: kleinere Indexgröße, aber möglicherweise zusätzliche E/A erforderlich
Höhere inline_pq: größere Indexgröße, aber Erhalt des Single-Read-Zugriffs

Wenn AISAQ mit inline_pq = max_degree konfiguriert ist, liest AISAQ den vollständigen Vektor eines Knotens, die Nachbarliste und alle PQ-Codes in einem einzigen Festplattenvorgang, was dem E/A-Muster von DISKANN entspricht, während alle Daten auf der SSD verbleiben.

3. Sequentieller PQ-Zugriff verbessert die Berechnungseffizienz

In DISKANN erfordert das Erweitern eines Kandidatenknotens R zufällige Speicherzugriffe, um die PQ-Codes seiner R Nachbarn abzurufen. AISAQ eliminiert diese Zufälligkeit, indem es alle PQ-Codes in einem einzigen I/O abruft und sie sequentiell auf der Festplatte speichert.

Das sequenzielle Layout bietet zwei wichtige Vorteile:

Sequentielle SSD-Lesevorgänge sind viel schneller als verstreute Zufallslesevorgänge.
Zusammenhängende Daten sind cache-freundlicher, so dass die CPUs die PQ-Abstände effizienter berechnen können.

Dies verbessert sowohl die Geschwindigkeit als auch die Vorhersagbarkeit der PQ-Abstandsberechnungen und trägt dazu bei, die Leistungskosten der Speicherung von PQ-Codes auf SSD statt auf DRAM auszugleichen.

AISAQ vs. DISKANN: Leistungsbewertung

Nachdem wir verstanden haben, wie sich AISAQ architektonisch von DISKANN unterscheidet, ist die nächste Frage einfach: Wie wirken sich diese Designentscheidungen in der Praxis auf die Leistung und den Ressourcenverbrauch aus? Diese Evaluierung vergleicht AISAQ und DISKANN in drei Dimensionen, die im Milliardenmaßstab am wichtigsten sind: Suchleistung, Speicherverbrauch und Festplattennutzung.

Insbesondere untersuchen wir, wie sich AISAQ verhält, wenn sich die Menge der eingefügten PQ-Daten (INLINE_PQ) ändert. Dieser Parameter steuert direkt den Kompromiss zwischen Indexgröße, Festplatten-E/A und Laufzeiteffizienz. Wir evaluieren beide Ansätze auch für niedrig- und hochdimensionale Vektorarbeitslasten, da die Dimensionalität die Kosten der Abstandsberechnung und die Speicheranforderungen stark beeinflusst.

Aufbau

Alle Experimente wurden auf einem Ein-Knoten-System durchgeführt, um das Indexverhalten zu isolieren und Störungen durch Netzwerk- oder verteilte Systemeffekte zu vermeiden.

Hardware-Konfiguration:

CPU: Intel® Xeon® Platinum 8375C CPU @ 2.90GHz
Speicher: Geschwindigkeit: 3200 MT/s, Typ: DDR4, Größe: 32 GB
Festplatte: 500 GB NVMe SSD

Parameter für den Indexaufbau

{
  "max_degree": 48,
  "search_list_size": 100,
  "inline_pq": 0/12/24/48,  // AiSAQ only
  "pq_code_budget_gb_ratio": 0.125,
  "search_cache_budget_gb_ratio": 0.0,
  "build_dram_budget_gb": 32.0
}

Abfrage-Parameter

{
  "k": 100,
  "search_list_size": 100,
  "beamwidth": 8
}

Benchmark-Methode

Sowohl DISKANN als auch AISAQ wurden mit Knowhere, der in Milvus verwendeten Open-Source-Vektorsuchmaschine, getestet. Für diese Bewertung wurden zwei Datensätze verwendet:

SIFT128D (1M Vektoren): ein bekannter 128-dimensionaler Benchmark, der häufig für die Suche nach Bilddeskriptoren verwendet wird. (Größe des Rohdatensatzes ≈ 488 MB)
Cohere768D (1M Vektoren): ein 768-dimensionaler Einbettungssatz, der typisch für die transformatorbasierte semantische Suche ist. (Größe des Rohdatensatzes ≈ 2930 MB)

Diese Datensätze spiegeln zwei verschiedene reale Szenarien wider: kompakte Bildverarbeitungsmerkmale und große semantische Einbettungen.

Ergebnisse

Sift128D1M (vollständiger Vektor ~488MB)

Cohere768D1M (Voller Vektor ~2930MB)

Analyse

SIFT128D-Datensatz

Beim SIFT128D-Datensatz kann AISAQ mit der Leistung von DISKANN mithalten, wenn alle PQ-Daten inlined werden, so dass die erforderlichen Daten jedes Knotens vollständig in eine einzige 4 KB SSD-Seite passen (INLINE_PQ = 48). Bei dieser Konfiguration wird jede Information, die während der Suche benötigt wird, kolokalisiert:

Vollständiger Vektor: 512B
Nachbarschaftsliste: 48 × 4 + 4 = 196B
PQ-Codes der Nachbarn: 48 × (512B × 0,125) ≈ 3072B
Insgesamt: 3780B

Da der gesamte Knoten in eine Seite passt, ist nur eine Ein/Ausgabe pro Zugriff erforderlich, und AISAQ vermeidet das zufällige Lesen von externen PQ-Daten.

Wenn jedoch nur ein Teil der PQ-Daten inlined wird, müssen die restlichen PQ-Codes von einer anderen Stelle der Festplatte geholt werden. Dies führt zu zusätzlichen zufälligen E/A-Operationen, die den IOPS-Bedarf drastisch erhöhen und zu erheblichen Leistungseinbußen führen.

Cohere768D-Datensatz

Auf dem Cohere768D-Datensatz schneidet AISAQ schlechter ab als DISKANN. Der Grund dafür ist, dass ein 768-dimensionaler Vektor einfach nicht in eine 4 KB SSD-Seite passt:

Vollständiger Vektor: 3072B
Nachbarschaftsliste: 48 × 4 + 4 = 196B
PQ-Codes der Nachbarn: 48 × (3072B × 0,125) ≈ 18432B
Insgesamt: 21.700 B (≈ 6 Seiten)

In diesem Fall erstreckt sich jeder Knoten über mehrere Seiten, selbst wenn alle PQ-Codes inlined sind. Während die Anzahl der E/A-Operationen konstant bleibt, muss jede E/A-Operation viel mehr Daten übertragen, wodurch die SSD-Bandbreite viel schneller verbraucht wird. Sobald die Bandbreite zum begrenzenden Faktor wird, kann AISAQ nicht mehr mit DISKANN mithalten - vor allem bei hochdimensionalen Arbeitslasten, bei denen die Datenmenge pro Knoten schnell wächst.

Anmerkung:

Das Speicherlayout von AISAQ erhöht die Indexgröße auf der Festplatte in der Regel um das 4- bis 6-fache. Dies ist ein bewusster Kompromiss: Vollständige Vektoren, Nachbarlisten und PQ-Codes sind auf der Festplatte untergebracht, um einen effizienten Single-Page-Zugriff während der Suche zu ermöglichen. Dies erhöht zwar die SSD-Nutzung, aber die Festplattenkapazität ist wesentlich billiger als DRAM und lässt sich bei großen Datenmengen leichter skalieren.

In der Praxis können Benutzer diesen Kompromiss durch Anpassen der INLINE_PQ und PQ-Komprimierungsverhältnisse abstimmen. Mit diesen Parametern ist es möglich, Suchleistung, Festplattenbedarf und Gesamtsystemkosten je nach den Anforderungen der Arbeitslast auszugleichen, anstatt durch feste Speichergrenzen eingeschränkt zu sein.

Schlussfolgerung

Die Wirtschaftlichkeit von moderner Hardware ändert sich. Die DRAM-Preise sind nach wie vor hoch, während die Leistung von SSDs rasant gestiegen ist - PCIe 5.0-Laufwerke bieten jetzt eine Bandbreite von über 14 GB/s. Infolgedessen werden Architekturen, die suchkritische Daten von teurem DRAM auf weitaus erschwinglicheren SSD-Speicher verlagern, immer überzeugender. Da die SSD-Kapazität weniger als 30 Mal so viel pro Gigabyte kostet wie DRAM, sind diese Unterschiede nicht mehr nur marginal, sondern haben einen bedeutenden Einfluss auf das Systemdesign.

AISAQ spiegelt diese Verschiebung wider. Durch den Wegfall der Notwendigkeit großer, ständig verfügbarer Speicherzuweisungen können Vektorsuchsysteme auf der Grundlage der Datengröße und der Arbeitslastanforderungen skaliert werden, nicht auf der Grundlage von DRAM-Limits. Dieser Ansatz steht im Einklang mit dem allgemeinen Trend zu All-in-Storage"-Architekturen, bei denen schnelle SSDs eine zentrale Rolle nicht nur bei der Persistenz, sondern auch bei aktiven Berechnungen und Suchvorgängen spielen. Durch das Angebot von zwei Betriebsmodi - Leistung und Skalierung - erfüllt AiSAQ die Anforderungen sowohl der semantischen Suche (die die geringste Latenz erfordert) als auch der RAG (die eine sehr hohe Skalierung, aber eine moderate Latenz erfordert).

Es ist unwahrscheinlich, dass diese Verschiebung auf Vektordatenbanken beschränkt bleibt. Ähnliche Entwurfsmuster zeichnen sich bereits bei der Graphenverarbeitung, der Zeitreihenanalyse und sogar bei Teilen herkömmlicher relationaler Systeme ab, da die Entwickler langjährige Annahmen darüber, wo Daten gespeichert werden müssen, um eine akzeptable Leistung zu erzielen, überdenken. In dem Maße, wie sich die Wirtschaftlichkeit der Hardware weiterentwickelt, werden auch die Systemarchitekturen folgen.

Weitere Einzelheiten zu den hier besprochenen Designs finden Sie in der Dokumentation:

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