Panoramica sull'archiviazione a livelliCompatible with Milvus 2.6.4+
In Milvus, la modalità tradizionale full-load richiede che ogni QueryNode carichi tutti i campi dati e gli indici di un segmento al momento dell'inizializzazione, anche quelli a cui non si accede mai. Questo garantisce la disponibilità immediata dei dati, ma spesso comporta uno spreco di risorse, tra cui un elevato utilizzo della memoria, un'intensa attività su disco e un significativo overhead di I/O, soprattutto quando si gestiscono insiemi di dati di grandi dimensioni.
Lostorage a livelli affronta questa sfida disaccoppiando la cache dei dati dal caricamento dei segmenti. Invece di caricare tutti i dati in una sola volta, Milvus introduce un livello di caching che distingue tra dati caldi (memorizzati nella cache locale) e dati freddi (memorizzati in remoto). Il QueryNode carica inizialmente solo metadati leggeri e preleva o evade dinamicamente i dati del campo su richiesta. Questo riduce significativamente il tempo di caricamento, ottimizza l'utilizzo delle risorse locali e consente ai QueryNode di elaborare set di dati che superano di gran lunga la loro memoria fisica o la capacità del disco.
Considerate la possibilità di attivare l'archiviazione a livelli in scenari quali:
Collezioni che superano la memoria disponibile o la capacità NVMe di un singolo QueryNode
Carichi di lavoro analitici o batch in cui la velocità di caricamento è più importante della latenza della prima interrogazione.
Carichi di lavoro misti che possono tollerare occasionali mancanze della cache per i dati a cui si accede meno frequentemente.
Imetadati comprendono lo schema, le definizioni degli indici, le mappe dei chunk, il conteggio delle righe e i riferimenti agli oggetti remoti. Questo tipo di dati è piccolo, sempre in cache e mai evaso.
Per maggiori dettagli su segmenti e chunk, consultare Segmento.
Come funziona
Tiered Storage cambia il modo in cui QueryNode gestisce i dati dei segmenti. Invece di memorizzare nella cache tutti i campi e gli indici al momento del caricamento, QueryNode ora carica solo i metadati e utilizza un livello di cache per recuperare ed eliminare i dati dinamicamente.
Modalità full-load vs. modalità di archiviazione a livelli
Le modalità full-load e Tiered Storage gestiscono gli stessi dati, ma si differenziano per il momento e il modo in cui QueryNode memorizza nella cache questi componenti.
Modalità full-load: Al momento del caricamento, QueryNode memorizza nella cache i dati completi della raccolta, compresi i metadati, i dati dei campi e gli indici, dalla memoria degli oggetti.
Modalità di archiviazione a livelli: Al momento del caricamento, QueryNode memorizza nella cache solo i metadati. I dati dei campi vengono estratti su richiesta a granularità di chunk. I file degli indici rimangono remoti finché la prima query non ne ha bisogno; a quel punto l'intero indice per segmento viene recuperato e messo in cache.
Il diagramma seguente mostra queste differenze.
Modalità Full Load vs modalità di archiviazione a livelli
Flusso di lavoro per il caricamento dei QueryNode
In modalità Tiered Storage, il flusso di lavoro prevede queste fasi:
Flusso di lavoro per il caricamento del querynode
Fase 1: Carico pigro
All'inizializzazione, Milvus esegue un caricamento pigro, mettendo in cache solo i metadati a livello di segmento, come le definizioni di schema, le informazioni sugli indici e le mappature dei chunk.
In questa fase non vengono memorizzati nella cache i dati dei campi o i file degli indici. Questo permette alle collezioni di diventare interrogabili quasi immediatamente dopo l'avvio, mantenendo il consumo di memoria e di disco al minimo.
Poiché i dati di campo e i file di indice rimangono nello storage remoto fino al primo accesso, la prima query può presentare una latenza aggiuntiva, poiché i dati necessari devono essere recuperati su richiesta. Per mitigare questo effetto per i campi o gli indici critici, è possibile utilizzare la strategia Warm Up per precaricarli in modo proattivo prima che il segmento diventi interrogabile.
Configurazione
Si applica automaticamente quando si abilita l'archiviazione a livelli. Non è necessaria alcuna impostazione manuale.
Fase 2: riscaldamento
Per ridurre la latenza di primo impatto introdotta dal caricamento pigro, Milvus offre un meccanismo di riscaldamento.
Prima che un segmento diventi interrogabile, Milvus è in grado di recuperare e memorizzare nella cache campi o indici specifici dallo storage degli oggetti, assicurando che la prima query colpisca direttamente i dati memorizzati nella cache invece di attivare il caricamento su richiesta.
Durante il warmup, i campi vengono precaricati a livello di chunk, mentre gli indici vengono precaricati a livello di segmento.
Configurazione
Le impostazioni di Warm Up sono definite nella sezione Tiered Storage di milvus.yaml. È possibile abilitare o disabilitare il precaricamento per ogni tipo di campo o indice e specificare la strategia preferita. Per le configurazioni dettagliate, vedere Warm Up.
Fase 3: caricamento parziale
Una volta iniziate le query o le ricerche, il QueryNode esegue un caricamento parziale, recuperando solo i chunk di dati o i file di indice necessari dallo storage degli oggetti.
Campi: Caricati su richiesta a livello di chunk. Vengono recuperati solo i chunk di dati che corrispondono alle condizioni della query corrente, riducendo al minimo l'I/O e l'uso della memoria.
Indici: Caricati su richiesta a livello di segmento. I file degli indici devono essere recuperati come unità complete e non possono essere suddivisi in chunk.
Configurazione
Il carico parziale viene applicato automaticamente quando si attiva l'archiviazione a livelli. Non è necessaria alcuna impostazione manuale. Per ridurre al minimo la latenza di primo impatto per i dati critici, combinarlo con Warm Up.
Fase 4: Evacuazione
Per mantenere un uso sano delle risorse, Milvus rilascia automaticamente i dati inutilizzati nella cache quando vengono raggiunte soglie specifiche.
L'eviction segue una politica LRU (Least Recently Used), assicurando che i dati a cui si accede di rado vengano rimossi per primi, mentre i dati attivi rimangono nella cache.
Lo svuotamento è regolato dai seguenti elementi configurabili:
Filigrane: Definizione di soglie di memoria o di disco che attivano e interrompono lo svuotamento.
TTL della cache: rimuove i dati stantii presenti nella cache dopo una durata definita di inattività.
Configurazione
Abilitare e sintonizzare i parametri di eviction in milvus.yaml. Per una configurazione dettagliata, vedere Eviction.
Come iniziare
Prerequisiti
Milvus 2.6.4+
QueryNodes con risorse di memoria e disco dedicate
Backend di archiviazione degli oggetti (S3, MinIO, ecc.)
Le risorse dei QueryNode non devono essere condivise con altri carichi di lavoro. Le risorse condivise possono indurre Tiered Storage a valutare erroneamente la capacità disponibile, causando arresti anomali.
Modello di configurazione di base
Modificare il file di configurazione di Milvus (milvus.yaml) per configurare le impostazioni di Tiered Storage:
# 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
Passi successivi
Configurare il Warm Up - Ottimizzare il precaricamento per i modelli di accesso. Vedere Warm Up.
Messa a punto dell'Eviction - Impostare i watermark e il TTL appropriati per i vincoli delle risorse. Vedere Eviction.
Monitorare le prestazioni - Tracciare le percentuali di accesso alla cache, la frequenza di evasione e i modelli di latenza delle query.
Iterare la configurazione - Regolare le impostazioni in base alle caratteristiche del carico di lavoro osservato.
DOMANDE FREQUENTI
È possibile modificare i parametri di Tiered Storage in fase di esecuzione?
Tutti i parametri devono essere impostati in milvus.yaml prima di avviare Milvus. Le modifiche richiedono un riavvio per avere effetto.
Il Tiered Storage influisce sulla persistenza dei dati?
No. La persistenza dei dati è ancora gestita dalla memorizzazione remota degli oggetti. Tiered Storage gestisce solo la cache sui QueryNode.
Le query saranno sempre più veloci con Tiered Storage?
Non necessariamente. Il Tiered Storage riduce i tempi di caricamento e l'utilizzo delle risorse, ma le query che toccano dati non memorizzati nella cache (freddi) possono avere una latenza maggiore. Per i carichi di lavoro sensibili alla latenza, si consiglia la modalità full-load.
Perché un QueryNode continua a esaurire le risorse anche con il Tiered Storage attivato?
Due cause comuni:
Il QueryNode è stato configurato con un numero di risorse troppo basso. I watermark sono relativi alle risorse disponibili, quindi un approvvigionamento insufficiente amplifica le valutazioni errate.
Le risorse del QueryNode sono condivise con altri carichi di lavoro, quindi Tiered Storage non è in grado di valutare correttamente la capacità effettiva disponibile.
Per risolvere questo problema, si consiglia di allocare risorse dedicate ai QueryNode.
Perché alcune query falliscono in caso di elevata concurrency?
Se un numero eccessivo di query colpisce contemporaneamente i dati caldi, i limiti delle risorse dei QueryNode possono essere superati. Alcuni thread possono fallire a causa del timeout della prenotazione delle risorse. Il problema può essere risolto riprovando dopo che il carico è diminuito o allocando più risorse.
Perché la latenza di ricerca/query aumenta dopo aver attivato l'archiviazione a livelli?
Le possibili cause sono:
Frequenti interrogazioni di dati freddi, che devono essere recuperati dallo storage.
Filigrane impostate troppo vicine, che causano frequenti evacuazioni sincrone.