Home
Blog
Wie man sicher von Milvus 2.5.x auf Milvus 2.6.x aktualisiert

Wie man sicher von Milvus 2.5.x auf Milvus 2.6.x aktualisiert

Tutorials

December 25, 2025

Yiqing Lu

Milvus 2.6 ist seit einiger Zeit live und erweist sich als ein solider Schritt nach vorne für das Projekt. Die Version bringt eine verfeinerte Architektur, eine bessere Echtzeitleistung, einen geringeren Ressourcenverbrauch und ein intelligenteres Skalierungsverhalten in Produktionsumgebungen. Viele dieser Verbesserungen wurden direkt durch das Feedback der Benutzer beeinflusst, und frühe Anwender von 2.6.x haben bereits von einer spürbar schnelleren Suche und einer besser vorhersehbaren Systemleistung bei hoher oder dynamischer Arbeitslast berichtet.

Für Teams, die Milvus 2.5.x einsetzen und einen Umstieg auf 2.6.x in Erwägung ziehen, ist dieser Leitfaden ein guter Startpunkt. Er schlüsselt die architektonischen Unterschiede auf, hebt die in Milvus 2.6 eingeführten Schlüsselfunktionen hervor und bietet einen praktischen, schrittweisen Upgrade-Pfad, der darauf ausgelegt ist, die Betriebsunterbrechung zu minimieren.

Wenn Ihre Arbeitslasten Echtzeit-Pipelines, multimodale oder hybride Suchvorgänge oder groß angelegte Vektoroperationen umfassen, hilft Ihnen dieser Blog bei der Einschätzung, ob 2.6 Ihren Anforderungen entspricht, und wenn Sie sich für ein Upgrade entscheiden, können Sie dieses mit Zuversicht durchführen, während die Datenintegrität und Serviceverfügbarkeit erhalten bleibt.

Architekturänderungen von Milvus 2.5 zu Milvus 2.6

Bevor wir uns mit dem eigentlichen Upgrade-Workflow befassen, sollten wir zunächst verstehen, wie sich die Milvus-Architektur in Milvus 2.6 ändert.

Milvus 2.5 Architektur

Milvus 2.5 Architecture Milvus 2.5 Architektur

In Milvus 2.5 waren Streaming- und Batch-Workflows über mehrere Worker Nodes hinweg miteinander verflochten:

QueryNode bearbeitete sowohl historische Abfragen als auch inkrementelle (Streaming) Abfragen.
DataNode wickelte sowohl das Ingest-Time-Flushing als auch die Hintergrundverdichtung von historischen Daten ab.

Diese Vermischung von Batch- und Echtzeitlogik erschwerte die unabhängige Skalierung von Batch-Workloads. Außerdem war der Streaming-Status über mehrere Komponenten verstreut, was zu Synchronisationsverzögerungen führte, die Wiederherstellung nach einem Ausfall erschwerte und die Komplexität des Betriebs erhöhte.

Milvus 2.6 Architektur

Milvus 2.6 Architecture Die Architektur von Milvus 2.6

Milvus 2.6 führt einen dedizierten StreamingNode ein, der für alle Echtzeitdaten zuständig ist: Konsumieren der Nachrichtenwarteschlange, Schreiben inkrementeller Segmente, Bedienen inkrementeller Abfragen und Verwalten der WAL-basierten Wiederherstellung. Durch die Isolierung des Streaming übernehmen die übrigen Komponenten klarere, gezieltere Rollen:

QueryNode verarbeitet jetzt nur noch Batch-Abfragen auf historischen Segmenten.
DataNode übernimmt nur noch Aufgaben für historische Daten wie Verdichtung und Indexaufbau.

Der StreamingNode übernimmt alle Streaming-bezogenen Aufgaben, die in Milvus 2.5 zwischen DataNode, QueryNode und sogar dem Proxy aufgeteilt waren, und sorgt so für mehr Klarheit und eine Reduzierung der rollenübergreifenden Zustandsaufteilung.

Milvus 2.5.x gegenüber Milvus 2.6.x: Vergleich der einzelnen Komponenten

	Milvus 2.5.x	Milvus 2.6.x	Was hat sich geändert?
Koordinator-Dienste	RootCoord / QueryCoord / DataCoord (oder MixCoord)	MixCoord	Metadatenmanagement und Aufgabenplanung sind in einem einzigen MixCoord zusammengefasst, was die Koordinationslogik vereinfacht und die verteilte Komplexität reduziert.
Zugriffsschicht	Proxy	Proxy	Schreibanfragen werden nur über den Streaming Node zur Datenaufnahme geleitet.
Worker-Knoten	-	Streaming-Knoten	Dedizierter Streaming-Verarbeitungsknoten, der für die gesamte inkrementelle (wachsende Segmente) Logik zuständig ist, einschließlich:- Inkrementelle Datenaufnahme- Inkrementelle Datenabfrage- Persistieren inkrementeller Daten im Objektspeicher- Stream-basierte Schreibvorgänge- Fehlerbehebung auf der Grundlage von WAL
	Abfrageknoten	Abfrageknoten	Stapelverarbeitungsknoten, der nur Abfragen über historische Daten verarbeitet.
	Datenknoten	Datenknoten	Stapelverarbeitungsknoten, der nur für historische Daten zuständig ist, einschließlich Verdichtung und Indexaufbau.
	Index-Knoten	-	Der Indexknoten wird mit dem Datenknoten verschmolzen, wodurch die Rollendefinitionen und die Bereitstellungstopologie vereinfacht werden.

Kurz gesagt, Milvus 2.6 zieht eine klare Linie zwischen Streaming- und Batch-Workloads, beseitigt die komponentenübergreifende Verflechtung, die in 2.5 zu sehen war, und schafft eine skalierbarere, wartbare Architektur.

Milvus 2.6 Funktions-Highlights

Bevor wir uns mit dem Upgrade-Workflow befassen, werfen wir einen kurzen Blick auf die Neuerungen von Milvus 2.6. Diese Version konzentriert sich auf die Senkung der Infrastrukturkosten, die Verbesserung der Suchleistung und die einfachere Skalierung großer, dynamischer KI-Workloads.

Kosten- und Effizienzverbesserungen

RaBitQ-Quantisierung für Primärindizes - Eine neue 1-Bit-Quantisierungsmethode, die Vektorindizes auf 1/32 ihrer ursprünglichen Größe komprimiert. In Kombination mit dem SQ8-Reranking wird die Speichernutzung auf ~28 % reduziert, die QPS um das Vierfache erhöht und eine Wiederauffindbarkeit von ~95 % beibehalten, wodurch die Hardwarekosten erheblich gesenkt werden.
BM25-optimierte Volltextsuche - Native BM25-Bewertung mit spärlichen Term-Gewichts-Vektoren. Die Stichwortsuche läuft im Vergleich zu Elasticsearch 3-4x schneller (bei einigen Datensätzen bis zu 7x ), während die Indexgröße auf etwa ein Drittel der ursprünglichen Textdaten beschränkt bleibt.
JSON Path Indexing mit JSON Shredding - Strukturiertes Filtern von verschachteltem JSON ist jetzt deutlich schneller und viel vorhersehbarer. Vorindizierte JSON-Pfade verkürzen die Filterlatenz von 140 ms → 1,5 ms (P99: 480 ms → 10 ms) und machen die hybride Vektorsuche + Metadatenfilterung deutlich reaktionsschneller.
Erweiterte Datentypunterstützung - Hinzufügen von Int8-Vektortypen, Geometriefeldern (POINT / LINESTRING / POLYGON) und Array-of-Structs. Diese Erweiterungen unterstützen Geodaten-Workloads, umfassendere Metadatenmodellierung und sauberere Schemata.
Upsert für partielle Aktualisierungen - Sie können jetzt Entitäten mit einem einzigen Primärschlüsselaufruf einfügen oder aktualisieren. Bei partiellen Aktualisierungen werden nur die bereitgestellten Felder geändert, wodurch der Schreibaufwand reduziert und Pipelines vereinfacht werden, die häufig Metadaten oder Einbettungen aktualisieren.

Verbesserungen bei Suche und Retrieval

Verbesserte Textverarbeitung und mehrsprachige Unterstützung: Neue Lindera- und ICU-Tokenizer verbessern die Verarbeitung von japanischem, koreanischem und mehrsprachigem Text. Jieba unterstützt jetzt benutzerdefinierte Wörterbücher. run_analyzer hilft beim Debuggen des Tokenisierungsverhaltens, und mehrsprachige Analysatoren gewährleisten eine konsistente sprachenübergreifende Suche.
Hochpräzises Text Matching: Phrase Match erzwingt geordnete Phrasenabfragen mit konfigurierbarem Slop. Der neue NGRAM-Index beschleunigt Teilstring- und LIKE -Abfragen sowohl für VARCHAR-Felder als auch für JSON-Pfade und ermöglicht schnelle Teiltext- und Fuzzy-Abgleiche.
Zeit- und Metadaten-bewusstes Reranking: Decay Rankers (exponentiell, linear, Gauß) passen die Punktzahlen anhand von Zeitstempeln an; Boost Rankers wenden metadatengesteuerte Regeln an, um Ergebnisse auf- oder abzuwerten. Beide helfen bei der Feinabstimmung des Abrufverhaltens, ohne die zugrunde liegenden Daten zu verändern.
Vereinfachte Modellintegration und Auto-Vektorisierung: Integrierte Integrationen mit OpenAI, Hugging Face und anderen Einbettungsanbietern ermöglichen Milvus die automatische Vektorisierung von Text bei Einfüge- und Abfragevorgängen. Keine manuellen Einbettungspipelines mehr für gängige Anwendungsfälle.
Online-Schema-Updates für skalare Felder: Fügen Sie neue skalare Felder zu bestehenden Sammlungen hinzu, ohne Ausfallzeiten oder Neuladen, und vereinfachen Sie so die Schemaentwicklung bei wachsenden Metadatenanforderungen.
Fast-Duplikat-Erkennung mit MinHash: MinHash + LSH ermöglicht eine effiziente Erkennung von Beinahe-Duplikaten in großen Datenbeständen ohne teure exakte Vergleiche.

Architektur- und Skalierbarkeits-Upgrades

Tiered Storage für Hot-Cold Data Management: Trennt heiße und kalte Daten über SSD- und Objektspeicher hinweg; unterstützt träges und teilweises Laden; eliminiert die Notwendigkeit, Sammlungen vollständig lokal zu laden; reduziert die Ressourcennutzung um bis zu 50 % und beschleunigt die Ladezeiten für große Datensätze.
Echtzeit-Streaming-Dienst: Fügt dedizierte Streaming-Knoten hinzu, die mit Kafka/Pulsar für kontinuierliche Ingestion integriert sind; ermöglicht sofortige Indizierung und Abfrageverfügbarkeit; verbessert den Schreibdurchsatz und beschleunigt die Fehlerbehebung für schnell wechselnde Echtzeit-Workloads.
Verbesserte Skalierbarkeit und Stabilität: Milvus unterstützt jetzt mehr als 100.000 Sammlungen für große mandantenfähige Umgebungen. Infrastruktur-Upgrades - Woodpecker (Zero-Disk WAL), Storage v2 (reduzierte IOPS/Speicher) und der Coordinator Merge - verbessern die Stabilität des Clusters und ermöglichen eine vorhersehbare Skalierung bei hohen Arbeitslasten.

Eine vollständige Liste der Funktionen von Milvus 2.6 finden Sie in den Milvus-Versionshinweisen.

Wie man von Milvus 2.5.x auf Milvus 2.6.x umsteigt

Um das System während des Upgrades so verfügbar wie möglich zu halten, sollten Milvus 2.5-Cluster in der folgenden Reihenfolge auf Milvus 2.6 upgegradet werden.

1. Starten Sie zuerst den Streaming Node

Starten Sie den Streaming Node im Voraus. Der neue Delegator (die Komponente im Query Node, die für die Verarbeitung von Streaming-Daten zuständig ist) muss zum Milvus 2.6 Streaming Node verschoben werden.

2. MixCoord aktualisieren

Aktualisieren Sie die Koordinator-Komponenten auf MixCoord. Während dieses Schritts muss MixCoord die Versionen der Worker Nodes erkennen, um die Kompatibilität der verschiedenen Versionen innerhalb des verteilten Systems zu gewährleisten.

3. Upgrade des Abfrageknotens

Upgrades von Query Nodes dauern normalerweise länger. Während dieser Phase können Milvus 2.5 Data Nodes und Index Nodes weiterhin Operationen wie Flush und Indexaufbau durchführen und so den Druck auf der Abfrageseite reduzieren, während die Query Nodes aufgerüstet werden.

4. Upgrade des Datenknotens

Sobald Milvus 2.5 DataNodes offline genommen werden, sind Flush-Operationen nicht mehr verfügbar, und Daten in Growing Segments können sich weiterhin ansammeln, bis alle Nodes vollständig auf Milvus 2.6 aktualisiert sind.

5. Upgrade des Proxys

Nach dem Upgrade eines Proxys auf Milvus 2.6 sind Schreiboperationen auf diesem Proxy so lange nicht verfügbar, bis alle Clusterkomponenten auf 2.6 aktualisiert sind.

6. Entfernen Sie den Index-Knoten

Sobald alle anderen Komponenten aufgerüstet sind, kann der eigenständige Index-Knoten sicher entfernt werden.

Hinweise:

Ab dem Abschluss des DataNode-Upgrades bis zum Abschluss des Proxy-Upgrades sind Flush-Vorgänge nicht mehr verfügbar.
Ab dem Zeitpunkt des Upgrades des ersten Proxys bis zum Abschluss des Upgrades aller Proxy-Knoten sind einige Schreiboperationen nicht verfügbar.
Bei einem direkten Upgrade von Milvus 2.5.x auf 2.6.6 sind DDL-Operationen (Data Definition Language) während des Upgrade-Prozesses aufgrund von Änderungen im DDL-Framework nicht verfügbar.

Upgrade auf Milvus 2.6 mit Milvus Operator

Milvus Operator ist ein Open-Source-Kubernetes-Operator, der eine skalierbare, hochverfügbare Möglichkeit zur Bereitstellung, Verwaltung und Aktualisierung des gesamten Milvus-Service-Stacks auf einem Kubernetes-Zielcluster bietet. Der vom Operator verwaltete Milvus-Service-Stack umfasst:

Kernkomponenten von Milvus
Erforderliche Abhängigkeiten wie etcd, Pulsar und MinIO

Milvus Operator folgt dem Standardmuster von Kubernetes Operator. Er führt eine benutzerdefinierte Milvus-Ressource (CR) ein, die den gewünschten Zustand eines Milvus-Clusters beschreibt, z. B. seine Version, Topologie und Konfiguration.

Ein Controller überwacht den Cluster kontinuierlich und gleicht den Ist-Zustand mit dem in der CR definierten Soll-Zustand ab. Wenn Änderungen vorgenommen werden, z. B. ein Upgrade der Milvus-Version, wendet der Operator diese automatisch auf kontrollierte und wiederholbare Weise an und ermöglicht so automatisierte Upgrades und ein fortlaufendes Lifecycle-Management.

Beispiel für eine benutzerdefinierte Ressource (CR) von Milvus

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-milvus-mansion    
  namespace: dev       
spec:
  mode: cluster                  # cluster or standalone
  # Milvus Components
  components:
    image: milvusdb/milvus:v2.6.5
    imageUpdateMode: rollingUpgrade 
    proxy:                   
      replicas: 1          
    mixCoord:              
      replicas: 1           
    dataNode:               
      replicas: 1          
    queryNode:              
      replicas: 2           
      resources:
        requests:
          cpu: "2"
          memory: "8Gi"  
  # Dependencies, including etcd, storage and message stream
  dependencies:
    etcd:                   
      inCluster:
        values:
          replicaCount: 3    
    storage:                 
      type: MinIO
      inCluster:
        values:
          mode: distributed     
    msgStreamType: pulsar    
    pulsar:
      inCluster:
        values:
          bookkeeper:
            replicas: 3   
  # Milvus configs
  config:
    dataCoord:
      enableActiveStandby: true

Rolling Upgrades von Milvus 2.5 auf 2.6 mit Milvus Operator

Milvus Operator bietet integrierte Unterstützung für Rolling Upgrades von Milvus 2.5 auf 2.6 im Clustermodus und passt sein Verhalten an die in 2.6 eingeführten architektonischen Änderungen an.

1. Erkennung von Upgrade-Szenarien

Während eines Upgrades bestimmt Milvus Operator die Zielversion von Milvus anhand der Clusterspezifikation. Dies geschieht entweder durch:

Untersuchung des in spec.components.image definierten Image-Tags, oder
Lesen der expliziten Version, die in spec.components.version

Der Operator vergleicht dann diese gewünschte Version mit der aktuell laufenden Version, die in status.currentImage oder status.currentVersion aufgezeichnet ist. Wenn die aktuelle Version 2.5 und die gewünschte Version 2.6 ist, identifiziert der Operator das Upgrade als ein 2.5 → 2.6 Upgrade-Szenario.

2. Rolling Upgrade-Ausführungsreihenfolge

Wenn ein 2.5 → 2.6-Upgrade erkannt wird und der Upgrade-Modus auf "Rolling Upgrade" eingestellt ist (spec.components.imageUpdateMode: rollingUpgrade, was die Standardeinstellung ist), führt Milvus Operator das Upgrade automatisch in einer vordefinierten Reihenfolge durch, die auf die Milvus 2.6-Architektur abgestimmt ist:

Start des Streaming-Knotens → Upgrade von MixCoord → Upgrade des Abfrageknotens → Upgrade des Datenknotens → Upgrade des Proxys → Entfernen des Indexknotens

3. Automatische Koordinatorenkonsolidierung

Milvus 2.6 ersetzt mehrere Coordinator-Komponenten durch einen einzigen MixCoord. Milvus Operator verarbeitet diesen Architekturwechsel automatisch.

Wenn spec.components.mixCoord konfiguriert ist, ruft der Operator MixCoord auf und wartet, bis dieser bereit ist. Sobald MixCoord voll funktionsfähig ist, schaltet der Operator die alten Koordinator-Komponenten - RootCoord, QueryCoord und DataCoord - ab und schließt so die Migration ab, ohne dass ein manuelles Eingreifen erforderlich ist.

Upgrade-Schritte von Milvus 2.5 auf 2.6

1. aktualisieren Sie Milvus Operator auf die neueste Version (in diesem Handbuch verwenden wir Version 1.3.3, die zum Zeitpunkt der Erstellung dieses Handbuchs die neueste Version war)

# Option 1: Using Helm
helm upgrade --install milvus-operator \
  -n milvus-operator --create-namespace \
  https://github.com/zilliztech/milvus-operator/releases/download/v1.3.3/milvus-operator-1.3.3.tgz
 # Option 2: Using kubectl & raw manifests
 kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/v1.3.3/deploy/manifests/deployment.yaml

2.führen Sie die Koordinator-Komponenten zusammen

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "mixCoord": {
        "replicas": 1
      }
    }
  }
}'

3. sicherstellen, dass auf dem Cluster Milvus 2.5.16 oder höher läuft

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.5.22"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

4. aktualisieren Sie Milvus auf Version 2.6

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.6.5"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

Upgrade auf Milvus 2.6 mit Helm

Bei der Bereitstellung von Milvus mit Helm werden alle Kubernetes-Ressourcen Deployment parallel aktualisiert, ohne garantierte Ausführungsreihenfolge. Infolgedessen bietet Helm keine strenge Kontrolle über rollierende Upgrade-Sequenzen zwischen den Komponenten. Für Produktionsumgebungen wird daher die Verwendung von Milvus Operator dringend empfohlen.

Milvus kann dennoch mit Helm von 2.5 auf 2.6 aktualisiert werden, indem Sie die folgenden Schritte ausführen.

Systemanforderungen

Helm-Version: ≥ 3.14.0
Kubernetes-Version: ≥ 1.20.0

1. Aktualisieren Sie die Milvus Helm-Karte auf die neueste Version. In dieser Anleitung verwenden wir die Chart-Version 5.0.7, die zum Zeitpunkt der Erstellung dieses Handbuchs die neueste war.

helm repo add zilliztech https://zilliztech.github.io/milvus-helm
helm repo update

Wenn der Cluster mit mehreren Coordinator-Komponenten eingesetzt wird, aktualisieren Sie zunächst Milvus auf Version 2.5.16 oder höher und aktivieren Sie MixCoord.

mixCoordinator
。
helm upgrade -i my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.5.22" \
  --set mixCoordinator.enabled=true \
  --set rootCoordinator.enabled=false \
  --set indexCoordinator.enabled=false \
  --set queryCoordinator.enabled=false \
  --set dataCoordinator.enabled=false \
  --set streaming.enabled=false \
  --set indexNode.enabled=true \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

3. aktualisieren Sie Milvus auf Version 2.6

helm upgrade my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.6.5" \
  --set streaming.enabled=true \
  --set indexNode.enabled=false \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

FAQ zu Milvus 2.6 Upgrade und Betrieb

Q1: Milvus Helm vs. Milvus Operator - welches sollte ich verwenden?

Für Produktionsumgebungen wird Milvus Operator dringend empfohlen.

Einzelheiten finden Sie in der offiziellen Anleitung: https://github.com/zilliztech/milvus-operator?tab=readme-ov-file#milvus-operator-vs-helm

Q2: Wie sollte ich eine Message Queue (MQ) auswählen?

Die empfohlene MQ hängt vom Einsatzmodus und den betrieblichen Anforderungen ab:

1. Eigenständiger Modus: Für kostenbewusste Implementierungen wird RocksMQ empfohlen.

2. Cluster-Modus

Pulsar unterstützt Multi-Tenancy, ermöglicht großen Clustern die gemeinsame Nutzung der Infrastruktur und bietet eine hohe horizontale Skalierbarkeit.
Kafka hat ein ausgereifteres Ökosystem mit verwalteten SaaS-Angeboten, die auf den meisten großen Cloud-Plattformen verfügbar sind.

3. Woodpecker (eingeführt in Milvus 2.6): Woodpecker macht eine externe Nachrichten-Warteschlange überflüssig und reduziert so Kosten und betriebliche Komplexität.

Derzeit wird nur der eingebettete Woodpecker-Modus unterstützt, der leichtgewichtig und einfach zu bedienen ist.
Für Milvus 2.6 Standalone-Einsätze wird Woodpecker empfohlen.
Für produktive Cluster-Einsätze wird empfohlen, den kommenden Woodpecker-Cluster-Modus zu verwenden, sobald er verfügbar ist.

F3: Kann die Message Queue während eines Upgrades gewechselt werden?

Nein. Das Umschalten der Nachrichtenwarteschlange während eines Upgrades wird derzeit nicht unterstützt. Künftige Versionen werden Verwaltungs-APIs einführen, die das Umschalten zwischen Pulsar, Kafka, Woodpecker und RocksMQ unterstützen.

F4: Müssen Konfigurationen zur Ratenbegrenzung für Milvus 2.6 aktualisiert werden?

Nein. Bestehende Konfigurationen zur Ratenbegrenzung bleiben wirksam und gelten auch für den neuen Streaming Node. Es sind keine Änderungen erforderlich.

F5: Ändern sich nach der Zusammenführung der Koordinatoren Überwachungsrollen oder -konfigurationen?

Die Überwachungsrollen bleiben unverändert (RootCoord, QueryCoord, DataCoord).
Bestehende Konfigurationsoptionen funktionieren weiterhin wie bisher.
Es wird eine neue Konfigurationsoption, mixCoord.enableActiveStandby, eingeführt, die auf rootcoord.enableActiveStandby zurückfällt, wenn sie nicht explizit gesetzt wird.

F6: Was sind die empfohlenen Ressourceneinstellungen für StreamingNode?

Für leichte Echtzeit-Ingestion oder gelegentliche Schreib- und Abfrage-Arbeitslasten ist eine kleinere Konfiguration, z. B. 2 CPU-Kerne und 8 GB Speicher, ausreichend.
Für schwere Echtzeit-Ingestion oder kontinuierliche Schreib- und Abfrage-Arbeitslasten wird empfohlen, Ressourcen zuzuweisen, die mit denen des Abfrageknotens vergleichbar sind.

F7: Wie kann ich eine eigenständige Bereitstellung mit Docker Compose aktualisieren?

Für Docker Compose-basierte Standalone-Bereitstellungen aktualisieren Sie einfach das Milvus-Image-Tag in docker-compose.yaml.

Weitere Informationen finden Sie in der offiziellen Anleitung: https://milvus.io/docs/upgrade_milvus_standalone-docker.md

Schlussfolgerung

Milvus 2.6 stellt eine wesentliche Verbesserung sowohl in der Architektur als auch im Betrieb dar. Durch die Trennung von Streaming- und Batch-Verarbeitung mit der Einführung von StreamingNode, die Konsolidierung von Koordinatoren in MixCoord und die Vereinfachung von Worker-Rollen bietet Milvus 2.6 eine stabilere, skalierbarere und einfacher zu bedienende Grundlage für große Vektor-Workloads.

Durch diese architektonischen Änderungen sind Upgrades - insbesondere von Milvus 2.5 - stärker von der Reihenfolge abhängig. Ein erfolgreiches Upgrade hängt von der Einhaltung von Komponentenabhängigkeiten und temporären Verfügbarkeitsbeschränkungen ab. Für Produktionsumgebungen ist Milvus Operator der empfohlene Ansatz, da er die Upgrade-Reihenfolge automatisiert und das Betriebsrisiko reduziert, während Helm-basierte Upgrades besser für nicht-produktive Anwendungsfälle geeignet sind.

Mit erweiterten Suchfunktionen, reichhaltigeren Datentypen, abgestuftem Speicher und verbesserten Optionen für Nachrichtenwarteschlangen ist Milvus 2.6 gut positioniert, um moderne KI-Anwendungen zu unterstützen, die Echtzeit-Ingestion, hohe Abfrageleistung und effiziente Abläufe im großen Maßstab erfordern.

Haben Sie Fragen oder wünschen Sie einen tieferen Einblick in eine Funktion des neuesten Milvus? Treten Sie unserem Discord-Kanal bei oder stellen Sie Fragen auf GitHub. Sie können auch eine 20-minütige persönliche Sitzung buchen, um Einblicke, Anleitung und Antworten auf Ihre Fragen über die Milvus Office Hours zu erhalten.