Hauptkomponenten
Ein Milvus-Cluster besteht aus fünf Kernkomponenten und drei Drittanbieter-Abhängigkeiten. Jede Komponente kann unabhängig auf Kubernetes bereitgestellt werden:
Milvus-Komponenten
- Coordinator: Der Master-Slave-Modus kann aktiviert werden, um hohe Verfügbarkeit zu gewährleisten.
- Proxy: einer oder mehrere pro Cluster
- Streaming Node: ein oder mehrere pro Cluster
- Abfrageknoten: ein oder mehrere pro Cluster
- Datenknoten: ein oder mehrere pro Cluster
Abhängigkeiten von Drittanbietern
- Meta-Speicher: Speichert Metadaten für verschiedene Komponenten im milvus, z. B. etcd.
- Objektspeicher: Verantwortlich für die Datenpersistenz großer Dateien im milvus, wie Index- und binäre Protokolldateien, z. B. S3
- WAL-Speicher: Bietet einen Write-Ahead Log (WAL) Service für die milvus, z.B. woodpecker.
- Im Woodpecker-Zero-Disk-Modus verwendet WAL direkt Objektspeicher und Metaspeicher ohne weitere Bereitstellung, wodurch Abhängigkeiten von Dritten reduziert werden.
Milvus-Einsatzmodi
Es gibt zwei Modi für den Betrieb von Milvus:
Eigenständig
Eine einzelne Instanz von Milvus, in der alle Komponenten in einem Prozess ausgeführt werden, was sich für kleine Datenmengen und eine geringe Arbeitslast eignet. Darüber hinaus können im Standalone-Modus einfachere WAL-Implementierungen wie Woodpecker und Rocksmq gewählt werden, um die Abhängigkeit von WAL-Speichern Dritter zu eliminieren.
Eigenständige_Architektur
Derzeit ist es nicht möglich, ein Online-Upgrade von einer eigenständigen Milvus-Instanz auf einen Milvus-Cluster durchzuführen, selbst wenn das WAL-Speicher-Backend den Cluster-Modus unterstützt.
Cluster
Ein verteilter Bereitstellungsmodus von Milvus, bei dem jede Komponente unabhängig läuft und aus Gründen der Elastizität skaliert werden kann. Diese Konfiguration eignet sich für große Datensätze und Szenarien mit hoher Last.
Verteilte_Architektur
Was kommt als Nächstes?
- Lesen Sie Computing/Storage Disaggregation, um den Mechanismus und das Designprinzip von Milvus zu verstehen.
