Panoramica dell'architettura distribuita

Milvus mira a realizzare una ricerca di similarità e un'analisi efficienti per vettori di dimensioni enormi. Un'istanza indipendente di Milvus può facilmente gestire la ricerca vettoriale per vettori di dimensioni miliardarie. Tuttavia, per set di dati da 10 miliardi, 100 miliardi o addirittura più grandi, è necessario un cluster Milvus. Il cluster può essere utilizzato come istanza indipendente per le applicazioni di livello superiore e può soddisfare le esigenze aziendali di bassa latenza e alta concorrenza per i dati su larga scala. Un cluster Milvus può reinviare le richieste, separare la lettura dalla scrittura, scalare orizzontalmente ed espandersi dinamicamente, fornendo così un'istanza Milvus che può espandersi senza limiti. Mishards è una soluzione distribuita per Milvus.

Questo articolo presenterà brevemente i componenti dell'architettura di Mishards. Informazioni più dettagliate saranno introdotte nei prossimi articoli.

1-milvus-cluster-mishards.png

Panoramica dell'architettura distribuita

2-architettura distribuita-overview.png

Tracciamento dei servizi

3-service-tracing-milvus.png

Componenti primari del servizio

• Framework di rilevamento dei servizi, come ZooKeeper, etcd e Consul.
• Bilanciatore di carico, come Nginx, HAProxy, Ingress Controller.
• Nodo Mishards: stateless, scalabile.
• Nodo Milvus di sola scrittura: nodo singolo e non scalabile. È necessario utilizzare soluzioni ad alta disponibilità per questo nodo per evitare il single-point-of-failure.
• Nodo Milvus di sola lettura: Nodo statico e scalabile.
• Servizio di storage condiviso: Tutti i nodi Milvus utilizzano un servizio di archiviazione condiviso per condividere i dati, come NAS o NFS.
• Servizio di metadati: Tutti i nodi Milvus utilizzano questo servizio per condividere i metadati. Attualmente è supportato solo MySQL. Questo servizio richiede una soluzione ad alta disponibilità per MySQL.

Componenti scalabili

• Mishard
• Nodi Milvus di sola lettura

Introduzione ai componenti

Nodi Mishards

Mishards è responsabile della suddivisione delle richieste a monte e dell'instradamento delle sotto-richieste ai sottoservizi. I risultati vengono riassunti per tornare all'upstream.

4-nodi-mishards.jpg

Come indicato nel grafico qui sopra, dopo aver accettato una richiesta di ricerca TopK, Mishards prima scompone la richiesta in sotto-richieste e invia le sotto-richieste al servizio a valle. Quando tutte le sotto-richieste sono state raccolte, le sotto-richieste vengono unite e restituite a monte.

Poiché Mishards è un servizio stateless, non salva dati né partecipa a calcoli complessi. Pertanto, i nodi non hanno requisiti di configurazione elevati e la potenza di calcolo viene utilizzata principalmente per unire i risultati secondari. Pertanto, è possibile aumentare il numero di nodi Mishards per ottenere un'elevata concurrency.

Nodi Milvus

I nodi Milvus sono responsabili delle operazioni di base relative al CRUD, quindi hanno requisiti di configurazione relativamente elevati. In primo luogo, la dimensione della memoria deve essere sufficientemente grande per evitare un numero eccessivo di operazioni di IO su disco. In secondo luogo, anche la configurazione della CPU può influire sulle prestazioni. All'aumentare delle dimensioni del cluster, sono necessari più nodi Milvus per aumentare il throughput del sistema.

Nodi di sola lettura e nodi scrivibili

• Le operazioni principali di Milvus sono l'inserimento e la ricerca di vettori. La ricerca ha requisiti estremamente elevati per le configurazioni di CPU e GPU, mentre l'inserimento o altre operazioni hanno requisiti relativamente bassi. La separazione del nodo che esegue la ricerca da quello che esegue le altre operazioni consente un'implementazione più economica.
• In termini di qualità del servizio, quando un nodo esegue operazioni di ricerca, l'hardware correlato funziona a pieno carico e non può garantire la qualità del servizio delle altre operazioni. Pertanto, vengono utilizzati due tipi di nodi. Le richieste di ricerca sono elaborate da nodi di sola lettura e le altre richieste sono elaborate da nodi scrivibili.

È consentito un solo nodo scrivibile

• Attualmente, Milvus non supporta la condivisione dei dati per più istanze scrivibili.

• Durante l'implementazione, è necessario considerare un singolo punto di guasto dei nodi scrivibili. È necessario preparare soluzioni ad alta disponibilità per i nodi scrivibili.

Scalabilità dei nodi di sola lettura

Quando le dimensioni dei dati sono estremamente grandi o i requisiti di latenza sono estremamente elevati, è possibile scalare orizzontalmente i nodi di sola lettura come nodi stateful. Si supponga che ci siano 4 host e che ognuno abbia la seguente configurazione: Core CPU: 16, GPU: 1, memoria: 64 GB. Il grafico seguente mostra il cluster quando si scalano orizzontalmente i nodi stateful. Sia la potenza di calcolo che la memoria scalano linearmente. I dati sono suddivisi in 8 shard e ogni nodo elabora le richieste da 2 shard.

5-read-only-node-scalability-milvus.png

Quando il numero di richieste è elevato per alcuni shard, è possibile distribuire nodi di sola lettura stateless per questi shard per aumentare il throughput. Prendiamo come esempio gli host di cui sopra. Quando gli host vengono combinati in un cluster serverless, la potenza di calcolo aumenta linearmente. Poiché i dati da elaborare non aumentano, anche la potenza di elaborazione per lo stesso shard di dati aumenta linearmente.

6-read-only-node-scalability-milvus-2.png

Servizio di metadati

Parole chiave: MySQL

Per ulteriori informazioni sui metadati di Milvus, consultare la sezione Come visualizzare i metadati. In un sistema distribuito, i nodi scrivibili Milvus sono gli unici produttori di metadati. I nodi Mishard, i nodi scrivibili Milvus e i nodi di sola lettura Milvus sono tutti consumatori di metadati. Attualmente, Milvus supporta solo MySQL e SQLite come backend di archiviazione dei metadati. In un sistema distribuito, il servizio può essere distribuito solo come MySQL ad alta disponibilità.

Scoperta del servizio

Parole chiave: Apache Zookeeper, etcd, Consul, Kubernetes

7-scoperta dei servizi.png

La scoperta dei servizi fornisce informazioni su tutti i nodi Milvus. I nodi Milvus registrano le loro informazioni quando vanno online e si disconnettono quando vanno offline. I nodi Milvus possono anche rilevare nodi anomali controllando periodicamente lo stato di salute dei servizi.

La scoperta dei servizi contiene molti framework, tra cui etcd, Consul, ZooKeeper, ecc. Mishards definisce le interfacce per il rilevamento dei servizi e offre la possibilità di scalare i servizi tramite plugin. Attualmente, Mishards fornisce due tipi di plugin, che corrispondono al cluster Kubernetes e alle configurazioni statiche. È possibile personalizzare il proprio service discovery seguendo l'implementazione di questi plugin. Le interfacce sono temporanee e necessitano di una riprogettazione. Maggiori informazioni sulla scrittura di un proprio plugin saranno elaborate nei prossimi articoli.

Bilanciamento del carico e sharding dei servizi

Parole chiave: Nginx, HAProxy, Kubernetes

7-load-balancing-e-service-sharding.png

Il rilevamento dei servizi e il bilanciamento del carico vengono utilizzati insieme. Il bilanciamento del carico può essere configurato come polling, hashing o hashing coerente.

Il bilanciatore di carico è responsabile del reinvio delle richieste degli utenti al nodo Mishards.

Ogni nodo Mishards acquisisce le informazioni di tutti i nodi Milvus a valle tramite il centro di scoperta dei servizi. Tutti i metadati relativi possono essere acquisiti dal servizio metadati. Mishards implementa lo sharding consumando queste risorse. Mishards definisce le interfacce relative alle strategie di routing e fornisce estensioni tramite plugin. Attualmente, Mishards fornisce una strategia di hashing coerente basata sul livello di segmento più basso. Come mostrato nel grafico, ci sono 10 segmenti, da s1 a s10. In base alla strategia di hashing coerente basata sui segmenti, Mishards instrada le richieste relative a s1, 24, s6 e s9 al nodo Milvus 1, a s2, s3, s5 al nodo Milvus 2 e a s7, s8, s10 al nodo Milvus 3.

In base alle esigenze aziendali, è possibile personalizzare l'instradamento seguendo il plugin predefinito di instradamento con hashing coerente.

Tracciamento

Parole chiave: OpenTracing, Jaeger, Zipkin

Data la complessità di un sistema distribuito, le richieste vengono inviate a più invocazioni di servizi interni. Per individuare i problemi, è necessario tracciare la catena di invocazione dei servizi interni. Con l'aumentare della complessità, i vantaggi di un sistema di tracciamento disponibile sono evidenti. Abbiamo scelto lo standard OpenTracing di CNCF. OpenTracing fornisce API indipendenti dalla piattaforma e dal fornitore per consentire agli sviluppatori di implementare comodamente un sistema di tracciamento.

8-tracing-demo-milvus.png

Il grafico precedente è un esempio di tracciamento durante l'invocazione della ricerca. La ricerca invoca consecutivamente get_routing, do_search e do_merge. do_search invoca anche search_127.0.0.1.

L'intero record di tracciamento forma il seguente albero:

8-search-traceid-milvus.png

Il grafico seguente mostra esempi di informazioni su richiesta/risposta e tag di ogni nodo:

request-response-info-tags-node-milvus.png

OpenTracing è stato integrato in Milvus. Ulteriori informazioni saranno trattate nei prossimi articoli.

Monitoraggio e avvisi

Parole chiave: Prometheus, Grafana

10-monitoraggio-allarme-milvus.jpg

Sintesi

Come middleware di servizio, Mishards integra la scoperta dei servizi, l'instradamento delle richieste, l'unione dei risultati e il tracciamento. È prevista anche un'espansione basata su plugin. Attualmente, le soluzioni distribuite basate su Mishards presentano ancora i seguenti inconvenienti:

• Mishards utilizza il proxy come livello intermedio e ha costi di latenza.
• I nodi scrivibili di Milvus sono servizi a punto singolo.
• Dipende dal servizio MySQL altamente disponibile. -La distribuzione è complicata quando ci sono più shard e un singolo shard ha più copie.
• Manca un livello di cache, come l'accesso ai metadati.

Risolveremo questi problemi nelle prossime versioni, in modo che Mishard possa essere applicato all'ambiente di produzione in modo più pratico.