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, und verwaltet 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

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

Abfrageknoten rufen inkrementelle Protokolldaten ab und verwandeln sie in wachsende Segmente, indem sie den Protokollbroker abonnieren, historische Daten aus dem Objektspeicher laden und eine hybride Suche zwischen Vektor- und Skalardaten durchführen.

Datenknoten

Datenknoten rufen inkrementelle Protokolldaten ab, indem sie sich beim Log-Broker anmelden, Mutationsanforderungen verarbeiten und Protokolldaten in Protokoll-Snapshots packen und im Objektspeicher speichern.

Index-Knoten

Indexknoten bauen Indizes auf. Sie 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 für diesen Zweck ausgewählt hat. Milvus verwendet etcd auch für die Serviceregistrierung und Zustandsprüfungen.

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. Objektspeicher haben jedoch eine hohe Zugriffslatenz und werden 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 Distributed verwendet Pulsar als Log Broker, während Milvus Standalone RocksDB verwendet. Der Log-Broker kann ohne weiteres durch Streaming-Data-Storage-Plattformen wie Kafka ersetzt werden.

Milvus 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.