Uma Visão Geral do Sistema de Armazenamento do Milvus e Técnicas para Avaliar e Otimizar Seu Desempenho
Bem-vindo à nossa exploração do Milvus, o banco de dados vetorial de código aberto conhecido por sua impressionante escalabilidade horizontal e desempenho ultrarrápido. No núcleo do Milvus está seu robusto sistema de armazenamento, uma base crítica para persistência e armazenamento de dados confiáveis. Esse sistema compreende vários componentes essenciais: meta-armazenamento, agente de logs e armazenamento de objetos.
Este guia se aprofundará na arquitetura do Milvus, detalhará seus principais componentes de armazenamento e explorará técnicas eficazes para avaliar seu desempenho.
Uma Visão Geral da Arquitetura do Milvus
O Milvus adota uma arquitetura distribuída que garante a separação entre armazenamento e computação e oferece suporte à escalabilidade horizontal para seus nós de computação. Essa configuração é organizada em quatro camadas principais: a camada de acesso, o serviço coordenador, os nós de trabalho e o armazenamento, cada uma independentemente escalável e otimizada para recuperação de desastres.
Visão Geral da Arquitetura do Milvus.png
Camada de Acesso: Esta camada front-end consiste em proxies sem estado que lidam com solicitações dos usuários e otimizam respostas, servindo como a principal interface do usuário do sistema.
Camada Coordenadora: Atuando como o comando central do sistema, o serviço coordenador gerencia a distribuição de tarefas, a topologia do cluster, o balanceamento de carga e o gerenciamento de dados entre os nós de trabalho.
Nós de Trabalho: Estes são os executores que processam comandos de Linguagem de Manipulação de Dados (DML) sob a direção do serviço coordenador.
Armazenamento: Fundamental para a persistência de dados, esta camada inclui meta-armazenamento, um agente de logs e armazenamento de objetos, garantindo a integridade e a disponibilidade dos dados.
Componentes de Armazenamento do Milvus
O Milvus usa três componentes principais de armazenamento para garantir a integridade e a disponibilidade dos dados: meta-armazenamento, armazenamento de objetos e um agente de logs.
Meta-armazenamento
O meta-armazenamento no Milvus armazena snapshots de metadados, como esquemas de coleções, status de nós e pontos de verificação de consumo de mensagens. Dada a necessidade de alta disponibilidade, consistência forte e suporte a transações, o Milvus utiliza o etcd como sua solução de meta-armazenamento. Etcd é um armazenamento de chave-valor robusto e distribuído que é crucial para os sistemas distribuídos dentro do Milvus. Ele lida com tarefas como registro de serviços e verificações de integridade, além da preservação de metadados.
Armazenamento de objetos
O armazenamento de objetos no Milvus lida com o armazenamento de arquivos de snapshots de logs, arquivos de índice para dados escalares e vetoriais e resultados intermediários de consultas. O Milvus integra o MinIO para armazenamento de objetos devido ao seu alto desempenho e compatibilidade com Kubernetes, facilitando a operação contínua em ambientes de nuvem como AWS S3 e Azure Blob Storage.
Agente de logs
O agente de logs no Milvus adota um sistema pub-sub com recursos de reprodução. Ele é essencial para a persistência de dados em streaming, execução de consultas assíncronas confiáveis, notificações de eventos e retornos de resultados de consultas. Ele também garante a integridade dos dados incrementais durante a recuperação de nós de trabalho após falhas do sistema. Dependendo da implantação, o Milvus usa diferentes ferramentas de agente de logs. Configurações do Milvus Cluster usam Pulsar ou Kafka, enquanto versões autônomas do Milvus geralmente usam RocksDB.
Como Avaliar e Otimizar o Desempenho do Armazenamento do Milvus
Avaliar e melhorar constantemente o desempenho do armazenamento é crucial.
Etcd: O Armazenamento de Metadados do Milvus
O Etcd é um armazenamento de chave-valor robusto e distribuído projetado para sistemas distribuídos. No Milvus, o etcd é um armazenamento de metadados que armazena dados essenciais, como esquemas de coleções, status de nós e pontos de verificação de consumo de mensagens.
A latência de gravação em disco é crítica para o desempenho do etcd; uma velocidade de disco lenta pode aumentar significativamente a latência das solicitações e colocar em risco a estabilidade do sistema. Recomendamos sustentar pelo menos 500 IOPS sequenciais (operações de entrada/saída por segundo) para desempenho ideal em ambientes de produção, garantindo que 99% das durações de fdatasync permaneçam abaixo de dez milissegundos. Embora o etcd normalmente exija apenas largura de banda de disco moderada, aumentar essa largura de banda pode reduzir consideravelmente os tempos de recuperação. Consequentemente, recomendamos uma largura de banda de disco de referência de pelo menos 100MB/s para ambientes de produção.
Para verificar se sua solução de armazenamento atende a esses critérios, considere realizar avaliações de desempenho usando Fio, uma ferramenta de benchmark de disco. Abaixo está um guia sobre como usar o Fio para avaliar o desempenho do seu armazenamento.
Primeiro, certifique-se de que o Fio esteja instalado no seu sistema. Em seguida, execute o seguinte comando, especificando o diretório onde seu armazenamento está montado como o diretório test-data. Esse diretório deve estar sob o ponto de conexão do seu armazenamento.
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest
Inspecione os resultados para garantir que 99% da duração de fdatasync seja inferior a 10ms e que o IOPS de gravação seja superior a 500. Se essas condições forem atendidas, seu armazenamento tem desempenho adequado.
Abaixo está um exemplo dos resultados de saída:
Jobs: 1 (f=1): [W(1)][100.0%][w=1771KiB/s][w=788 IOPS][eta 00m:00s]
mytest: (groupid=0, jobs=1): err= 0: pid=703: Mon Jul 25 08:36:48 2022
write: IOPS=967, BW=2173KiB/s (2225kB/s)(220MiB/103664msec); 0 zone resets
clat (nsec): min=1903, max=29662k, avg=287307.76, stdev=492386.04
lat (nsec): min=1981, max=29662k, avg=287583.67, stdev=492438.10
clat percentiles (usec):
| 1.00th=[ 3], 5.00th=[ 4], 10.00th=[ 4], 20.00th=[ 5],
| 30.00th=[ 6], 40.00th=[ 9], 50.00th=[ 233], 60.00th=[ 343],
| 70.00th=[ 437], 80.00th=[ 553], 90.00th=[ 701], 95.00th=[ 742],
| 99.00th=[ 1172], 99.50th=[ 2114], 99.90th=[ 6390], 99.95th=[ 8455],
| 99.99th=[15533]
bw ( KiB/s): min= 1630, max= 2484, per=100.00%, avg=2174.66, stdev=193.65, samples=207
iops : min= 726, max= 1106, avg=968.37, stdev=86.19, samples=207
lat (usec) : 2=0.03%, 4=16.49%, 10=27.68%, 20=3.21%, 50=0.71%
lat (usec) : 100=0.27%, 250=2.65%, 500=24.64%, 750=20.40%, 1000=2.57%
lat (msec) : 2=0.82%, 4=0.30%, 10=0.18%, 20=0.03%, 50=0.01%
fsync/fdatasync/sync_file_range:
sync (usec): min=309, max=21848, avg=741.93, stdev=489.64
sync percentiles (usec):
| 1.00th=[ 392], 5.00th=[ 437], 10.00th=[ 474], 20.00th=[ 529],
| 30.00th=[ 578], 40.00th=[ 619], 50.00th=[ 660], 60.00th=[ 709],
| 70.00th=[ 742], 80.00th=[ 791], 90.00th=[ 988], 95.00th=[ 1369],
| 99.00th=[ 2442], 99.50th=[ 3523], 99.90th=[ 6915], 99.95th=[ 8586],
| 99.99th=[11994]
Ao implantar um cluster Milvus em ambientes de nuvem, selecionar o tipo apropriado de armazenamento em bloco para o etcd é crucial devido à sua sensibilidade ao desempenho do disco. Os provedores de nuvem oferecem várias opções de armazenamento em bloco, cada uma com características de desempenho distintas adequadas para diferentes cargas de trabalho.
Abaixo estão os tipos de volume e métricas de desempenho recomendados de vários provedores de nuvem.
| Provedor de nuvem | Tipo de volume | TAMANHO | IOPS | sync P99 |
| AWS | gp3 | 20Gi | 660 | 4.3ms |
| GCP | pd-ssd | 20Gi | 1262 | 1.3ms |
| Azure | PremiumV2 | 20Gi | 705 | 2.6ms |
| Aliyun | cloud_essd | 20Gi | 1137 | 3.5ms |
Você também pode usar o Fio para confirmar que o armazenamento em blocos escolhido atende aos benchmarks de desempenho necessários para o funcionamento ideal do etcd na sua implantação do Milvus.
MinIO: Ferramenta de Armazenamento de Objetos do Milvus
MinIO é uma solução de armazenamento de objetos de alto desempenho, nativa do Kubernetes, otimizada para cargas de trabalho nativas da nuvem. O Milvus utiliza o MinIO para armazenar arquivos de snapshot de logs, arquivos de índice para dados escalares e vetoriais, e resultados intermediários de consultas.
O desempenho de armazenamento de objetos como o MinIO é medido principalmente pela taxa de transferência de E/S, em vez de IOPS. Essa métrica impacta significativamente várias operações no Milvus, como carregar coleções, criar índices e inserir dados. Muitos fatores influenciam o desempenho da taxa de transferência do MinIO, incluindo largura de banda da rede, ajuste de desempenho do kernel Linux e o desempenho de unidades de disco individuais. O desempenho do disco é particularmente crucial.
Podemos usar o comando dd para medir o desempenho de uma única unidade. DD é uma ferramenta Unix que copia dados de um arquivo para outro bit a bit. Ela fornece várias opções para controlar o tamanho do bloco de cada leitura e gravação.
No exemplo abaixo, ao testar uma única unidade NVMe com um tamanho de bloco de 16MB, a opção O_DIRECT para 64 contagens gera um desempenho de gravação superior a 2GB por segundo por unidade.
$ dd if=/dev/zero of=/mnt/drive/test bs=16M count=64 oflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.443096 s, 2.4 GB/s
No mesmo exemplo, ao testar uma única unidade NVMe com um tamanho de bloco de 16MB, a opção O_DIRECT para 64 contagens gera um desempenho de leitura superior a 5GB por segundo por unidade.
$ dd of=/dev/null if=/mnt/drive/test bs=16M count=64 iflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.187263 s, 5.7 GB/s
Quanto maior o desempenho de leitura e gravação da sua unidade de disco, melhor será o desempenho geral da taxa de transferência do MinIO. Recomendamos o uso de unidades do tipo SSD ou NVMe como discos de armazenamento em uma configuração do MinIO para obter resultados ideais. Essas unidades podem oferecer suporte eficaz aos requisitos de alta taxa de transferência das operações do MinIO. Evite usar appliances SAN/NAS para armazenamento do MinIO. Essas configurações frequentemente introduzem problemas de concorrência e gargalos de desempenho que podem degradar a eficiência e a capacidade de resposta do sistema.
Pulsar/Kafka: Ferramentas de Broker de Logs do Milvus
Como mencionado acima, o Milvus usa diferentes ferramentas de broker de logs adaptadas a modos específicos de implantação. Configurações do Milvus Cluster usam Pulsar ou Kafka, enquanto versões autônomas do Milvus normalmente usam RocksDB.
Tanto o Pulsar quanto o Kafka são projetados para oferecer suporte ao armazenamento persistente de mensagens e fornecer alta taxa de transferência para consumidores de mensagens. Seu desempenho depende criticamente do tipo de armazenamento em disco usado, pois eles dependem de operações sequenciais de E/S em disco.
Para o Pulsar, discos de alto desempenho são essenciais para os arquivos de journal do BookKeeper, a fim de garantir a integridade e a durabilidade dos dados, sendo SSDs de baixa latência altamente benéficos para esse propósito. Tanto os Ledgers do Pulsar quanto o Kafka são otimizados para eficiência de disco, utilizando o cache do sistema de arquivos e apresentando bom desempenho com HDDs e SSDs. No entanto, para aplicações sensíveis à latência ou implantações em larga escala, os SSDs oferecem benefícios significativos de desempenho.
Para otimizar o desempenho, use vários dispositivos de disco para o Pulsar e o Kafka. Especificamente, para o Pulsar, usar discos separados para o journal e o armazenamento geral permite que os bookies isolem a latência das operações de gravação das operações de leitura. Para garantir latência ideal, não use as mesmas unidades para armazenar dados, logs de aplicações ou outras atividades do sistema de arquivos do SO. Essas unidades podem ser configuradas como um único volume usando RAID, ou cada unidade pode ser formatada e montada como seu próprio diretório. O armazenamento conectado à rede (NAS) deve ser evitado devido ao seu desempenho mais lento, latências maiores e mais variáveis, e potencial como ponto único de falha.
Resumo
Nossa exploração aprofundada do sistema de armazenamento Milvus oferece insights abrangentes sobre sua arquitetura e seus componentes, destacando seus papéis no suporte ao gerenciamento e à análise de dados em larga escala. Dissecamos os três principais componentes de armazenamento do Milvus—armazenamento de metadados, armazenamento de objetos e corretor de logs—e fornecemos estratégias para avaliar e aprimorar seu desempenho.
Fendy FengFendy Feng is the Technical Marketing Writer at Zilliz. She has extensive experience developing and enhancing the impact of open-source projects in various global markets by producing high-quality, tailored content. Before joining Zilliz, Fendy worked as a Content Strategist at PingCAP, a fast-growing E-Series startup renowned for its open-source distributed SQL database.
Jay ZhuJay Zhu is the Senior Software Engineer and tech leader of the DevOps & Infrastructure team at Zilliz. He specializes in DevOps, cloud-native technologies, and Kubernetes projects. Additionally, Jay is actively involved in developing and maintaining various open-source projects, including Milvus, Milvus-helm, and Milvus-operator.
Continue lendo
My Wife Wanted Dior. I Spent $600 on Claude Code to Vibe-Code a 2M-Line Database Instead.
Write tests, not code reviews. How a test-first workflow with 6 parallel Claude Code sessions turns a 2M-line C++ codebase into a daily shipping pipeline.
How to Install and Run OpenClaw (Previously Clawdbot/Moltbot) on Mac
Turn your Mac into an AI gateway for WhatsApp, Telegram, Discord, iMessage, and more — in under 5 minutes.
Selecting the Right ETL Tools for Unstructured Data to Prepare for AI
Learn the right ETL tools for unstructured data to power AI. Explore key challenges, tool comparisons, and integrations with Milvus for vector search.