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-Dienst

Der Koordinatordienst weist den Arbeitsknoten Aufgaben zu und fungiert als Gehirn des Systems. Zu den Aufgaben, die er übernimmt, gehören die Verwaltung der Clustertopologie, der Lastausgleich, die Erzeugung von Zeitstempeln, die Datendeklaration und die Datenverwaltung.

Es gibt drei Arten von Koordinatoren: Stammkoordinator (Root Coord), Datenkoordinator (Data Coord) und Abfragekoordinator (Query Coord).

Wurzelkoordinator (Root Coord)

Der Root-Koordinator bearbeitet Data Definition Language (DDL)- und Data Control Language (DCL)-Anfragen, wie z. B. das Erstellen oder Löschen von Collections, Partitionen oder Indizes, sowie die Verwaltung von TSO (Timestamp Oracle) und die Ausgabe von Zeittickern.

Abfragekoordinator (query coord)

Der Abfragekoordinator verwaltet die Topologie und den Lastausgleich für die Abfrageknoten sowie die Weitergabe von wachsenden Segmenten an geschlossene Segmente.

Datenkoordinator (Datenkoordinator)

Der Datenkoordinator verwaltet die Topologie der Daten- und Indexknoten, pflegt die Metadaten und stößt das Flushen, Verdichten und Erstellen von Indizes sowie andere Datenoperationen im Hintergrund an.

Worker-Knoten

Die Arme und Beine. Worker-Knoten sind stumme Executors, die den Anweisungen des Coordinator-Dienstes folgen und DML-Befehle (Data Manipulation Language) des Proxys ausführen. 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:

Abfrageknoten

Der Abfrageknoten ruft inkrementelle Protokolldaten ab und verwandelt sie in wachsende Segmente, indem er den Protokollbroker abonniert, lädt historische Daten aus dem Objektspeicher und führt eine hybride Suche zwischen Vektor- und Skalardaten durch.

Datenknoten

Der Datenknoten ruft inkrementelle Protokolldaten ab, indem er sich beim Log-Broker anmeldet, verarbeitet Mutationsanforderungen und packt Protokolldaten in Protokoll-Snapshots und speichert sie im Objektspeicher.

Index-Knoten

Der Index-Knoten baut Indizes auf. Indexknoten müssen nicht speicherresident sein und können mit dem serverlosen Framework implementiert werden.

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 Cold-Hot-Datentrennung in einem speicher- oder SSD-basierten Cache-Pool.

Log-Broker

Der Log-Broker ist ein Pub-Sub-System, das Playback unterstützt. Er ist für die Persistenz der Streaming-Daten und die Ereignisbenachrichtigung zuständig. Er stellt auch die Integrität der inkrementellen Daten sicher, wenn sich die Arbeitsknoten von einem Systemausfall erholen. Milvus-Cluster verwendet Pulsar als Log-Broker; Milvus Standalone verwendet RocksDB als Log-Broker. Außerdem kann der Log-Broker ohne weiteres durch Streaming-Data-Storage-Plattformen wie Kafka ersetzt werden.

Milvus ist um den Log-Broker herum aufgebaut und folgt dem "Log as Data"-Prinzip, d. h. Milvus unterhält keine physische Tabelle, sondern garantiert die Zuverlässigkeit der Daten durch Logging-Persistenz und Snapshot-Logs.

Log_Mechanismus

Der Log-Broker ist das Rückgrat von Milvus. Er ist für die Persistenz der Daten und die Disaggregation von Lese- und Schreibzugriffen zuständig, dank seines eingebauten Pub-Sub-Mechanismus. Die obige Abbildung zeigt eine vereinfachte Darstellung des Mechanismus, bei dem das System in zwei Rollen unterteilt ist, den Log-Broker (zur Aufrechterhaltung der Log-Sequenz) und den Log-Subscriber. Ersterer zeichnet alle Operationen auf, die den Zustand der Sammlungen verändern; letzterer abonniert die Log-Sequenz, um die lokalen Daten zu aktualisieren, und bietet Dienste in Form von Nur-Lese-Kopien an. Der Pub-Sub-Mechanismus bietet auch Raum für die Erweiterbarkeit des Systems im Hinblick auf die Erfassung von Änderungsdaten (CDC) und die globale Verteilung.

Was kommt als nächstes

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