Tiered Storage ÜberblickCompatible with Milvus 2.6.4+

In Milvus erfordert der traditionelle Full-Load-Modus, dass jeder QueryNode alle Datenfelder und Indizes eines Segments bei der Initialisierung lädt, selbst Daten, auf die möglicherweise nie zugegriffen wird. Dies gewährleistet die sofortige Datenverfügbarkeit, führt jedoch häufig zu einer Verschwendung von Ressourcen, einschließlich hoher Speicherauslastung, starker Festplattenaktivität und erheblichem E/A-Overhead, insbesondere bei der Verarbeitung großer Datensätze.

Tiered Storage löst dieses Problem durch die Entkopplung des Daten-Cachings vom Laden der Segmente. Anstatt alle Daten auf einmal zu laden, lädt der QueryNode jetzt zunächst nur leichtgewichtige Metadaten und ruft bei Bedarf dynamisch Felddaten ab oder entfernt sie. Dadurch wird die Ladezeit erheblich verkürzt, die lokale Ressourcennutzung optimiert und QueryNodes in die Lage versetzt, Datensätze zu verarbeiten, die ihre physische Speicher- oder Festplattenkapazität bei weitem übersteigen.

Erwägen Sie die Aktivierung von Tiered Storage in Szenarien wie:

• Sammlungen, die die verfügbare Speicher- oder NVMe-Kapazität eines einzelnen QueryNodes übersteigen

• Analytische oder Batch-Workloads, bei denen ein schnelleres Laden wichtiger ist als die Latenzzeit bei der ersten Abfrage

• Gemischte Arbeitslasten, die gelegentliche Cache-Misses für weniger häufig abgerufene Daten tolerieren können

Wie funktioniert es?

Tiered Storage ändert, wie QueryNode Segmentdaten verwaltet. Anstatt jedes Feld und jeden Index zum Zeitpunkt des Ladens zwischenzuspeichern, lädt QueryNode jetzt nur noch Metadaten und verwendet eine Zwischenspeicherschicht, um Daten dynamisch abzurufen und zu verdrängen.

Volllastmodus vs. Tiered Storage-Modus

Die beiden Modi "Volllast" und "Tiered Storage" verarbeiten zwar dieselben Daten, unterscheiden sich aber darin, wann und wie QueryNode diese Komponenten zwischenspeichert.

• Volllast-Modus: Zum Zeitpunkt des Ladens speichert QueryNode die vollständigen Sammlungsdaten, einschließlich Metadaten, Felddaten und Indizes, aus dem Objektspeicher.

• Tiered Storage-Modus: Zum Zeitpunkt des Ladens speichert QueryNode nur Metadaten im Cache. Felddaten werden bei Bedarf mit Chunk-Granularität abgerufen. Indexdateien bleiben entfernt, bis die erste Abfrage sie benötigt; dann wird der gesamte Index pro Segment abgerufen und zwischengespeichert.

Das folgende Diagramm zeigt diese Unterschiede.

Volllastmodus vs. Tiered Storage Modus

Arbeitsablauf beim Laden von QueryNode

Unter Tiered Storage hat der Workflow von Tiered Storage diese Phasen:

QueryNode-Lade-Workflow

Phase 1: Lazy Load

Bei der Initialisierung führt Milvus ein "Lazy Load" durch, wobei nur Metadaten auf Segmentebene wie Schemadefinitionen, Indexinformationen und Chunk-Mappings zwischengespeichert werden.

In diesem Stadium werden keine tatsächlichen Felddaten oder Indexdateien zwischengespeichert. Dadurch können Sammlungen fast sofort nach dem Start abgefragt werden, während der Speicher- und Festplattenverbrauch minimal bleibt.

Da die Felddaten und Indexdateien bis zum ersten Zugriff im entfernten Speicher verbleiben, kann es bei der ersten Abfrage zu einer zusätzlichen Latenzzeit kommen, da die erforderlichen Daten bei Bedarf abgerufen werden müssen. Um diesen Effekt für kritische Felder oder Indizes abzuschwächen, können Sie die Warm Up-Strategie verwenden, um sie proaktiv vorzuladen, bevor das Segment abfragbar wird.

Konfiguration

Wird automatisch angewendet, wenn Tiered Storage aktiviert ist. Eine manuelle Einstellung ist nicht erforderlich.

Phase 2: Aufwärmen

Um die durch Lazy Load verursachte First-Hit-Latenz zu reduzieren, bietet Milvus einen Warm Up-Mechanismus.

Bevor ein Segment abfragbar wird, kann Milvus proaktiv bestimmte Felder oder Indizes aus dem Objektspeicher abrufen und zwischenspeichern, um sicherzustellen, dass die erste Abfrage direkt auf zwischengespeicherte Daten trifft, anstatt ein bedarfsgesteuertes Laden auszulösen.

Während der Aufwärmphase werden Felder auf Chunk-Ebene vorgeladen, während Indizes auf Segmentebene vorgeladen werden.

Konfiguration

Warmup kann auf drei Ebenen konfiguriert werden:

• Cluster-Ebene: Definieren Sie Standardwerte in milvus.yaml, die für alle Sammlungen gelten.

• Sammlungsebene: Überschreiben Sie die Cluster-Vorgaben für eine bestimmte Sammlung mithilfe von SDK-Methoden (create_collection, alter_collection_properties).

• Feld/Index-Ebene: Feinabstimmung einzelner Felder oder Indizes mit SDK-Methoden (add_field, alter_collection_field, add_index, alter_index_properties).

Einstellungen auf höherer Ebene haben Vorrang vor Einstellungen auf niedrigerer Ebene (Feld/Index > Sammlung > Cluster). Siehe Warm Up für detaillierte Konfigurationen.

Phase 3: Teilweise Belastung

Sobald Abfragen oder Suchvorgänge beginnen, führt der QueryNode eine Teilladung durch, wobei er nur die erforderlichen Datenchunks oder Indexdateien aus dem Objektspeicher abruft.

• Felder: Werden bei Bedarf auf der Chunk-Ebene geladen. Es werden nur Datenchunks abgerufen, die den aktuellen Abfragebedingungen entsprechen, wodurch die E/A- und Speichernutzung minimiert wird.

• Indizes: Werden bei Bedarf auf Segmentebene geladen. Indexdateien müssen als komplette Einheiten abgerufen werden und können nicht auf Chunks aufgeteilt werden.

Konfiguration

Die Teillast wird automatisch angewendet, wenn Tiered Storage aktiviert ist. Eine manuelle Einstellung ist nicht erforderlich. Um die First-Hit-Latenz für kritische Daten zu minimieren, kombinieren Sie diese Option mit Warm Up.

Phase 4: Auslagerung

Um eine gesunde Ressourcennutzung aufrechtzuerhalten, gibt Milvus automatisch ungenutzte Daten im Cache frei, wenn bestimmte Schwellenwerte erreicht werden.

Die Freigabe erfolgt nach einer LRU-Richtlinie (Least Recently Used), die sicherstellt, dass Daten, auf die nur selten zugegriffen wird, zuerst entfernt werden, während aktive Daten im Cache verbleiben.

Die Räumung wird durch die folgenden konfigurierbaren Elemente gesteuert:

• Wasserzeichen: Definieren Sie Speicher- oder Festplattenschwellenwerte, die die Auslagerung auslösen und stoppen.

• Cache-TTL: Entfernt veraltete Daten aus dem Cache nach einer bestimmten Dauer der Inaktivität.

Konfiguration

Aktivieren Sie die Verdrängungsparameter in milvus.yaml und stellen Sie sie ein. Siehe Verdrängung für eine detaillierte Konfiguration.

Erste Schritte

Voraussetzungen

• Milvus 2.6.4+

• QueryNodes mit dedizierten Speicher- und Festplattenressourcen

• Objektspeicher-Backend (S3, MinIO, usw.)

Grundlegende Konfigurationsvorlage

Bearbeiten Sie die Milvus-Konfigurationsdatei (milvus.yaml), um Tiered Storage-Einstellungen auf Clusterebene zu konfigurieren:

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      # Warm Up Configuration
      warmup:
        scalarField: sync      # Preload scalar field data
        scalarIndex: sync      # Preload scalar indexes
        vectorField: disable   # Don't preload vector field data (large)
        vectorIndex: sync      # Preload vector indexes
      
      # Eviction Configuration
      evictionEnabled: true
      backgroundEvictionEnabled: true
      
      # Memory Watermarks
      memoryLowWatermarkRatio: 0.75   # Stop evicting at 75%
      memoryHighWatermarkRatio: 0.80  # Start evicting at 80%
      
      # Disk Watermarks  
      diskLowWatermarkRatio: 0.75
      diskHighWatermarkRatio: 0.80
      
      # Cache TTL (7 days)
      cacheTtl: 604800

Nächste Schritte

1. Konfigurieren Sie Warm Up - Optimieren Sie das Vorladen für Ihre Zugriffsmuster. Siehe Aufwärmen.

2. Tune Eviction - Legen Sie geeignete Wasserzeichen und TTL für Ihre Ressourcenbeschränkungen fest. Siehe Eviction.

3. Leistung überwachen - Verfolgen Sie Cache-Trefferraten, Auslagerungshäufigkeit und Abfragelatenzmuster.

4. Konfiguration iterieren - Passen Sie die Einstellungen auf der Grundlage der beobachteten Arbeitslastmerkmale an.

FAQ

Kann ich Tiered Storage-Parameter während der Laufzeit ändern?

Das hängt vom Parametertyp ab:

• Warmup-Einstellungen: Warmup auf Sammlungs- und Feld-/Indexebene kann über das SDK konfiguriert werden, bevor die Sammlung geladen wird. Sobald die Sammlung geladen ist, müssen Sie sie zuerst freigeben, die Einstellungen ändern und dann erneut laden.

• Einstellungen für Ausschluss und Wasserzeichen: Diese müssen vor dem Start von Milvus unter milvus.yaml eingestellt werden. Änderungen erfordern einen Neustart, um wirksam zu werden.

Beeinflusst Tiered Storage die Haltbarkeit der Daten?

Nein. Die Dauerhaftigkeit der Daten wird nach wie vor von Remote Object Storage verwaltet. Tiered Storage verwaltet nur das Caching auf QueryNodes.

Werden Abfragen mit Tiered Storage immer schneller sein?

Nicht unbedingt. Tiered Storage reduziert die Ladezeit und die Ressourcennutzung, aber Abfragen, die auf nicht zwischengespeicherte (kalte) Daten zugreifen, können eine höhere Latenz aufweisen. Für latenzempfindliche Workloads wird der Volllastmodus empfohlen.

Warum gehen einem QueryNode auch bei aktiviertem Tiered Storage die Ressourcen aus?

Dafür gibt es zwei häufige Ursachen:

• Der QueryNode wurde mit zu wenig Ressourcen konfiguriert. Wasserzeichen sind relativ zu den verfügbaren Ressourcen, so dass eine Unterversorgung eine Fehleinschätzung noch verstärkt.

• QueryNode-Ressourcen werden mit anderen Workloads geteilt, so dass Tiered Storage die tatsächlich verfügbare Kapazität nicht richtig einschätzen kann.

Um dieses Problem zu beheben, empfehlen wir Ihnen, dedizierte Ressourcen für QueryNodes zuzuweisen.

Warum schlagen einige Abfragen bei hoher Gleichzeitigkeit fehl?

Wenn zu viele Abfragen gleichzeitig auf heiße Daten zugreifen, können die Ressourcengrenzen der QueryNodes dennoch überschritten werden. Einige Threads können aufgrund von Timeouts bei der Ressourcenreservierung fehlschlagen. Ein erneuter Versuch, nachdem die Last abgenommen hat, oder die Zuweisung weiterer Ressourcen kann dieses Problem beheben.

Warum erhöht sich die Such-/Abfrage-Latenzzeit nach der Aktivierung von Tiered Storage?

Mögliche Ursachen sind:

• Häufige Abfragen auf kalte Daten, die aus dem Speicher geholt werden müssen.

• Wasserzeichen, die zu dicht beieinander liegen, was zu häufigen synchronen Auslagerungen führt.