Du arbeitest an einem Projekt, bei dem die Datenbank täglich um Millionen neuer Vektoren wächst. Anfangs passt alles in den Arbeitsspeicher – Antwortzeiten sind niedrig, Kosten überschaubar. Doch der Index wird größer, die monatliche Cloud-Rechnung steigt. Irgendwann kostet der reine RAM für deinen Vektorindex mehrere tausend Euro pro Monat. Wie optimiert man die Vektorsuche, wenn RAM zur teuren Ressource wird?
Die Antwort liegt in der Architektur der Approximate Nearest Neighbor (ANN) Algorithmen, genauer in der Entscheidung zwischen In-Memory und On-Disk Indizes. Eine Vektordatenbank besteht aus drei Komponenten: den Embeddings (numerische Repräsentationen des Text- oder Bildkorpus), dem Suchalgorithmus samt Indexstruktur (Qualität und Geschwindigkeit) und der Speicherung (RAM, Festplatte oder hybrid). Embeddings sind in der Literatur ausführlich behandelt. Der Fokus liegt hier auf den Suchalgorithmen – speziell den ANN-Verfahren.
Exakte Suche vs. Approximate Nearest Neighbor
Zwei grundlegende Ansätze: Die exakte Suche (kNN) durchläuft alle Einträge und berechnet für jeden den Abstand zur Anfrage. Sie liefert perfekte Ergebnisse, aber die Latenz skaliert linear mit der Indexgröße. Bei einer Million Vektoren wird es langsam, bei einer Milliarde unpraktikabel. Viele moderne Vektordatenbanken verzichten bei kleinen Sammlungen auf den Indexbau und fallen auf kNN zurück – der Overhead für ein paar tausend Vektoren lohnt nicht.
ANN-Algorithmen vermeiden den vollständigen Scan, indem sie Abkürzungen im Datenraum schaffen. Die meisten modernen Vertreter – HNSW oder DiskANN – nutzen eine Graphstruktur für schnelle Sprünge zu den nächsten Nachbarn. Die Kunst liegt in der Balance: Ein guter ANN-Algorithmus opfert ein wenig Genauigkeit, um Latenz und Skalierbarkeit drastisch zu verbessern.
Zwei Welten: In-Memory vs. On-Disk ANN
Der Artikel unterscheidet zwei Gruppen von ANN-Algorithmen: solche, die den gesamten Index oder große Teile im RAM halten (In-Memory), und solche, die RAM sparen, indem sie Daten auf der Festplatte belassen und nur eine schlanke Routing-Schicht im Speicher vorhalten (On-Disk). Beide können prinzipiell sowohl im RAM als auch auf der Festplatte betrieben werden, liefern aber die besten Ergebnisse, wenn man sie wie vorgesehen einsetzt.
Die bekannteste In-Memory-ANN ist HNSW (Hierarchical Navigable Small World). Sie verwendet einen mehrschichtigen Graphen: Eine Anfrage startet in der obersten, dünn besetzten Ebene, hangelt sich von Knoten zu Knoten zum nächsten Nachbarn, steigt dann in die nächsttiefere Ebene ab und wiederholt das Spiel, bis sie in der dichten unteren Ebene landet. Solange der gesamte Graph im RAM liegt, liefert HNSW extrem niedrige Latenzen – oft einstellige Millisekunden. Der Haken: Sobald der Index zu groß wird, um in den RAM zu passen – oder die RAM-Kosten explodieren –, bleibt nur der Umzug auf die Festplatte. Und da zeigt HNSW seine Schwäche: Die Graphstruktur erzeugt viele nicht-sequentielle Festplattenzugriffe bei jedem Hop. Die Folge: Latenzen steigen von Millisekunden auf Hunderte von Millisekunden oder mehr.
Genau hier setzen On-Disk-ANN-Algorithmen an. Der Autor stellt zwei prominente Vertreter vor: SPANN und DiskANN.
SPANN: Cluster-basierte On-Disk-Suche
SPANN folgt dem Vorbild des invertierten Index (IVF): Die Vektoren werden in Cluster gruppiert, jedes Cluster wird durch einen Zentroiden repräsentiert. Die Zentroiden – quasi die Routing-Information – bleiben im RAM, während die eigentlichen Vektoren eines Clusters auf der Festplatte hintereinander abgelegt werden. Das sorgt für sequentielle Lesevorgänge. Bei der Suche findet die Anfrage zunächst die vielversprechendsten Cluster über ihre Zentroiden und lädt dann die Vektoren dieser Cluster von der Festplatte als Block. Dadurch reduziert sich die Anzahl der I/O-Operationen drastisch. Der Autor verweist auf Turbopuffer, eine Datenbank, die auf SPFresh aufbaut (einem Nachfolger von SPANN), oder auf Chroma DB in der Cloud-Version.
DiskANN: Single-Layer-Graph mit Quantisierung
DiskANN verwendet einen anderen Ansatz: einen einschichtigen Graphen namens Vamana. Die Idee ist, die Anzahl der Hops und damit die Anzahl der zufälligen Festplattenzugriffe zu minimieren, indem der Graph bewusst einige längere Kanten enthält – nicht nur die nächsten Nachbarn. Zusätzlich werden die Vektoren stark quantisiert (auf wenige Bits) im RAM gehalten, während die vollen Float-Präzisionsvektoren auf der Festplatte liegen. So kann die Routing-Schicht schnell entscheiden, welche Knoten besucht werden müssen, und lädt dann nur deren vollständige Vektoren bei Bedarf. DiskANN findet sich beispielsweise in Milvus oder in einer PostgreSQL-Erweiterung (pg_diskann).
Die Kostenfrage: RAM vs. Festplatte
Eine Rechnung: Cloud-RAM kostet etwa 5 US-Dollar pro Gigabyte und Monat, EBS (Remote Disk) liegt bei rund 0,08 – 0,10 $, lokale NVMe-SSDs bei 0,20 – 0,25 $. RAM ist etwa 50‑mal teurer als Remote Disk. Für einen Index mit 100 Millionen Vektoren in 1024 Dimensionen (Float32) benötigt man bei einer Replikation von 3 etwa 1,2 TB Speicher. Nicht quantisiert im RAM: rund 6000 $ pro Monat. Mit skalare Quantisierung (25 % Speicher) immer noch 1500 $. Dagegen: Remote Disk knapp 120 $, lokale Disk etwa 300 $. Das Verhältnis wird extremer, wenn der Index auf eine Milliarde Vektoren wächst – dann kostet RAM nicht quantisiert etwa 60.000 $.
Diese Zahlen zeigen: On-Disk-Verfahren sind nicht nur eine Notlösung, sondern oft die einzige wirtschaftlich sinnvolle Option, sobald die Indizes in den Milliardenbereich gehen.
Der Preis der Ersparnis: Latenz
Die Kostensenkung ist nicht kostenlos. On-Disk-ANN-Indexe müssen die Daten von der Festplatte laden, das ist immer langsamer als ein RAM-Zugriff. Die tatsächliche Latenz hängt stark von der Hardware und dem Cache-Status ab. Der Autor zitiert Zahlen aus dem SPANN-Paper: 90 % Recall bei etwa einer Millisekunde mittlerer Latenz auf einer einzelnen Maschine mit lokaler SSD. In der Praxis, etwa bei Turbopuffer, misst man bei warmem Index auf schnellem Speicher etwa 14 Millisekunden (p50), bei kaltem Index aus dem Objektspeicher dagegen 874 Millisekunden – ein Faktor 60 allein durch den Cache. Generell gilt: On-Disk-ANN ist langsamer als HNSW im RAM, aber für viele Anwendungen (etwa RAG, wo die Ergebnisse ohnehin an ein Reranking und ein LLM weitergereicht werden) sind 100 Millisekunden Aufschlag völlig unkritisch. Nur wenn es auf jede Millisekunde ankommt – etwa bei agentischen Gedächtnissystemen mit vielen Abfragen pro Anfrage –, sollte man besser beim teuren RAM bleiben.
Wähle mit Bedacht
Die Entscheidung zwischen In-Memory- und On-Disk-ANN ist eine Abwägung von Kosten, Latenz und Skalierungsanforderungen. Für kleine bis mittlere Indizes (bis zu einigen zehn Millionen Vektoren) ist HNSW im RAM die beste Wahl – schnell, ausgereift, und die Kosten sind noch überschaubar. Sobald die Indizes jedoch in die Hunderte Millionen oder Milliarden gehen, werden On-Disk-Algorithmen wie SPANN oder DiskANN wirtschaftlich. Selbst wenn die Latenz etwas höher ist: Wenn man die Daten richtig organisiert – lokale SSDs statt Remote Disk, mit Quantisierung und warmem Cache –, kommt man in Bereiche, die für die meisten KI-Anwendungen völlig akzeptabel sind.
RAM ist schnell, aber teuer. Festplatte ist langsam, aber günstig. Die moderne Vektorsuche bietet clevere Algorithmen, die den Unterschied überbrücken – wenn man die Trade-offs versteht und die richtige Architektur für den eigenen Anwendungsfall wählt.
Quelle: towardsdatascience.com
