Replica in memoria

Questo argomento introduce il meccanismo di replica in memoria (replicazione) di Milvus, che consente di replicare più segmenti nella memoria di lavoro per migliorare le prestazioni e la disponibilità.

Per informazioni su come configurare le repliche in-memory, fare riferimento a Configurazioni relative ai nodi di query.

Panoramica

Disponibilità delle repliche

Con le repliche in-memory, Milvus può caricare lo stesso segmento su più nodi di query. Se un nodo di query è fallito o è occupato da una richiesta di ricerca corrente quando ne arriva un'altra, il sistema può inviare nuove richieste a un nodo di query inattivo che ha una replica dello stesso segmento.

Prestazioni

Le repliche in memoria consentono di sfruttare risorse extra di CPU e memoria. È molto utile se si dispone di un set di dati relativamente piccolo ma si vuole aumentare la velocità di lettura con risorse hardware aggiuntive. Il QPS (query al secondo) e il throughput complessivo possono essere migliorati in modo significativo.

Disponibilità

Le repliche in memoria aiutano Milvus a riprendersi più velocemente se un nodo di query si blocca. Quando un nodo di interrogazione si guasta, il segmento non deve essere ricaricato su un altro nodo di interrogazione. Al contrario, la richiesta di ricerca può essere inviata immediatamente a un nuovo nodo di query senza dover ricaricare i dati. Grazie alla gestione simultanea di più repliche di segmenti, il sistema è più resistente in caso di failover.

Concetti chiave

Le repliche in memoria sono organizzate come gruppi di repliche. Ogni gruppo di repliche contiene repliche shard. Ogni replica shard ha una replica streaming e una replica storica che corrispondono ai segmenti in crescita e sigillati nello shard (ad esempio, il canale DML).

Un'illustrazione del funzionamento della replica in-memory

Gruppo di replica

Un gruppo di replica è costituito da più nodi di query responsabili della gestione dei dati storici e delle repliche.

Replica shard

Una replica shard consiste in una replica streaming e in una replica storica, entrambe appartenenti allo stesso shard. Il numero di repliche shard in un gruppo di repliche è determinato dal numero di shard in una raccolta specifica.

Replica in streaming

Una replica in streaming contiene tutti i segmenti in crescita dello stesso canale DML. Tecnicamente, una replica di streaming dovrebbe essere servita da un solo nodo di query in una replica.

Replica storica

Una replica storica contiene tutti i segmenti sigillati dello stesso canale DML. I segmenti sigillati di una replica storica possono essere distribuiti su diversi nodi di query all'interno dello stesso gruppo di replica.

Leader dello shard

Uno shard leader è il nodo di query che serve la replica di streaming in una replica shard.

Dettagli di progettazione

Equilibrio

Un nuovo segmento che deve essere caricato viene assegnato a più nodi di ricerca diversi. Una richiesta di ricerca può essere elaborata una volta che almeno una replica è stata caricata con successo.

Ricerca

Cache

Il proxy mantiene una cache che mappa i segmenti ai nodi di interrogazione e la aggiorna periodicamente. Quando il proxy riceve una richiesta, Milvus prende dalla cache tutti i segmenti sigillati che devono essere cercati e cerca di assegnarli ai nodi di interrogazione in modo uniforme.

Per i segmenti in crescita, il proxy mantiene anche una cache channel-to-query-node e invia le richieste ai nodi di interrogazione corrispondenti.

Failover

Le cache del proxy non sono sempre aggiornate. Alcuni segmenti o canali potrebbero essere stati spostati su altri nodi di interrogazione quando arriva una richiesta. In questo caso, il proxy riceve una risposta di errore, aggiorna la cache e cerca di assegnare il segmento a un altro nodo di interrogazione.

Un segmento viene ignorato se il proxy non riesce a trovarlo dopo l'aggiornamento della cache. Questo potrebbe accadere se il segmento è stato compattato.

Se la cache non è accurata, il proxy potrebbe perdere alcuni segmenti. I nodi di interrogazione con canali DML (segmenti in crescita) restituiscono risposte di ricerca insieme a un elenco di segmenti affidabili che il proxy può confrontare e aggiornare la cache.

Miglioramento

Il proxy non può assegnare le richieste di ricerca ai nodi di query in modo completamente uguale e i nodi di query possono avere risorse diverse per servire le richieste di ricerca. Per evitare una distribuzione delle risorse a coda lunga, il proxy assegnerà i segmenti attivi su altri nodi di query a un nodo di query inattivo che dispone anch'esso di tali segmenti.