Milvus: die Vektordatenbank für große volumes

#Was Milvus anstrebt

Die meisten Vektordatenbanken richten sich an Teamprojekte. Milvus ist auf den industriellen Maßstab ausgelegt: Trennung von Datenspeicherung und Rechenleistung, native horizontale Skalierung auf Kubernetes und ein Katalog von Indizes, mit dem sich Genauigkeit, Speicherbedarf und Geschwindigkeit fein gegeneinander abwägen lassen. Das Projekt gibt an, Zehntausende von Anfragen auf Milliarden von Vektoren verarbeiten zu können und die Daten gleichzeitig durch Streaming-Updates in Echtzeit aktuell zu halten. Das ist eine Architekturentscheidung, nicht bloß eine Sammlung von Funktionen.

Dieser Anspruch hat einen unmittelbaren Nachteil: Bei einem Korpus mit fünfzigtausend Textpassagen kommt diese Leistungsfähigkeit nicht zum Tragen, die Komplexität macht sich dagegen sofort bemerkbar. Die Frage sollte daher nicht lauten: „Ist das die beste Vektordatenbank?“, sondern: „Wird mein Korpus die Größe erreichen, bei der diese Entscheidungen eine Rolle spielen?“

Das Projekt präsentiert sich als eine Datenbank, auf die KI-Entwickler beim Aufbau von Anwendungen für die Text- und Bildsuche, Retrieval-Augmented Generation und Empfehlungssystemen vertrauen können, und gibt an, zahlreiche Unternehmen bei als kritisch eingestuften Anwendungen zu unterstützen. Diese Positionierung verdeutlicht die Zielgruppe: Teams, die ein Produkt entwickeln, das wachsen soll, und keine persönlichen Skripte zur Dokumentensuche in einigen Hundert PDF-Dateien.

#Eine komponentenbasierte Architektur

Bei vollständigem Deployment ist Milvus kein einzelner Prozess, sondern ein Verbund: Abfrageknoten, Datenknoten, ein Koordinationsdienst, ein Objektspeicher und ein Nachrichtenprotokoll. Jede Komponente lässt sich unabhängig dimensionieren – das Projekt hebt hervor, dass sich die Abfrageknoten für eine hohe Leselast und die Datenknoten für eine hohe Schreiblast jeweils separat skalieren lassen. Genau das ist im großen Maßstab erwünscht, und genau darauf kann man auf einem Arbeitsplatzrechner verzichten. Die zustandslosen Microservices auf Kubernetes ermöglichen außerdem eine schnelle Wiederherstellung nach einem Ausfall. Die Unterstützung von Replikaten verbessert die Fehlertoleranz zusätzlich, indem Datensegmente auf mehrere Abfrageknoten geladen werden. Diese Trennung von Rechenleistung und Speicherung unterscheidet eine für den industriellen Maßstab konzipierte Datenbank von einer Datenbank für einen einzelnen Dienst: Sie verursacht laufende Betriebskosten, selbst bei geringem Datenverkehr, was nur wenige Vergleiche vor dem Deployment erwähnen.

#Das Minimum in Python mit Milvus Lite

1. 01
   Verbinden

   Mit from pymilvus import MilvusClient und anschließend client = MilvusClient("milvus_demo.db") öffnen Sie eine lokale Datenbank in einer Datei; ersetzen Sie das Argument durch eine Server-URI, wechseln Sie zu einer vollständigen Bereitstellung, ohne den restlichen Code zu ändern.
2. 02
   Eine Sammlung erstellen

   client.create_collection(collection_name="demo_collection", dimension=1024) — die Dimension muss genau der Dimension Ihres Embedding-Modells entsprechen.
3. 03
   Die Daten einfügen

   res = client.insert(collection_name="demo_collection", data=data), wobei data eine Liste von Dictionaries ist, die jeweils einen Vektor und dessen Metadaten enthalten.
4. 04
   Suchen

   res = client.search(collection_name="demo_collection", data=vecteurs_requete, limit=5, output_fields=["text"]) liefert die fünf nächstgelegenen Textpassagen mit den angeforderten Feldern.

Das Projekt hebt seine Integration mit gängigen KI-Tools hervor — LangChain, LlamaIndex, OpenAI, Hugging Face — und ist damit nach Aussage seiner Autoren ein Vektorspeicher, der sich für Retrieval-gestützte Generierung eignet. Milvus arbeitet sowohl mit Open-Source-Embedding-Modellen als auch mit Embedding-Diensten für Text, Bilder und Videos und stellt ein Hilfsprogramm (pymilvus[model]) bereit, mit dem sich unstrukturierte Daten in Vektoren umwandeln lassen, ohne selbst den Code für den Modellaufruf schreiben oder die Clientbibliothek jedes Anbieters separat verwalten zu müssen.

#Die Indizes und die Wahl des passenden Index

Bei einem lokalen Dokumentenkorpus genügt es meistens, sich eine einzige Zahl zu merken: Unter einer Million Vektoren liegen die Unterschiede zwischen den sechs Indexfamilien im Millisekundenbereich, nicht im Minutenbereich. Die Mühe, die in die Wahl der richtigen Einstellung fließt, wäre fast immer an anderer Stelle im Projekt besser investiert.

Der Rat, der am meisten Zeit spart, bleibt überall derselbe: mit der exakten Suche beginnen. Approximative Indizes lösen ein Skalierungsproblem. Wer sie einführt, bevor dieses Problem auftritt, handelt sich einzustellende Parameter und einen zu messenden Recall ein – im Austausch für Millisekunden, die niemand bemerkt hat. Milvus dokumentiert ausdrücklich diese sechs Familien – HNSW, IVF, FLAT, SCANN, DiskANN und quantisierte Varianten – als jeweils für ein anderes Szenario optimiert, mit GPU-Hardwareunterstützung über CAGRA von NVIDIA für die Indexierung sehr großer Datenmengen. Das Projekt ergänzt diese Indizes um Metadatenfilterung und Bereichssuche, die auf derselben Ebene wie die Vektorsuche selbst optimiert sind, statt als separate Schicht implementiert zu werden, die das Endergebnis verlangsamen würde.

#Was Milvus bei großen Datenmengen auszeichnet

Neben den Indizes erklären mehrere Funktionen, warum große Organisationen Milvus einer einfacheren Alternative vorziehen. Die Mandantenfähigkeit lässt sich auf vier möglichen Isolationsebenen konfigurieren — Datenbank, Collection, Partition oder Partitionsschlüssel. Dadurch kann ein einzelner Cluster einige Dutzend bis hin zu Millionen Mandanten bedienen, ohne Einbußen bei der Suchleistung oder der Granularität der Zugriffskontrolle. Bei der Speicherung in heißen und kalten Speicherbereichen werden häufig abgerufene Daten im Arbeitsspeicher oder auf SSDs abgelegt, während selten abgerufene Daten auf langsamere, kostengünstigere Speichermedien ausgelagert werden. Das senkt die Kosten, ohne die Leistung kritischer Aufgaben zu beeinträchtigen.

Bei der Suche unterstützt Milvus nativ die Volltextsuche mit BM25 sowie gelernte Sparse-Embeddings wie SPLADE und BGE-M3, zusätzlich zur semantischen Suche mit dichten Vektoren. Sparse-Vektoren und dichte Vektoren können in derselben Collection nebeneinander bestehen; Reranking-Funktionen führen die Ergebnisse mehrerer Abfragen zusammen – eine hybride Suche, die vom Ansatz her mit dem Angebot von Qdrant vergleichbar ist, hier aber auf BM25 statt auf einer generischen Zusammenführung von Scores basiert. Bei der Sicherheit hebt das Projekt die verpflichtende Authentifizierung, die TLS-Verschlüsselung der Kommunikation und die rollenbasierte Zugriffskontrolle (RBAC) hervor: drei Elemente, die erwartet werden, sobald eine Datenbank mehrere Anwendungen oder Teams bedient, und die für eine Instanz, die nur auf localhost lauscht, deutlich weniger kritisch sind.

#Lokal: Was das bedeutet

Ressourcen

Eine vollständige Bereitstellung erfordert mehrere Container und mehrere Gigabyte Arbeitsspeicher, noch bevor Ihr Sprachmodell hinzukommt: Koordinationsdienst, Abfrageknoten, Datenknoten, Objektspeicher und Nachrichtenlog laufen jeweils separat.

Speicherbedarf der Vektoren

Etwa 4 KB pro Vektor mit 1.024 Dimensionen bei voller Präzision, ohne den Speicherbedarf des Indexes. Diese Rechnung bestimmt die Architektur, nicht die Funktionen – und sie gilt unabhängig davon, ob Sie Milvus, Qdrant oder pgvector verwenden.

Betrieb

Backups, Versionsupdates, Überwachung: Eine echte verteilte Datenbank braucht jemanden, der ihren Betrieb fachkundig betreut. Das Milvus-Ökosystem umfasst Attu, eine grafische Verwaltungsoberfläche, und Birdwatcher für das System-Debugging – zwei Werkzeuge, die dennoch Kenntnisse der zugrunde liegenden Architektur voraussetzen.

Die GPU bleibt dem Modell vorbehalten

Die Dokumentenkodierung und die Inferenz konkurrieren bereits um die Grafikkarte; die Vektorsuche beansprucht dagegen vor allem Prozessor und Arbeitsspeicher, außer wenn bei sehr großen Datenmengen der Aufbau eines GPU-Index über CAGRA ausdrücklich aktiviert ist.

#Wann Milvus die richtige Wahl ist

Die richtige Frage lautet nie „Welche Datenbank bietet die meisten Funktionen?“, sondern „Welche dieser Funktionen wird mein Projekt tatsächlich nutzen?“. Mandantenfähigkeit auf vier Ebenen, Hot- und Cold-Storage, RBAC und hybride BM25-Suche sind für Organisationen gedacht, die Tausende von Nutzern bedienen und Compliance-Anforderungen erfüllen müssen; auf einem persönlichen Rechner oder bei internen Werkzeugen für ein kleines Team bleiben diese Mechanismen ungenutzt, während der Aufwand für ihre Konfiguration weiterhin besteht. Milvus ist gerechtfertigt, wenn die Entwicklung des Projekts — nicht sein aktueller Stand — innerhalb eines überschaubaren Zeitraums auf diese Anforderungen zusteuert.

• Qdrant: der spezialisierte Dienst, der sich einfacher betreiben lässt
• pgvector: in PostgreSQL bleiben
• FAISS: die Bibliothek statt des Dienstes
• Die vollständige RAG-Pipeline in Python
• Das lokale RAG-Kit QuelLLM
• Quelle: offizielles Milvus-Repository auf GitHub
• Quelle: offizielle Dokumentation von Milvus Lite
• Quelle: Überblick über die verteilte Architektur von Milvus

#FAQ