Migliori pratiche per l'archiviazione a livelliCompatible with Milvus 2.6.4+

Milvus offre il sistema di archiviazione a livelli per aiutarvi a gestire in modo efficiente i dati su larga scala, bilanciando la latenza delle query, la capacità e l'utilizzo delle risorse. Questa guida riassume le configurazioni consigliate per i carichi di lavoro tipici e spiega le ragioni di ciascuna strategia di ottimizzazione.

Prima di iniziare

• Milvus v2.6.4 o successivo

• I QueryNode devono avere risorse locali dedicate (memoria e disco). Gli ambienti condivisi possono distorcere la stima della cache e causare errori di valutazione.

Scegliere la strategia giusta

Tiered Storage offre strategie flessibili di caricamento e caching che possono essere combinate per adattarsi al carico di lavoro.

Scenario 1: recupero in tempo reale e a bassa latenza

Quando utilizzare

• La latenza delle query è critica (ad esempio, raccomandazioni in tempo reale o ranking di ricerca)

• Gli indici vettoriali e i filtri scalari del core vengono acceduti frequentemente

• Le prestazioni costanti sono più importanti della velocità di avviamento

Configurazione consigliata

# 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

Motivazione

• Il warmup elimina la latenza di primo impatto per gli indici scalari e vettoriali ad alta frequenza.

• Lo sfratto in background mantiene stabile la pressione della cache senza bloccare le query.

• La disabilitazione del TTL della cache evita ricariche inutili per i dati caldi.

Scenario 2: analisi offline, in batch

Quando si usa

• La tolleranza alla latenza delle query è elevata

• I carichi di lavoro coinvolgono insiemi di dati massicci o molti segmenti.

• La capacità e il throughput sono prioritari rispetto alla reattività.

Configurazione consigliata

# 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

Motivazione

• La disabilitazione del warm-up accelera l'avvio quando si inizializzano molti segmenti.

• Filigrane più alte consentono un uso più denso della cache, migliorando la capacità di carico totale.

• Il TTL della cache pulisce automaticamente i dati inutilizzati per liberare spazio locale.

Scenario 3: distribuzione ibrida (mista online + offline)

Quando si usa

• Un singolo cluster serve sia carichi di lavoro online che analitici.

• Alcune collezioni richiedono una bassa latenza, mentre altre danno priorità alla capacità.

Strategia consigliata

• Applicare la configurazione in tempo reale alle raccolte sensibili alla latenza.

• Applicare la configurazione offline alle raccolte analitiche o di archivio.

• Regolare evictableMemoryCacheRatio, cacheTtl e rapporti di filigrana in modo indipendente per ogni tipo di carico di lavoro.

Motivazione

La combinazione delle configurazioni consente un controllo a grana fine dell'allocazione delle risorse.

Le raccolte critiche mantengono garanzie di bassa latenza, mentre le raccolte secondarie possono gestire più segmenti e volumi di dati.

Ulteriori suggerimenti per la messa a punto