Arquiteturas de referência do Milvus
Este blog aborda algumas perguntas frequentes sobre a alocação de recursos do Milvus com base em casos de uso específicos. Essas perguntas incluem:
Quantos recursos de CPU e memória são necessários para o Milvus, com base em um número específico de usuários ou solicitações por segundo (RPS)?
Quantos recursos de CPU e memória são necessários para o Milvus, com base em diferentes combinações de LEITURA e ESCRITA?
Entendendo as Características da Sua Carga de Trabalho
O primeiro passo na alocação de recursos para o Milvus é entender as características da sua carga de trabalho. Esses fatores desempenham um papel crucial na determinação dos requisitos de poder computacional e memória do Milvus.
Abaixo está uma lista de exemplos de arquiteturas de referência baseadas em pacotes Linux, em que RPS significa Solicitações Por Segundo:
Até 20 RPS ou 1.000 usuários API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS
Até 40 RPS ou 2.000 usuários API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS
Até 60 RPS ou 3.000 usuários API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
Até 100 RPS ou 5.000 usuários API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS
Até 200 RPS ou 10.000 usuários API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS
Até 500 RPS ou 25.000 usuários API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS
Até 1000 RPS ou 50.000 usuários API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS
Estimando os Requisitos de Recursos
Para estimar os requisitos de recursos para o Milvus, precisamos fazer algumas suposições:
Leituras: Cada solicitação web e pull do Git é uma operação de LEITURA.
Escritas: Cada push do Git é considerado uma operação de ESCRITA.
Volume e proporção de leituras/escritas: presume-se que o Milvus seja igual à proporção de leitura/escrita das chamadas de API por número de usuários.
Consultas por segundo (QPS): devem corresponder ao requisito de RPS da API (solicitações por segundo) por número de usuários.
Também precisamos estimar o tamanho dos dados por solicitação de leitura/escrita. Vamos assumir um caso de uso comum de GenAI:
Dimensão do vetor: 1024 números de ponto flutuante
Tamanho em bytes por número de ponto flutuante: 4 KB
Top_k (número de vetores retornados): 10 vetores por solicitação de busca
Tamanho de uma coleção (tabela de banco de dados): 1 milhão de vetores por solicitação de escrita
Tipo de índice do banco de dados: HNSW
Com base nessas suposições, podemos fazer uma conta aproximada para estimar o tamanho dos dados por leitura ou escrita. Suponha que a dimensão do vetor seja 1024, e cada vetor ocupe 1024 * 4 bytes = 4 KB. Suponha um top_k típico = 10 vetores por leitura. Com essas suposições:
Cada operação de leitura do Milvus processa cerca de 40 KB de dados.
Estima-se que cada operação de escrita do Milvus envolva 40 MB de dados.
O Milvus oferece funcionalidades de insert (criar uma coleção inteiramente nova) e upsert (modificar algumas linhas) (Veja o blog Milvus insert, upsert, delete para mais informações). Vamos superestimar cada operação de ESCRITA como sendo uma inserção de coleção inteira, em vez de apenas upserts de algumas linhas.
Os bancos de dados precisam considerar não apenas o tamanho dos dados, mas também a velocidade de busca e inserção. Vamos assumir que a coleção é indexada usando o popular índice HNSW, que tem tempo de busca em notação Big-O, O(log n).
Com essas premissas, aqui está nossa conversão de usuários/RPS/leituras/gravações baseados na Web para níveis de arquitetura de QPS/tamanho de dados de Banco de Dados Vetorial:
Até 1.000 usuários = 20 QPS com 1 milhão de vetores
Até 2.000 usuários = 40 QPS com 1 milhão de vetores
Até 3.000 usuários = 60 QPS com 1 milhão de vetores
Até 5.000 usuários = 100 QPS com 2 milhões de vetores
Até 10.000 usuários = 200 QPS com 4 milhões de vetores
Até 25.000 usuários = 500 QPS com 10 milhões de vetores
Até 50.000 usuários = 1000 QPS com 20 milhões de vetores
Teste de Carga e Benchmarking
Para garantir a precisão de nossas estimativas de recursos, realizamos testes de carga e benchmarking dos níveis de arquitetura no VectorDBBench. Assumimos os tamanhos padrão de Segment, Partition, Shard, Data node, Query node e Index node para a própria arquitetura do Milvus.
Devido aos recursos de autoscaling do Milvus, o desempenho é linear com o tamanho dos dados e os recursos do cluster! Abaixo está uma tabela mostrando os tamanhos de recursos recomendados do Milvus e do Zilliz Cloud (o Milvus totalmente gerenciado) para diferentes capacidades de dados e requisitos de QPS.
A tabela abaixo mostra a capacidade de dados em milhões de vetores de 1024_dimensões. Os recursos do Milvus são fornecidos em várias CPUs e GB de memória. Para comparação de custos, mostramos os tamanhos de recursos do Zilliz Cloud, fornecidos em Compute Units (cu), em tipos de desempenho ou capacidade.
Tabela de tamanhos de recursos recomendados do Milvus e Zilliz por níveis de Usuários/RPS
| Usuários | Capacidade de dados | QPS em benchmark | RPS necessário | Recurso do Milvus | Recurso do Zilliz |
| 3.000 | 1m_1024d vetores | 1200 | 60 | 8CPU, 32G | 1cu-perf |
| 3.000 | 1m_1024d vetores | 2400 | 60 | 16CPU, 64G | 2cu-perf |
| 3.000 | 1m_1024d vetores | 3600 | 60 | 24CPU, 96G | 4cu-perf |
| 10.000 | 3.7m_1024d vetores | 360 | 200 | 16CPU, 64G | 2cu-cap |
| 10.000 | 3.7m_1024d vetores | 700 | 200 | 64CPU, 256G | 4cu-cap |
| 25.000 | 10m_1024d vetores | 600 | 500 | 196CPU, 768G | 12cu- cap |
| 250.000 | 100m_1024d vetores | 6000 | 5000 | 19200CPU, 76800G | 1200cu- cap |
Tabela de tamanhos de recursos recomendados do Milvus e Zilliz por número de níveis de Usuários/RPS. O dimensionamento do Milvus é linear em relação ao tamanho dos dados e ao QPS necessário.
A partir da tabela acima, quando o tamanho dos dados e o QPS precisam atingir um determinado limite, pode ser mais econômico executar o Milvus a partir do Zilliz Cloud em vez de on-premises.
Conclusão
Ao entender as características da sua carga de trabalho, estimar os requisitos de recursos com base em premissas e aproveitar ferramentas de teste de carga e benchmarking, como o VectorDBBench, você pode provisionar com confiança os recursos necessários para sua implantação do Milvus.
Consulte nosso guia de dimensionamento de cluster para uma análise mais aprofundada. Lembre-se: à medida que sua carga de trabalho evolui, é essencial revisar e ajustar regularmente sua alocação de recursos para manter o desempenho máximo.
Referências
HNSW: https://github.com/nmslib/hnswlib/blob/master/ALGO_PARAMS.md
Arquitetura do 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
Shards, Partições, Segmentos: https://zilliz.com/blog/sharding-partitioning-segments-get-most-from-your-database
Tipos de CU do Zilliz Cloud: https://docs.zilliz.com/docs/cu-types-explained#evaluate-performance
Ferramenta VectorDBBench para benchmarking do Milvus, Zilliz Cloud e muitos outros bancos de dados vetoriais principais
Continue lendo
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.
Vector Databases vs. Graph Databases
Use a vector database for AI-powered similarity search; use a graph database for complex relationship-based queries and network analysis.