Home
Blog
Introduzione di AISAQ in Milvus: la ricerca vettoriale su scala miliardaria è appena diventata più economica di 3.200 volte sulla memoria

Introduzione di AISAQ in Milvus: la ricerca vettoriale su scala miliardaria è appena diventata più economica di 3.200 volte sulla memoria

Engineering

December 10, 2025

Martin Li

I database vettoriali sono diventati l'infrastruttura principale dei sistemi di intelligenza artificiale mission-critical e i loro volumi di dati crescono in modo esponenziale, spesso raggiungendo miliardi di vettori. A questa scala, tutto diventa più difficile: mantenere una bassa latenza, preservare l'accuratezza, garantire l'affidabilità e operare attraverso repliche e regioni. Ma una sfida tende a emergere presto e a dominare le decisioni architettoniche: il costo.

Per garantire una ricerca veloce, la maggior parte dei database vettoriali mantiene le strutture di indicizzazione chiave nella DRAM (Dynamic Random Access Memory), il livello di memoria più veloce e più costoso. Questo design è efficace per le prestazioni, ma è poco scalabile. L'utilizzo della DRAM varia in base alle dimensioni dei dati piuttosto che al traffico delle query e, anche con la compressione o l'offloading parziale su SSD, gran parte dell'indice deve rimanere in memoria. Quando i dataset crescono, i costi della memoria diventano rapidamente un fattore limitante.

Milvus supporta già DISKANN, un approccio ANN basato su disco che riduce la pressione sulla memoria spostando gran parte dell'indice su SSD. Tuttavia, DISKANN si affida ancora alla DRAM per le rappresentazioni compresse utilizzate durante la ricerca. Milvus 2.6 si spinge oltre con AISAQ, un indice vettoriale basato su disco ispirato a DISKANN. Sviluppata da KIOXIA, l'architettura di AiSAQ è stata progettata con una "Zero-DRAM-Footprint Architecture", che memorizza tutti i dati critici per la ricerca su disco e ottimizza la collocazione dei dati per ridurre al minimo le operazioni di I/O. In un carico di lavoro di un miliardo di vettori, questo riduce l'uso della memoria da 32 GB a circa 10 MB, con una riduzione di 3.200 volte, purmantenendo prestazioni pratiche.

Nelle sezioni che seguono spieghiamo come funziona la ricerca vettoriale basata su grafi, da dove derivano i costi di memoria e come AISAQ ridisegna la curva dei costi per la ricerca vettoriale su scala miliardaria.

Come funziona la ricerca vettoriale convenzionale basata sui grafi

Laricerca vettoriale è il processo di ricerca dei punti di dati le cui rappresentazioni numeriche sono le più vicine a un'interrogazione in uno spazio ad alta dimensionalità. Per "più vicino" si intende semplicemente la distanza minore secondo una funzione di distanza, come la distanza coseno o la distanza L2. Su piccola scala, questo è semplice: si calcola la distanza tra l'interrogazione e ogni vettore, quindi si restituiscono quelli più vicini. Tuttavia, su larga scala, ad esempio su scala miliardaria, questo approccio diventa rapidamente troppo lento per essere pratico.

Per evitare confronti esaustivi, i moderni sistemi di ricerca approssimata del vicino (ANNS) si basano su indici basati su grafi. Invece di confrontare una query con ogni vettore, l'indice organizza i vettori in un grafo. Ogni nodo rappresenta un vettore e gli spigoli collegano vettori numericamente vicini. Questa struttura consente al sistema di restringere notevolmente lo spazio di ricerca.

Il grafo viene costruito in anticipo, basandosi esclusivamente sulle relazioni tra i vettori. Non dipende dalle interrogazioni. Quando arriva una richiesta, il compito del sistema è quello di navigare nel grafo in modo efficiente e identificare i vettori con la distanza minore dalla richiesta, senza scansionare l'intero set di dati.

La ricerca inizia da un punto di ingresso predefinito nel grafo. Questo punto di partenza può essere lontano dalla query, ma l'algoritmo migliora la sua posizione passo dopo passo, spostandosi verso vettori che appaiono più vicini alla query. Durante questo processo, la ricerca mantiene due strutture di dati interne che lavorano insieme: un elenco di candidati e un elenco di risultati.

Le due fasi più importanti di questo processo sono l'espansione dell'elenco dei candidati e l'aggiornamento dell'elenco dei risultati.

Espansione dell'elenco dei candidati

L'elenco dei candidati rappresenta la prossima tappa della ricerca. È un insieme prioritario di nodi del grafo che appaiono promettenti in base alla loro distanza dalla query.

A ogni iterazione, l'algoritmo:

Seleziona il candidato più vicino scoperto finora. Dall'elenco dei candidati, sceglie il vettore con la distanza minore dall'interrogazione.
Recupera i vicini di questo vettore dal grafo. Questi vicini sono vettori che sono stati identificati durante la costruzione dell'indice come vicini al vettore corrente.
Valuta i vicini non visitati e li aggiunge all'elenco dei candidati. Per ogni vicino che non è già stato esplorato, l'algoritmo calcola la sua distanza dalla query. I vicini visitati in precedenza vengono saltati, mentre quelli nuovi vengono inseriti nell'elenco dei candidati se sembrano promettenti.

Espandendo ripetutamente l'elenco dei candidati, la ricerca esplora regioni sempre più rilevanti del grafo. Questo permette all'algoritmo di muoversi costantemente verso risposte migliori, esaminando solo una piccola frazione di tutti i vettori.

Aggiornamento dell'elenco dei risultati

Allo stesso tempo, l'algoritmo mantiene un elenco di risultati, che registra i migliori candidati trovati finora per l'output finale. Man mano che la ricerca procede, l'algoritmo

Traccia i vettori più vicini incontrati durante l'attraversamento. Questi includono i vettori selezionati per l'espansione e altri valutati lungo il percorso.
Memorizza le loro distanze dalla query. In questo modo è possibile classificare i candidati e mantenere l'attuale top-K dei più vicini.

Nel corso del tempo, man mano che si valutano più candidati e si trovano meno miglioramenti, l'elenco dei risultati si stabilizza. Quando è improbabile che un'ulteriore esplorazione del grafo produca vettori più vicini, la ricerca termina e restituisce l'elenco dei risultati come risposta finale.

In parole povere, l'elenco dei candidati controlla l'esplorazione, mentre l'elenco dei risultati cattura le migliori risposte scoperte finora.

Il compromesso nella ricerca vettoriale basata su grafi

L'approccio basato sul grafo è ciò che rende la ricerca vettoriale su larga scala pratica in primo luogo. Navigando nel grafo invece di scansionare ogni vettore, il sistema può trovare risultati di alta qualità toccando solo una piccola frazione del set di dati.

Tuttavia, questa efficienza non è gratuita. La ricerca basata su grafi espone un compromesso fondamentale tra accuratezza e costi.

L'esplorazione di un maggior numero di vicini migliora l'accuratezza coprendo una porzione più ampia del grafo e riducendo la possibilità di perdere i veri vicini.
Allo stesso tempo, ogni espansione aggiuntiva aggiunge lavoro: più calcoli di distanza, più accessi alla struttura del grafo e più letture di dati vettoriali. Man mano che la ricerca si approfondisce o si allarga, questi costi si accumulano. A seconda di come è stato progettato l'indice, questi costi si manifestano come un maggiore utilizzo della CPU, una maggiore pressione sulla memoria o un maggiore I/O su disco.

Il bilanciamento di queste forze contrapposte, tra un elevato richiamo e un uso efficiente delle risorse, è fondamentale per la progettazione di ricerche basate su grafi.

Sia DISKANN che AISAQ sono costruiti intorno a questa stessa tensione, ma fanno scelte architettoniche diverse su come e dove vengono pagati questi costi.

Come DISKANN ottimizza la ricerca vettoriale su disco

DISKANN è la soluzione ANN basata su disco più influente finora e funge da base ufficiale per la competizione NeurIPS Big ANN, un benchmark globale per la ricerca vettoriale su scala miliardaria. La sua importanza non risiede solo nelle prestazioni, ma in ciò che ha dimostrato: la ricerca ANN basata su grafi non deve vivere interamente in memoria per essere veloce.

Combinando l'archiviazione basata su SSD con strutture in memoria accuratamente scelte, DISKANN ha dimostrato che la ricerca vettoriale su larga scala può raggiungere un'elevata accuratezza e una bassa latenza su hardware commodity, senza richiedere ingombri massicci di DRAM. Ciò avviene ripensando quali parti della ricerca devono essere veloci e quali possono tollerare un accesso più lento.

Ad alto livello, DISKANN mantiene in memoria i dati a cui si accede più frequentemente, spostando su disco le strutture più grandi e a cui si accede meno frequentemente. Questo equilibrio si ottiene grazie a diverse scelte progettuali fondamentali.

1. Uso delle distanze PQ per espandere l'elenco dei candidati

L'espansione dell'elenco dei candidati è l'operazione più frequente nella ricerca a grafo. Ogni espansione richiede la stima della distanza tra il vettore della query e i vicini di un nodo candidato. L'esecuzione di questi calcoli utilizzando vettori completi ad alta dimensione richiederebbe frequenti letture casuali dal disco, un'operazione costosa sia dal punto di vista computazionale che dell'I/O. DISKANN evita questo costo.

DISKANN evita questo costo comprimendo i vettori in codici di quantizzazione del prodotto (PQ) e mantenendoli in memoria. I codici PQ sono molto più piccoli dei vettori completi, ma conservano comunque informazioni sufficienti per stimare approssimativamente la distanza.

Durante l'espansione dei candidati, DISKANN calcola le distanze usando questi codici PQ in memoria invece di leggere i vettori completi dall'SSD. Questo riduce drasticamente l'I/O su disco durante l'attraversamento del grafo, consentendo alla ricerca di espandere i candidati in modo rapido ed efficiente, mantenendo la maggior parte del traffico SSD fuori dal percorso critico.

2. Co-localizzazione dei vettori completi e degli elenchi di vicini su disco

Non tutti i dati possono essere compressi o accessibili in modo approssimativo. Una volta identificati i candidati promettenti, la ricerca ha ancora bisogno di accedere a due tipi di dati per ottenere risultati accurati:

Elenchi di vicini, per continuare l'attraversamento del grafo.
Vettori completi (non compressi), per il reranking finale.

Queste strutture sono accessibili meno frequentemente dei codici PQ, quindi DISKANN le memorizza su SSD. Per ridurre al minimo l'overhead del disco, DISKANN colloca l'elenco dei vicini di ogni nodo e il suo vettore completo nella stessa regione fisica del disco. Ciò garantisce che una singola lettura su SSD possa recuperare entrambi.

Grazie alla co-localizzazione dei dati correlati, DISKANN riduce il numero di accessi casuali al disco necessari durante la ricerca. Questa ottimizzazione migliora l'efficienza dell'espansione e del reranking, soprattutto su larga scala.

3. Espansione parallela dei nodi per un migliore utilizzo dell'SSD

La ricerca di RNA basate su grafi è un processo iterativo. Se ogni iterazione espande un solo nodo candidato, il sistema esegue una sola lettura del disco alla volta, lasciando inutilizzata la maggior parte della larghezza di banda parallela dell'SSD. Per evitare questa inefficienza, DISKANN espande più candidati in ogni iterazione e invia richieste di lettura parallele all'SSD. Questo approccio sfrutta molto meglio la larghezza di banda disponibile e riduce il numero totale di iterazioni necessarie.

Il parametro beam_width_ratio controlla il numero di candidati espansi in parallelo: Larghezza del fascio = numero di core della CPU × beam_width_ratio. Un rapporto più alto allarga la ricerca, potenzialmente migliorando l'accuratezza, ma aumenta anche il calcolo e l'I/O su disco.

Per compensare questo problema, DISKANN introduce un search_cache_budget_gb_ratio che riserva la memoria per memorizzare nella cache i dati a cui si accede di frequente, riducendo le letture ripetute sull'SSD. Insieme, questi meccanismi aiutano DISKANN a trovare un equilibrio tra precisione, latenza ed efficienza I/O.

Perché questo è importante e dove appaiono i limiti

Il design di DISKANN rappresenta un importante passo avanti per la ricerca vettoriale su disco. Mantenendo i codici PQ in memoria e spingendo le strutture più grandi su SSD, riduce significativamente l'ingombro in memoria rispetto agli indici a grafo completamente in-memory.

Allo stesso tempo, questa architettura dipende ancora dalla DRAM sempre attiva per i dati critici per la ricerca. I codici PQ, le cache e le strutture di controllo devono rimanere in memoria per mantenere efficiente l'attraversamento. Quando i set di dati crescono fino a miliardi di vettori e le implementazioni aggiungono repliche o regioni, questo requisito di memoria può ancora diventare un fattore limitante.

Questa è la lacuna che AISAQ è stato progettato per colmare.

Come funziona AISAQ e perché è importante

AISAQ si basa direttamente sulle idee alla base di DISKANN, ma introduce un cambiamento fondamentale: elimina la necessità di mantenere i dati PQ nella DRAM. Invece di trattare i vettori compressi come strutture critiche per la ricerca e sempre in memoria, AISAQ li sposta su SSD e riprogetta il modo in cui i dati del grafo sono disposti su disco per preservare un'attraversamento efficiente.

Per far sì che questo funzioni, AISAQ riorganizza lo storage dei nodi in modo che i dati necessari durante la ricerca sul grafo - vettori completi, elenchi di vicini e informazioni PQ - siano disposti su disco secondo schemi ottimizzati per la localizzazione degli accessi. L'obiettivo non è solo quello di spostare più dati sul disco più economico, ma di farlo senza interrompere il processo di ricerca descritto in precedenza.

Per rispondere alle diverse esigenze applicative, AISAQ offre due modalità di archiviazione su disco: Performance e Scale. Da un punto di vista tecnico, queste modalità differiscono principalmente per il modo in cui i dati compressi in PQ vengono memorizzati e a cui si accede durante la ricerca. Dal punto di vista applicativo, queste modalità rispondono a due tipi distinti di requisiti: requisiti di bassa latenza, tipici della ricerca semantica online e dei sistemi di raccomandazione, e requisiti di altissima scala, tipici del RAG.

Prestazioni di AISAQ: Ottimizzato per la velocità

AISAQ-performance conserva tutti i dati su disco mantenendo un basso overhead di I/O grazie alla colocazione dei dati.

In questa modalità:

Il vettore completo di ogni nodo, l'elenco dei bordi e i codici PQ dei suoi vicini sono memorizzati insieme su disco.
La visita di un nodo richiede comunque una sola lettura dell'SSD, perché tutti i dati necessari per l'espansione e la valutazione dei candidati sono colocalizzati.

Dal punto di vista dell'algoritmo di ricerca, questo rispecchia fedelmente il modello di accesso di DISKANN. L'espansione dei candidati rimane efficiente e le prestazioni di runtime sono paragonabili, anche se tutti i dati critici per la ricerca si trovano ora su disco.

Il compromesso è l'overhead di memorizzazione. Poiché i dati PQ di un vicino possono apparire nelle pagine del disco di più nodi, questa disposizione introduce ridondanza e aumenta significativamente la dimensione complessiva dell'indice.

Pertanto, la modalità AISAQ-Performance privilegia una bassa latenza di I/O rispetto all'efficienza del disco. Dal punto di vista applicativo, la modalità AiSAQ-Performance può garantire una latenza dell'ordine di 10 mSec, come richiesto per la ricerca semantica online.

Scala AISAQ: Ottimizzato per l'efficienza dello storage

AISAQ-Scale adotta l'approccio opposto. È stato progettato per ridurre al minimo l'utilizzo del disco, pur mantenendo tutti i dati su SSD.

In questa modalità:

I dati PQ vengono archiviati su disco separatamente, senza ridondanza.
Questo elimina la ridondanza e riduce drasticamente le dimensioni dell'indice.

Il compromesso è che l'accesso ai codici PQ di un nodo e dei suoi vicini può richiedere più letture su SSD, aumentando le operazioni di I/O durante l'espansione dei candidati. Se non ottimizzato, questo rallenterebbe notevolmente la ricerca.

Per controllare questo overhead, la modalità AISAQ-Scale introduce due ottimizzazioni aggiuntive:

Riorganizzazione dei dati PQ, che ordina i vettori PQ in base alla priorità di accesso per migliorare la localizzazione e ridurre le letture casuali.
Una cache PQ nella DRAM (pq_read_page_cache_size), che memorizza i dati PQ a cui si accede di frequente ed evita letture ripetute del disco per le voci calde.

Con queste ottimizzazioni, la modalità AISAQ-Scale raggiunge un'efficienza di memorizzazione molto migliore di AISAQ-Performance, pur mantenendo prestazioni di ricerca pratiche. Le prestazioni rimangono inferiori a quelle di DISKANN, ma non c'è sovraccarico di memoria (la dimensione dell'indice è simile a quella di DISKANN) e l'ingombro della memoria è nettamente inferiore. Dal punto di vista applicativo, AiSAQ fornisce i mezzi per soddisfare i requisiti RAG su scala ultraelevata.

Vantaggi principali di AISAQ

Spostando tutti i dati critici per la ricerca su disco e riprogettando le modalità di accesso a tali dati, AISAQ cambia radicalmente il profilo di costo e scalabilità della ricerca vettoriale a grafo. Il suo design offre tre vantaggi significativi.

1. Utilizzo della DRAM fino a 3.200 volte inferiore

La quantizzazione del prodotto riduce in modo significativo le dimensioni dei vettori ad alta dimensionalità, ma su scala miliardaria l'ingombro in memoria è ancora notevole. Anche dopo la compressione, i codici PQ devono essere mantenuti in memoria durante la ricerca nei progetti convenzionali.

Per esempio, su SIFT1B, un benchmark con un miliardo di vettori a 128 dimensioni, i soli codici PQ richiedono circa 30-120 GB di DRAM, a seconda della configurazione. La memorizzazione dei vettori completi non compressi richiederebbe altri 480 GB. Sebbene PQ riduca l'uso della memoria di 4-16×, l'ingombro rimanente è ancora abbastanza grande da dominare il costo dell'infrastruttura.

AISAQ elimina completamente questo requisito. Memorizzando i codici PQ su SSD anziché su DRAM, la memoria non viene più consumata dai dati persistenti dell'indice. La DRAM viene utilizzata solo per strutture leggere e transitorie, come gli elenchi di candidati e i metadati di controllo. In pratica, questo riduce l'utilizzo della memoria da decine di gigabyte a circa 10 MB. In una configurazione rappresentativa su scala miliardaria, la DRAM passa da 32 GB a 10 MB, con una riduzione di 3.200 volte.

Dato che lo storage SSD costa circa 1/30 del prezzo per unità di capacità rispetto alla DRAM, questo cambiamento ha un impatto diretto e drammatico sul costo totale del sistema.

2. Nessun sovraccarico di I/O aggiuntivo

Lo spostamento dei codici PQ dalla memoria al disco normalmente aumenta il numero di operazioni di I/O durante la ricerca. AISAQ evita questo problema controllando attentamente la disposizione dei dati e i modelli di accesso. Invece di disperdere i dati correlati sul disco, AISAQ co-loca i codici PQ, i vettori completi e gli elenchi di vicini in modo che possano essere recuperati insieme. Ciò garantisce che l'espansione dei candidati non introduca letture casuali aggiuntive.

Per consentire agli utenti di controllare il compromesso tra dimensione dell'indice ed efficienza I/O, AISAQ introduce il parametro inline_pq, che determina la quantità di dati PQ memorizzati in linea con ciascun nodo:

Inline_pq più basso: dimensione dell'indice più piccola, ma può richiedere I/O aggiuntivo
Inline_pq più alto: dimensione dell'indice maggiore, ma preserva l'accesso a lettura singola.

Quando è configurato con inline_pq = max_degree, AISAQ legge il vettore completo di un nodo, l'elenco dei vicini e tutti i codici PQ in un'unica operazione su disco, rispettando il modello di I/O di DISKANN e mantenendo tutti i dati su SSD.

3. L'accesso sequenziale ai PQ migliora l'efficienza di calcolo

In DISKANN, l'espansione di un nodo candidato richiede R accessi casuali alla memoria per recuperare i codici PQ dei suoi R vicini. AISAQ elimina questa casualità recuperando tutti i codici PQ in un unico I/O e memorizzandoli in sequenza su disco.

Il layout sequenziale offre due importanti vantaggi:

Le letture sequenziali su SSD sono molto più veloci delle letture casuali sparse.
I dati contigui sono più adatti alla cache, consentendo alle CPU di calcolare le distanze PQ in modo più efficiente.

Questo migliora sia la velocità che la prevedibilità dei calcoli delle distanze PQ e aiuta a compensare il costo delle prestazioni della memorizzazione dei codici PQ su SSD piuttosto che su DRAM.

AISAQ vs. DISKANN: valutazione delle prestazioni

Dopo aver compreso come AISAQ differisce architettonicamente da DISKANN, la domanda successiva è semplice: come influiscono queste scelte progettuali sulle prestazioni e sull'utilizzo delle risorse nella pratica? Questa valutazione confronta AISAQ e DISKANN su tre dimensioni che contano di più su scala miliardaria: prestazioni di ricerca, consumo di memoria e utilizzo del disco.

In particolare, esaminiamo il comportamento di AISAQ al variare della quantità di dati PQ inline (INLINE_PQ). Questo parametro controlla direttamente il compromesso tra dimensione dell'indice, I/O su disco ed efficienza di runtime. Valutiamo inoltre entrambi gli approcci su carichi di lavoro vettoriali a bassa e alta dimensione, poiché la dimensionalità influenza fortemente il costo del calcolo della distanza e i requisiti di memorizzazione.

Configurazione

Tutti gli esperimenti sono stati condotti su un sistema a singolo nodo per isolare il comportamento dell'indice ed evitare l'interferenza degli effetti della rete o del sistema distribuito.

Configurazione hardware:

CPU: CPU Intel® Xeon® Platinum 8375C @ 2,90GHz
Memoria: Velocità: 3200 MT/s, Tipo: DDR4, Dimensione: 32 GB
Disco: 500 GB NVMe SSD

Parametri di creazione dell'indice

{
  "max_degree": 48,
  "search_list_size": 100,
  "inline_pq": 0/12/24/48,  // AiSAQ only
  "pq_code_budget_gb_ratio": 0.125,
  "search_cache_budget_gb_ratio": 0.0,
  "build_dram_budget_gb": 32.0
}

Parametri di interrogazione

{
  "k": 100,
  "search_list_size": 100,
  "beamwidth": 8
}

Metodo di benchmark

Sia DISKANN che AISAQ sono stati testati utilizzando Knowhere, il motore di ricerca vettoriale open-source utilizzato in Milvus. Per questa valutazione sono stati utilizzati due set di dati:

SIFT128D (1M di vettori): un noto benchmark a 128 dimensioni comunemente utilizzato per la ricerca di descrittori di immagini. (Dimensione del dataset grezzo ≈ 488 MB)
Cohere768D (1M vettori): un set di incorporazione a 768 dimensioni tipico della ricerca semantica basata su trasformatori. (Dimensione del dataset grezzo ≈ 2930 MB)

Questi set di dati riflettono due distinti scenari del mondo reale: caratteristiche visive compatte e grandi incorporazioni semantiche.

Risultati

Sift128D1M (vettore completo ~488MB)

Cohere768D1M (vettore completo ~2930MB)

Analisi

Set di dati SIFT128D

Sul set di dati SIFT128D, AISAQ è in grado di eguagliare le prestazioni di DISKANN quando tutti i dati PQ sono inseriti in linea, in modo che i dati richiesti da ciascun nodo si inseriscano interamente in una singola pagina SSD da 4 KB (INLINE_PQ = 48). Con questa configurazione, tutte le informazioni necessarie per la ricerca sono collocate:

Vettore completo: 512B
Elenco dei vicini: 48 × 4 + 4 = 196B
Codici PQ dei vicini: 48 × (512B × 0,125) ≈ 3072B
Totale: 3780B

Poiché l'intero nodo rientra in una pagina, è necessario un solo I/O per ogni accesso e AISAQ evita la lettura casuale dei dati PQ esterni.

Tuttavia, quando solo una parte dei dati PQ è inline, i codici PQ rimanenti devono essere recuperati da un'altra parte del disco. Questo introduce ulteriori operazioni di I/O casuali, che aumentano drasticamente la richiesta di IOPS e portano a significativi cali di prestazioni.

Set di dati Cohere768D

Sul dataset Cohere768D, AISAQ si comporta peggio di DISKANN. Il motivo è che un vettore di 768 dimensioni semplicemente non si adatta a una pagina SSD da 4 KB:

Vettore completo: 3072B
Elenco dei vicini: 48 × 4 + 4 = 196B
Codici PQ dei vicini: 48 × (3072B × 0,125) ≈ 18432B
Totale: 21.700 B (≈ 6 pagine)

In questo caso, anche se tutti i codici PQ sono inline, ogni nodo si estende su più pagine. Mentre il numero di operazioni di I/O rimane costante, ogni I/O deve trasferire molti più dati, consumando molto più velocemente la larghezza di banda dell'SSD. Una volta che la larghezza di banda diventa il fattore limitante, AISAQ non riesce a tenere il passo con DISKANN, soprattutto su carichi di lavoro ad alta dimensionalità in cui i dati per nodo crescono rapidamente.

Nota:

Il layout di archiviazione di AISAQ di solito aumenta la dimensione dell'indice su disco di 4× a 6×. Si tratta di un compromesso intenzionale: i vettori completi, gli elenchi di vicini e i codici PQ sono collocati su disco per consentire un accesso efficiente a pagina singola durante la ricerca. Sebbene questo aumenti l'utilizzo dell'SSD, la capacità del disco è significativamente più economica rispetto alla DRAM e può essere scalata più facilmente con grandi volumi di dati.

In pratica, gli utenti possono regolare questo compromesso regolando i rapporti di compressione di INLINE_PQ e PQ. Questi parametri consentono di bilanciare le prestazioni di ricerca, l'ingombro del disco e il costo complessivo del sistema in base ai requisiti del carico di lavoro, anziché essere vincolati da limiti di memoria fissi.

Conclusione

L'economia dell'hardware moderno sta cambiando. I prezzi delle memorie DRAM rimangono elevati, mentre le prestazioni delle unità SSD sono progredite rapidamente: le unità PCIe 5.0 offrono ora una larghezza di banda superiore a 14 GB/s. Di conseguenza, le architetture che spostano i dati critici per la ricerca dalla costosa DRAM allo storage SSD, molto più conveniente, stanno diventando sempre più interessanti. Con la capacità delle unità SSD che costa meno di 30 volte per gigabyte rispetto alla DRAM, queste differenze non sono più marginali: influenzano in modo significativo la progettazione del sistema.

AISAQ riflette questo cambiamento. Eliminando la necessità di allocare grandi quantità di memoria, consente ai sistemi di ricerca vettoriale di scalare in base alle dimensioni dei dati e ai requisiti del carico di lavoro piuttosto che ai limiti della DRAM. Questo approccio è in linea con una tendenza più ampia verso le architetture "all-in-storage", in cui le veloci unità SSD svolgono un ruolo centrale non solo nella persistenza, ma anche nel calcolo e nella ricerca attivi. Offrendo due modalità operative - Performance e Scale - AiSAQ soddisfa i requisiti sia della ricerca semantica (che richiede la latenza più bassa) sia della RAG (che richiede una scala molto elevata, ma una latenza moderata).

È improbabile che questo cambiamento sia limitato ai database vettoriali. Modelli di progettazione simili stanno già emergendo nell'elaborazione dei grafi, nell'analisi delle serie temporali e persino in parti dei sistemi relazionali tradizionali, in quanto gli sviluppatori ripensano a ipotesi di vecchia data sulla posizione dei dati per ottenere prestazioni accettabili. Con l'evoluzione dell'economia dell'hardware, le architetture di sistema seguiranno la stessa strada.

Per maggiori dettagli sui progetti qui discussi, consultare la documentazione:

Avete domande o volete un approfondimento su una qualsiasi caratteristica dell'ultimo Milvus? Unitevi al nostro canale Discord o inviate problemi su GitHub. È anche possibile prenotare una sessione individuale di 20 minuti per ottenere approfondimenti, indicazioni e risposte alle vostre domande tramite Milvus Office Hours.