Disaggregation von Speicherung und Datenverarbeitung

Nach dem Prinzip der Disaggregation von Daten- und Steuerungsebene umfasst Milvus vier Schichten, die in Bezug auf Skalierbarkeit und Disaster Recovery voneinander unabhängig sind.

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 und verarbeitet der Proxy die Zwischenergebnisse, bevor er die endgültigen Ergebnisse an den Client zurückgibt.

Koordinator

Der Coordinator dient als Gehirn von Milvus. Zu jedem Zeitpunkt ist genau ein Coordinator 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.

Worker-Knoten

Die Arme und Beine. Worker-Knoten sind stumme Ausführungseinheiten, die den Anweisungen des Koordinators folgen. Worker-Knoten sind dank der Trennung von Speicherung und Berechnung zustandslos und können die Skalierung des Systems und die Notfallwiederherstellung erleichtern, wenn sie in Kubernetes eingesetzt werden. Es gibt drei Arten von Worker Nodes:

Streaming-Knoten

Der Streaming Node dient als "Mini-Gehirn" auf Shard-Ebene und bietet Konsistenzgarantien auf Shard-Ebene sowie Fehlerwiederherstellung auf der Grundlage des zugrunde liegenden WAL-Speichers. Gleichzeitig ist der Streaming Node auch für die Abfrage von wachsenden 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 Indexaufbau.

Speicherung

Der Speicher 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 - ganz gleich, wie komplex Ihre verteilte Umgebung wird.

Was kommt als Nächstes?

• Lesen Sie Hauptkomponenten für weitere Details über die Milvus-Architektur.