Come Milvus bilancia il carico delle query tra i nodi?

Immagine di copertina di Binlog

Di Xi Ge.

Nei precedenti articoli del blog abbiamo introdotto le funzioni di cancellazione, bitet e compattazione di Milvus 2.0. Per concludere questa serie, vorremmo condividere il progetto del bilanciamento del carico, una funzione vitale nel cluster distribuito di Milvus.

L'implementazione

Mentre il numero e la dimensione dei segmenti bufferizzati nei nodi di interrogazione differiscono, anche le prestazioni di ricerca tra i nodi di interrogazione possono variare. Il caso peggiore è quello in cui alcuni nodi di interrogazione esauriscono la ricerca su una grande quantità di dati, ma i nodi di interrogazione appena creati rimangono inattivi perché non viene distribuito loro alcun segmento, causando un enorme spreco di risorse della CPU e un'enorme diminuzione delle prestazioni di ricerca.

Per evitare tali circostanze, il coordinatore delle query (query coord) è programmato per distribuire i segmenti in modo uniforme a ogni nodo di query, in base all'utilizzo della RAM dei nodi. In questo modo, le risorse della CPU vengono consumate equamente da tutti i nodi, migliorando in modo significativo le prestazioni di ricerca.

Attivare il bilanciamento automatico del carico

In base al valore predefinito della configurazione queryCoord.balanceIntervalSeconds, il query coord controlla l'utilizzo della RAM (in percentuale) di tutti i nodi di query ogni 60 secondi. Se una delle seguenti condizioni è soddisfatta, il query coord inizia a bilanciare il carico delle query sui nodi di query:

1. L'utilizzo della RAM di qualsiasi nodo di query nel cluster è superiore a queryCoord.overloadedMemoryThresholdPercentage (valore predefinito: 90);
2. Oppure il valore assoluto della differenza di utilizzo della RAM di due nodi di query è maggiore di queryCoord.memoryUsageMaxDifferencePercentage (valore predefinito: 30).

Dopo che i segmenti sono stati trasferiti dal nodo di query di origine al nodo di query di destinazione, devono soddisfare entrambe le condizioni seguenti:

1. L'utilizzo della RAM del nodo di query di destinazione non è superiore a queryCoord.overloadedMemoryThresholdPercentage (valore predefinito: 90);
2. il valore assoluto della differenza di utilizzo della RAM dei nodi di query di origine e di destinazione dopo il bilanciamento del carico è inferiore a quello precedente al bilanciamento del carico.

Se le condizioni di cui sopra sono soddisfatte, il query coord procede a bilanciare il carico della query tra i nodi.

Bilanciamento del carico

Quando viene attivato il bilanciamento del carico, il coordinamentodella query carica prima i segmenti di destinazione sul nodo di query di destinazione. A questo punto, entrambi i nodi di interrogazione restituiscono i risultati di ricerca del/i segmento/i di destinazione a qualsiasi richiesta di ricerca, per garantire la completezza del risultato.

Dopo che il nodo di interrogazione di destinazione ha caricato con successo il segmento di destinazione, il nodo di interrogazione pubblica un sealedSegmentChangeInfo sul Query Channel. Come mostrato di seguito, onlineNodeID e onlineSegmentIDs indicano rispettivamente il nodo di query che carica il segmento e il segmento caricato, mentre offlineNodeID e offlineSegmentIDs indicano rispettivamente il nodo di query che deve rilasciare il segmento e il segmento da rilasciare.

sealedSegmentChangeInfo

Dopo aver ricevuto il messaggio sealedSegmentChangeInfo, il nodo di query di origine rilascia il segmento di destinazione.

Flusso di lavoro del bilanciamento del carico

L'intero processo ha successo quando il nodo di query di origine rilascia il segmento di destinazione. Al termine di questo processo, il carico della query è bilanciato tra i nodi di query, il che significa che l'utilizzo della RAM di tutti i nodi di query non è superiore a queryCoord.overloadedMemoryThresholdPercentage e che il valore assoluto della differenza di utilizzo della RAM dei nodi di query di origine e di destinazione dopo il bilanciamento del carico è inferiore a quello precedente al bilanciamento del carico.

Cosa succederà in seguito?

Nella serie di blog sulle nuove funzionalità 2.0, ci proponiamo di spiegare il design delle nuove funzionalità. Leggete di più in questa serie di blog!

• Come Milvus elimina i dati in streaming in un cluster distribuito
• Come compattare i dati in Milvus?
• Come Milvus bilancia il carico delle query tra i nodi?
• Come Bitset consente la versatilità della ricerca per similarità vettoriale

Questa è la conclusione della serie di blog sulle nuove funzionalità di Milvus 2.0. Dopo questa serie, abbiamo in programma una nuova serie di Milvus Deep Dive, che introdurrà l'architettura di base di Milvus 2.0. Restate sintonizzati.