Best Practices für Tiered StorageCompatible with Milvus 2.6.4+

Milvus bietet Tiered Storage, um Sie bei der effizienten Verarbeitung großer Datenmengen zu unterstützen und gleichzeitig Abfragelatenz, Kapazität und Ressourcennutzung auszugleichen. Dieser Leitfaden fasst die empfohlenen Konfigurationen für typische Arbeitslasten zusammen und erläutert die Gründe für jede Tuning-Strategie.

Bevor Sie beginnen

• Milvus v2.6.4 oder höher

• QueryNodes müssen über dedizierte lokale Ressourcen (Speicher und Festplatte) verfügen. Gemeinsam genutzte Umgebungen können die Cache-Schätzung verzerren und zu Fehleinschätzungen bei der Auslagerung führen.

Wählen Sie die richtige Strategie

Tiered Storage bietet flexible Lade- und Caching-Strategien, die je nach Arbeitslast kombiniert werden können.

Ziel	Empfohlener Schwerpunkt	Schlüsselmechanismus
Minimierung der Latenzzeit bei der ersten Abfrage	Vorladen kritischer Felder	Aufwärmen
Effizienter Umgang mit großen Datenmengen	Laden nach Bedarf	Lazy Load + Partial Load
Aufrechterhaltung der langfristigen Stabilität	Verhinderung von Cache-Überlauf	Auslagerung
Gleichgewicht zwischen Leistung und Kapazität	Kombinieren Sie Preload und dynamisches Caching	Hybride Konfiguration

Szenario 1: Abruf in Echtzeit mit geringer Latenzzeit

Wann sollte man sie verwenden?

• Abfragelatenz ist kritisch (z. B. Echtzeit-Empfehlung oder Such-Ranking)

• Auf zentrale Vektorindizes und skalare Filter wird häufig zugegriffen

• Konsistente Leistung ist wichtiger als Startgeschwindigkeit

Empfohlene Konfiguration

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      warmup:
        # scalar field/index warm-up to eliminate first-time latency
        scalarField: sync
        scalarIndex: sync
        # warm-up of vector fields is disabled (if the original vector is not required)
        vectorField: disable
        # vector indexes warm-up to elminate first-time latenct
        vectorIndex: sync
      # enable cache eviction, and also turn on background asynchronous eviction
      # to reduce the triggering of synchronous eviction.
      evictionEnabled: true
      backgroundEvictionEnabled: true
      memoryLowWatermarkRatio: 0.75
      memoryHighWatermarkRatio: 0.8
      diskLowWatermarkRatio: 0.75
      diskHighWatermarkRatio: 0.8
      # no expiration time, which avoids frequent reloading
      cacheTtl: 0

Begründung

• Warmup eliminiert die First-Hit-Latenz für hochfrequente Skalar- und Vektorindizes.

• Die Verdrängung im Hintergrund hält den Cache-Druck stabil, ohne Abfragen zu blockieren.

• Durch die Deaktivierung der Cache-TTL werden unnötige Neuladungen für heiße Daten vermieden.

Szenario 2: Offline, Batch-Analyse

Wann sollte man sie verwenden?

• Die Toleranz für Abfragelatenz ist hoch

• Die Arbeitslast umfasst große Datensätze oder viele Segmente

• Kapazität und Durchsatz haben Vorrang vor der Reaktionsfähigkeit

Empfohlene Konfiguration

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      enabled: true
      warmup:
        # disable scalar field/index warm-up to speed up loading
        scalarField: disable
        scalarIndex: disable
        # disable vector field/index warm-up to speed up loading
        vectorField: disable
        vectorIndex: disable
      # enable cache eviction, and also turn on background asynchronous eviction
      # to reduce the triggering of synchronous eviction.
      evictionEnabled: true
      backgroundEvictionEnabled: true
      memoryLowWatermarkRatio: 0.7
      memoryHighWatermarkRatio: 0.85
      diskLowWatermarkRatio: 0.7
      diskHighWatermarkRatio: 0.85
      # use 1 day expiration to clean unused cache
      cacheTtl: 86400

Begründung

• Die Deaktivierung der Aufwärmphase beschleunigt den Startvorgang bei der Initialisierung vieler Segmente.

• Höhere Wasserzeichen ermöglichen eine dichtere Cache-Nutzung und verbessern die Gesamtlastkapazität.

• Die Cache-TTL bereinigt automatisch ungenutzte Daten, um lokalen Speicherplatz freizugeben.

Szenario 3: Hybride Bereitstellung (gemischt online + offline)

Wann verwenden

• Ein einziger Cluster bedient sowohl Online- als auch analytische Workloads

• Einige Sammlungen erfordern niedrige Latenzzeiten, bei anderen steht die Kapazität im Vordergrund

Empfohlene Strategie

• Anwendung der Echtzeitkonfiguration auf latenzempfindliche Sammlungen

• Anwendung der Offline-Konfiguration auf analytische oder archivierte Sammlungen

• Passen Sie evictableMemoryCacheRatio, cacheTtl und Watermark-Ratios unabhängig für jeden Workload-Typ an

Begründung

Die Kombination von Konfigurationen ermöglicht eine feinkörnige Steuerung der Ressourcenzuweisung.

Kritische Sammlungen behalten Garantien für niedrige Latenzzeiten bei, während sekundäre Sammlungen mehr Segmente und Datenvolumen verarbeiten können.

Zusätzliche Tuning-Tipps

Aspekt	Empfehlung	Erläuterung
Warm Up-Bereich	Laden Sie nur Felder oder Indizes mit hoher Abfragehäufigkeit vor.	Unnötiges Vorladen erhöht die Ladezeit und den Ressourcenverbrauch.
Optimierung der Verdrängung	Beginnen Sie mit den Standard-Wasserzeichen (75-80%) und passen Sie sie schrittweise an.	Eine kleine Lücke führt zu häufigen Auslagerungen; eine große Lücke verzögert die Freigabe von Ressourcen.
Cache-TTL	Deaktivieren Sie diese Option für stabile Hot-Datensätze; aktivieren Sie sie (z. B. 1-3 Tage) für dynamische Daten.	Verhindert den Aufbau eines veralteten Caches und gleicht gleichzeitig den Bereinigungs-Overhead aus.
Overcommit-Verhältnis	Vermeiden Sie Werte > 0,7, es sei denn, Sie haben einen großen Spielraum bei den Ressourcen.	Übermäßiges Overcommit kann zu Cache-Thrashing und instabiler Latenz führen.
Überwachung	Überwachen Sie die Cache-Trefferrate, die Ressourcennutzung und die Häufigkeit der Auslagerungen.	Häufige Cold Loads können darauf hinweisen, dass die Aufwärmzeit oder die Wasserzeichen angepasst werden müssen.