Streaming-Dienst
Der Streaming Service ist ein Konzept für das interne Streaming-Systemmodul von Milvus, das auf dem Write-Ahead Log (WAL) aufbaut, um verschiedene Streaming-bezogene Funktionen zu unterstützen. Dazu gehören die Aufnahme/Abonnement von Streaming-Daten, die Wiederherstellung des Cluster-Zustands im Fehlerfall, die Umwandlung von Streaming-Daten in historische Daten und die Abfrage wachsender Datenmengen. Architektonisch setzt sich der Streaming Service aus drei Hauptkomponenten zusammen:
Verteilter Streaming-Bogen
Streaming-Koordinator: Eine logische Komponente im Koordinator-Knoten. Er verwendet Etcd für die Service-Erkennung, um verfügbare Streaming-Knoten zu finden, und ist für die Bindung von WAL an die entsprechenden Streaming-Knoten verantwortlich. Außerdem registriert er Dienste, um die WAL-Verteilungstopologie offenzulegen, so dass Streaming-Clients den geeigneten Streaming-Knoten für eine bestimmte WAL kennen.
Streaming-Knoten-Cluster: Ein Cluster von Streaming-Worker-Nodes, die für alle Streaming-Verarbeitungsaufgaben zuständig sind, wie z. B. das Anhängen von WALs, die Wiederherstellung von Zuständen und die Abfrage wachsender Daten.
Streaming-Client: Ein intern entwickelter Milvus-Client, der grundlegende Funktionalitäten wie Service Discovery und Readiness Checks kapselt. Er wird verwendet, um Vorgänge wie das Schreiben von Nachrichten und Abonnements zu initiieren.
Nachricht
Der Streaming Service ist ein loggesteuertes Streaming-System, daher werden alle Schreiboperationen in Milvus (wie DML und DDL) als Nachrichten abstrahiert.
Jeder Nachricht wird vom Streaming Service ein Timestamp Oracle (TSO) Feld zugewiesen, das die Reihenfolge der Nachricht im WAL angibt. Die Reihenfolge der Nachrichten bestimmt die Reihenfolge der Schreiboperationen in Milvus. Dadurch ist es möglich, den letzten Clusterzustand aus den Protokollen zu rekonstruieren.
Jede Nachricht gehört zu einem bestimmten VChannel (Virtual Channel) und behält bestimmte invariante Eigenschaften innerhalb dieses Kanals bei, um die Konsistenz der Operationen zu gewährleisten. So muss beispielsweise eine Insert-Operation immer vor einer DropCollection-Operation auf demselben Kanal erfolgen.
Die Nachrichtenreihenfolge in Milvus kann wie folgt aussehen:
Reihenfolge der Nachrichten
WAL-Komponente
Um eine große horizontale Skalierbarkeit zu unterstützen, ist die WAL von Milvus keine einzelne Protokolldatei, sondern ein Verbund aus mehreren Protokollen. Jedes Protokoll kann unabhängig voneinander die Streaming-Funktionalität für mehrere VChannels unterstützen. Zu jedem Zeitpunkt darf eine WAL-Komponente auf genau einem Streaming-Knoten arbeiten. Diese Einschränkung wird sowohl durch einen Fencing-Mechanismus des zugrunde liegenden WAL-Speichers als auch durch den Streaming-Koordinator gewährleistet.
Weitere Merkmale der WAL-Komponente sind:
Segment Lifecycle Management: Die WAL verwaltet den Lebenszyklus der einzelnen Segmente auf der Grundlage von Richtlinien wie Speicherbedingungen, Segmentgröße und Leerlaufzeit.
Unterstützung von Basistransaktionen: Da jede Nachricht eine Größenbeschränkung hat, unterstützt die WAL-Komponente einfache Transaktionen, um atomare Schreibvorgänge auf VChannel-Ebene zu ermöglichen.
Ferngesteuertes Schreiben von Protokollen mit hoher Parallelität: Milvus unterstützt Remote Message Queues von Drittanbietern als WAL-Speicher. Um die Round-Trip-Latenz (RTT) zwischen dem Streaming-Knoten und dem Remote-WAL-Speicher zu verringern und den Schreibdurchsatz zu verbessern, unterstützt der Streaming-Dienst gleichzeitige Protokollschreibvorgänge. Die Nachrichtenreihenfolge wird durch TSO und TSO-Synchronisierung beibehalten, und die Nachrichten in der WAL werden in TSO-Reihenfolge gelesen.
Vorausschauender Schreibpuffer: Nachdem Nachrichten in die WAL geschrieben wurden, werden sie vorübergehend in einem Write-Ahead Buffer gespeichert. Dies ermöglicht das Lesen von Protokollen im Nachhinein, ohne dass Nachrichten aus einem entfernten WAL-Speicher abgerufen werden müssen.
Mehrere WAL-Speicher werden unterstützt: Woodpecker, Pulsar, Kafka. Wenn Sie Woodpecker im Zero-Disk-Modus verwenden, können Sie die Abhängigkeit vom entfernten WAL-Speicher aufheben.
Wiederherstellungsspeicher
Die Komponente Recovery Storage läuft immer auf dem Streaming-Knoten, auf dem sich die entsprechende WAL-Komponente befindet.
Sie ist für die Umwandlung von Streaming-Daten in persistente historische Daten und deren Speicherung im Objektspeicher verantwortlich.
Außerdem übernimmt sie die Wiederherstellung des Speicherzustands für die WAL-Komponente auf dem Streaming-Knoten.
Wiederherstellungsspeicher
Abfrage-Delegator
Der Query Delegator läuft auf jedem Streaming-Knoten und ist für die Ausführung inkrementeller Abfragen auf einem einzelnen Shard zuständig. Er generiert Abfragepläne, leitet sie an die entsprechenden Abfrageknoten weiter und aggregiert die Ergebnisse.
Darüber hinaus ist der Abfragedelegator für die Weiterleitung von Löschvorgängen an andere Abfrageknoten zuständig.
Der Abfragedelegator arbeitet immer zusammen mit der WAL-Komponente auf demselben Streaming-Knoten. Wenn die Sammlung jedoch mit Mehrfachvervielfältigung konfiguriert ist, werden N-1 Delegatoren auf den anderen Streaming Nodes eingesetzt.
WAL-Lebensdauer und Warten auf Bereitschaft
Durch die Trennung von Rechenknoten und Speicher kann Milvus die WAL leicht von einem Streaming-Knoten auf einen anderen übertragen und so eine hohe Verfügbarkeit des Streaming-Dienstes erreichen.
WAL-Lebensdauer
Warten auf Bereitschaft
Wenn die Wal auf einen neuen Streaming-Knoten übertragen wird, wird der Client feststellen, dass der alte Streaming-Knoten einige Anfragen zurückweist. In der Zwischenzeit wird die WAL auf dem neuen Streaming-Knoten wiederhergestellt, und der Client wartet darauf, dass die WAL auf dem neuen Streaming-Knoten bereit für den Dienst ist.
Warten auf Bereitschaft