Milvus Architektur Übersicht
Milvus ist eine quelloffene, Cloud-native Vektordatenbank, die für eine leistungsstarke Ähnlichkeitssuche in großen Vektordatensätzen entwickelt wurde. Sie basiert auf beliebten Vektorsuchbibliotheken wie Faiss, HNSW, DiskANN und SCANN und unterstützt KI-Anwendungen und unstrukturierte Datenabfrageszenarien. Bevor Sie fortfahren, machen Sie sich bitte mit den Grundprinzipien der Einbettungssuche vertraut.
Architektur-Diagramm
Das folgende Diagramm veranschaulicht die High-Level-Architektur von Milvus und zeigt das modulare, skalierbare und Cloud-native Design mit vollständig disaggregierten Speicher- und Berechnungsebenen.
Architektur_Diagramm
Architektonische Grundsätze
Milvus folgt dem Prinzip der Disaggregation von Daten- und Steuerungsebene und umfasst vier Hauptschichten, die in Bezug auf Skalierbarkeit und Disaster Recovery voneinander unabhängig sind. Diese Shared-Storage-Architektur mit vollständig disaggregierten Speicher- und Rechenschichten ermöglicht die horizontale Skalierung von Rechenknoten, während Woodpecker als Zero-Disk-WAL-Schicht implementiert wird, um die Elastizität zu erhöhen und den betrieblichen Overhead zu reduzieren.
Durch die Trennung der Stream-Verarbeitung in Streaming Node und der Batch-Verarbeitung in Query Node und Data Node erreicht Milvus eine hohe Leistung bei gleichzeitiger Erfüllung der Echtzeitverarbeitungsanforderungen.
Detaillierte Schichtenarchitektur
Schicht 1: Zugriffsschicht
Die Zugriffsschicht besteht aus einer Gruppe von zustandslosen Proxys und ist die vorderste Schicht des Systems und der Endpunkt für die Benutzer. Sie validiert Client-Anfragen und reduziert die zurückgegebenen Ergebnisse:
- Der Proxy ist an sich zustandslos. Er bietet eine einheitliche Dienstadresse unter Verwendung von Lastausgleichskomponenten wie Nginx, Kubernetes Ingress, NodePort und LVS.
- Da Milvus eine MPP-Architektur (Massively Parallel Processing) verwendet, aggregiert der Proxy die Zwischenergebnisse und verarbeitet sie nach, bevor er die endgültigen Ergebnisse an den Client zurückgibt.
Schicht 2: Koordinator
Der Coordinator dient als das Gehirn von Milvus. Zu jedem Zeitpunkt ist genau ein Koordinator im gesamten Cluster aktiv, der für die Aufrechterhaltung der Clustertopologie, die Planung aller Aufgabentypen und die Gewährleistung der Konsistenz auf Clusterebene verantwortlich ist.
Im Folgenden sind einige der Aufgaben aufgeführt, die vom Coordinator bearbeitet werden:
- DDL/DCL/TSO-Verwaltung: Bearbeitung von Data Definition Language (DDL)- und Data Control Language (DCL)-Anfragen, wie z. B. das Erstellen oder Löschen von Sammlungen, Partitionen oder Indizes, sowie die Verwaltung von Timestamp Oracle (TSO) und die Ausgabe von Zeittickern.
- Verwaltung von Streaming-Diensten: Verbindet das Write-Ahead Log (WAL) mit Streaming Nodes und bietet eine Service Discovery für den Streaming Service.
- Abfrage-Management: Verwaltet die Topologie und den Lastausgleich für die Abfrageknoten und liefert und verwaltet die Abfrageansichten, um das Abfrage-Routing zu steuern.
- Verwaltung historischer Daten: Verteilt Offline-Aufgaben wie Verdichtung und Indexerstellung an Datenknoten und verwaltet die Topologie von Segmenten und Datenansichten.
Schicht 3: Arbeiterknoten
Die Arme und Beine. Worker Nodes sind stumme Ausführungsknoten, die den Anweisungen des Koordinators folgen. Worker Nodes sind dank der Trennung von Speicherung und Berechnung zustandslos und können die Skalierung des Systems und die Wiederherstellung im Notfall erleichtern, wenn sie in Kubernetes eingesetzt werden. Es gibt drei Arten von Worker Nodes:
Streaming Node
Der Streaming Node dient als "Mini-Gehirn" auf Shard-Ebene und bietet Konsistenzgarantien auf Shard-Ebene sowie Fehlerbehebung auf der Grundlage des zugrunde liegenden WAL-Speichers. Gleichzeitig ist der Streaming Node auch für die Abfrage wachsender Daten und die Erstellung von Abfrageplänen zuständig. Darüber hinaus übernimmt er auch die Umwandlung wachsender Daten in versiegelte (historische) Daten.
Abfrageknoten
Der Abfrageknoten lädt die historischen Daten aus dem Objektspeicher und ermöglicht die Abfrage der historischen Daten.
Datenknoten
Der Datenknoten ist für die Offline-Verarbeitung historischer Daten zuständig, z. B. für die Verdichtung und den Aufbau von Indizes.
Schicht 4: Speicherung
Die Speicherung ist das Herzstück des Systems und für die Datenpersistenz verantwortlich. Er umfasst Metaspeicher, Log-Broker und Objektspeicher.
Metaspeicher
Der Metaspeicher speichert Schnappschüsse von Metadaten wie Sammelschemata und Prüfpunkte für den Nachrichtenverbrauch. Die Speicherung von Metadaten erfordert extrem hohe Verfügbarkeit, starke Konsistenz und Transaktionsunterstützung, weshalb Milvus etcd als Metaspeicher gewählt hat. Milvus verwendet etcd auch für die Serviceregistrierung und Zustandsüberprüfung.
Objektspeicher
Der Objektspeicher speichert Snapshot-Dateien von Protokollen, Indexdateien für skalare und Vektordaten sowie Zwischenergebnisse von Abfragen. Milvus verwendet MinIO als Objektspeicher und kann problemlos auf AWS S3 und Azure Blob eingesetzt werden, zwei der beliebtesten und kostengünstigsten Speicherdienste der Welt. Der Objektspeicher hat jedoch eine hohe Zugriffslatenz und wird nach der Anzahl der Abfragen berechnet. Um die Leistung zu verbessern und die Kosten zu senken, plant Milvus die Implementierung einer Kalt-Warm-Datentrennung auf einem speicher- oder SSD-basierten Cache-Pool.
WAL-Speicher
Die WAL-Speicherung (Write-Ahead Log) ist die Grundlage für die Haltbarkeit und Konsistenz von Daten in verteilten Systemen. Bevor eine Änderung übertragen wird, wird sie zunächst in einem Protokoll aufgezeichnet, um sicherzustellen, dass Sie im Falle eines Fehlers genau dort wiederhergestellt werden können, wo Sie aufgehört haben.
Zu den gängigen WAL-Implementierungen gehören Kafka, Pulsar und Woodpecker. Im Gegensatz zu herkömmlichen plattenbasierten Lösungen verwendet Woodpecker ein Cloud-natives Design ohne Platten, das direkt in den Objektspeicher schreibt. Dieser Ansatz lässt sich mühelos mit Ihren Anforderungen skalieren und vereinfacht den Betrieb, da der Overhead der Verwaltung lokaler Festplatten entfällt.
Indem jeder Schreibvorgang im Voraus protokolliert wird, garantiert die WAL-Schicht einen zuverlässigen, systemweiten Mechanismus für Wiederherstellung und Konsistenz - egal wie komplex Ihre verteilte Umgebung wird.
Datenfluss und API-Kategorien
Die Milvus-APIs sind nach ihrer Funktion kategorisiert und folgen bestimmten Pfaden durch die Architektur:
| API-Kategorie | Vorgänge | Beispiel-APIs | Architektur Fluss |
|---|---|---|---|
| DDL/DCL | Schema & Zugriffskontrolle | createCollection, dropCollection, hasCollection, createPartition | Zugriffsschicht → Koordinator |
| DML | Datenmanipulation | insert, delete, upsert | Zugriffsschicht → Streaming Worker Node |
| DQL | Datenabfrage | search, query | Zugriffsschicht → Batch-Worker-Knoten (Abfrageknoten) |
Beispiel Datenfluss: Suchvorgang
- Client sendet eine Suchanfrage über SDK/RESTful API
- Load Balancer leitet Anfrage an verfügbaren Proxy in der Zugriffsschicht weiter
- Proxy verwendet Routing-Cache, um Zielknoten zu bestimmen; kontaktiert Koordinator nur, wenn Cache nicht verfügbar ist
- Der Proxy leitet die Anfrage an die entsprechenden Streaming-Knoten weiter, die sich dann mit den Abfrageknoten für die Suche nach versiegelten Daten abstimmen, während die Suche nach wachsenden Daten lokal ausgeführt wird
- Abfrageknoten laden bei Bedarf versiegelte Segmente aus dem Objektspeicher und führen eine Suche auf Segmentebene durch
- Die Suchergebnisse werden auf mehreren Ebenen reduziert: Abfrageknoten reduzieren die Ergebnisse über mehrere Segmente hinweg, Streaming-Knoten reduzieren die Ergebnisse von Abfrageknoten und der Proxy reduziert die Ergebnisse von allen Streaming-Knoten, bevor er sie an den Client zurückgibt
Beispiel Datenfluss: Dateneinfügung
- Client sendet eine Einfügeanforderung mit Vektordaten
- Zugriffsschicht validiert und leitet Anfrage an Streaming Node weiter
- Streaming Node protokolliert den Vorgang im WAL-Speicher, um ihn dauerhaft zu speichern
- Die Daten werden in Echtzeit verarbeitet und für Abfragen zur Verfügung gestellt
- Wenn Segmente die Kapazität erreichen, löst der Streaming Node die Konvertierung in versiegelte Segmente aus
- Der Datenknoten führt die Verdichtung durch, erstellt Indizes auf den versiegelten Segmenten und speichert die Ergebnisse im Objektspeicher.
- Abfrageknoten laden die neu erstellten Indizes und ersetzen die entsprechenden wachsenden Daten
Was kommt als nächstes?
- Erkunden Sie die Hauptkomponenten für detaillierte Implementierungsspezifika
- Lernen Sie die Arbeitsabläufe der Datenverarbeitung und Optimierungsstrategien kennen
- Verstehen Sie das Konsistenzmodell und die Transaktionsgarantien in Milvus