Architetture di riferimento Milvus
Questo blog affronta alcune domande frequenti sull'allocazione delle risorse di Milvus in base a casi d'uso specifici. Queste domande includono:
Quante risorse CPU e di memoria sono necessarie per Milvus, in base a un numero specifico di utenti o richieste al secondo (RPS)?
Quante risorse CPU e di memoria sono necessarie per Milvus, in base a diversi mix di READ e WRITE?
Comprendere le caratteristiche del carico di lavoro
Il primo passo per allocare risorse a Milvus è comprendere le caratteristiche del carico di lavoro. Questi fattori svolgono un ruolo cruciale nel determinare la potenza di calcolo e i requisiti di memoria di Milvus.
Di seguito è riportato un elenco di esempio di architetture di riferimento basate su pacchetti Linux, dove RPS significa Requests Per Second:
Fino a 20 RPS o 1.000 utenti API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS
Fino a 40 RPS o 2.000 utenti API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS
Fino a 60 RPS o 3.000 utenti API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
Fino a 100 RPS o 5.000 utenti API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS
Fino a 200 RPS o 10.000 utenti API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS
Fino a 500 RPS o 25.000 utenti API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS
Fino a 1000 RPS o 50.000 utenti API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS
Stima dei requisiti delle risorse
Per stimare i requisiti delle risorse per Milvus, dobbiamo fare alcune ipotesi:
Letture: ogni richiesta web e ogni Git pull è un'operazione READ.
Scritture: ogni Git push è considerato un'operazione WRITE.
Volume e rapporto di letture/scritture: si presume che Milvus sia lo stesso del rapporto lettura/scrittura delle chiamate API per numero di utenti.
Query per secondo (QPS): devono corrispondere al requisito API RPS (richieste al secondo) per numero di utenti.
Dobbiamo anche stimare la dimensione dei dati per richiesta di lettura/scrittura. Supporremo un caso d'uso GenAI comune:
Dimensione del vettore: 1024 numeri in virgola mobile
Dimensione in byte per numero in virgola mobile: 4 KB
Top_k (numero di vettori restituiti): 10 vettori per richiesta di ricerca
Dimensione di una collection (tabella di database): 1 milione di vettori per richiesta di scrittura
Tipo di indice del database: HNSW
Sulla base di queste ipotesi, possiamo fare un calcolo approssimativo per stimare la dimensione dei dati per lettura o scrittura. Supponiamo che la dimensione del vettore sia 1024 e che ogni vettore occupi 1024 * 4 byte = 4 KB. Supponiamo un tipico top_k = 10 vettori per lettura. Con queste ipotesi:
Ogni operazione di lettura Milvus elabora circa 40 KB di dati.
Si stima che ogni operazione di scrittura Milvus coinvolga 40 MB di dati.
Milvus offre funzionalità sia di insert (creare una collection completamente nuova) sia di upsert (modificare alcune righe) (Vedi il blog Milvus insert, upsert, delete per maggiori informazioni). Sovrastimeremo ogni operazione WRITE come inserimento di un'intera collection piuttosto che come upsert di poche righe.
I database devono considerare non solo la dimensione dei dati, ma anche la velocità di ricerca e inserimento. Supporremo che la collection sia indicizzata utilizzando il popolare indice HNSW, che ha un tempo di ricerca in notazione Big-O, O(log n).
Con queste ipotesi, ecco la nostra conversione di utenti Web/RPS/letture/scritture in tier di architettura QPS/dimensione dati per Vector Database:
Fino a 1.000 utenti = 20 QPS con 1 milione di vettori
Fino a 2.000 utenti = 40 QPS con 1 milione di vettori
Fino a 3.000 utenti = 60 QPS con 1 milione di vettori
Fino a 5.000 utenti = 100 QPS con 2 milioni di vettori
Fino a 10.000 utenti = 200 QPS con 4 milioni di vettori
Fino a 25.000 utenti = 500 QPS con 10 milioni di vettori
Fino a 50.000 utenti = 1000 QPS con 20 milioni di vettori
Test di carico e benchmarking
Per garantire l’accuratezza delle nostre stime delle risorse, abbiamo eseguito test di carico e benchmarking dei tier di architettura su VectorDBBench. Abbiamo assunto le dimensioni predefinite di Segment, Partition, Shard, Data node, Query node e Index node per la stessa architettura Milvus.
Grazie alle capacità di autoscaling di Milvus, le prestazioni sono lineari rispetto alla dimensione dei dati e alle risorse del cluster! Di seguito è riportata una tabella che mostra le dimensioni delle risorse consigliate per Milvus e Zilliz Cloud (il Milvus completamente gestito) per diverse capacità di dati e requisiti QPS.
La tabella seguente mostra la capacità dei dati in milioni di vettori 1024_dimension. Le risorse Milvus sono indicate in numero di CPU e GB di memoria. Per il confronto dei costi, mostriamo le dimensioni delle risorse Zilliz Cloud, indicate in Compute Units (cu), in tipologie performance o capacity.
Tabella delle dimensioni delle risorse Milvus e Zilliz consigliate per tier Utenti/RPS
| Utenti | Capacità dati | QPS benchmarked | RPS richiesti | Risorsa Milvus | Risorsa Zilliz |
| 3.000 | 1m_1024d vettori | 1200 | 60 | 8CPU, 32G | 1cu-perf |
| 3.000 | 1m_1024d vettori | 2400 | 60 | 16CPU, 64G | 2cu-perf |
| 3.000 | 1m_1024d vettori | 3600 | 60 | 24CPU, 96G | 4cu-perf |
| 10.000 | 3.7m_1024d vettori | 360 | 200 | 16CPU, 64G | 2cu-cap |
| 10.000 | 3.7m_1024d vettori | 700 | 200 | 64CPU, 256G | 4cu-cap |
| 25.000 | 10m_1024d vettori | 600 | 500 | 196CPU, 768G | 12cu- cap |
| 250.000 | 100m_1024d vettori | 6000 | 5000 | 19200CPU, 76800G | 1200cu- cap |
Tabella delle dimensioni delle risorse Milvus e Zilliz consigliate per numero di tier Utenti/RPS. Lo scaling di Milvus è lineare rispetto alla dimensione dei dati e ai QPS richiesti.
Dalla tabella sopra, quando la dimensione dei dati e i QPS devono raggiungere una certa soglia, potrebbe essere più conveniente eseguire Milvus da Zilliz Cloud invece che on-premises.
Conclusione
Comprendendo le caratteristiche del tuo workload, stimando i requisiti delle risorse in base alle ipotesi e sfruttando strumenti di test di carico e benchmarking come VectorDBBench, puoi predisporre con fiducia le risorse necessarie per il tuo deployment Milvus.
Consulta la nostra guida al dimensionamento del cluster per un approfondimento. Ricorda, man mano che il tuo workload evolve, è essenziale rivedere e adeguare regolarmente l’allocazione delle risorse per mantenere prestazioni ottimali.
Riferimenti
HNSW: https://github.com/nmslib/hnswlib/blob/master/ALGO_PARAMS.md
Architettura Milvus: https://docs.gitlab.com/ee/administration/reference_architectures/
Blog Milvus Packaging Dependencies: https://zilliz.com/blog/Milvus-server-docker-installation-and-packaging-dependencies
Blog Milvus Sizing Tool: https://medium.com/@zilliz_learn/demystifying-the-milvus-sizing-tool-2c0afe7fe963
Shard, partizioni, segmenti: https://zilliz.com/blog/sharding-partitioning-segments-get-most-from-your-database
Tipi di CU Zilliz Cloud: https://docs.zilliz.com/docs/cu-types-explained#evaluate-performance
Strumento VectorDBBench per il benchmarking di Milvus, Zilliz Cloud e molte altre maintream vector databases
Continua a leggere
Introducing Functions and Model Inference on Zilliz Cloud: Automatic Embedding and Reranking with Hosted Models
Zilliz Cloud Functions auto-generate embeddings via OpenAI, Voyage AI, Cohere, or Zilliz Hosted Models. Built-in reranking — just insert text and search.
The Real Bottlenecks in Autonomous Driving — And How AI Infrastructure Can Solve Them
Autonomous driving faces a data bottleneck. Learn how AI-native vector databases like Zilliz solve scale, cost, and insight challenges across AV pipelines.
What Exactly Are AI Agents? Why OpenAI and LangChain Are Fighting Over Their Definition?
AI agents are software programs powered by AI that can perceive their environment, make decisions, and take actions to achieve a goal—often autonomously.