IOPS x Throughput: como escolher as métricas de desempenho certas para o seu banco de dados

By Mirko Peters · 2026-08-11 · Updated 2026-08-26

Quando arquitetos e administradores de banco de dados começam a projetar uma infraestrutura de alto desempenho para cargas de trabalho pesadas, como o SQL Server, costumam se deparar com uma enxurrada de siglas técnicas e especificações de armazenamento. Entre as métricas mais críticas, e ao mesmo tempo mais mal compreendidas, estão IOPS e throughput. Escolher a métrica errada ao provisionar seu a

Automatically translated with AI from the original post. Read the English original

Quando arquitetos e administradores de banco de dados começam a projetar uma infraestrutura de alto desempenho para cargas de trabalho pesadas, como o SQL Server, costumam se deparar com uma enxurrada de siglas técnicas e especificações de armazenamento. Entre as métricas mais críticas, e ao mesmo tempo mais mal compreendidas, estão IOPS e throughput. Escolher a métrica errada ao provisionar seu armazenamento pode levar a consultas lentas, sistemas com gargalos e orçamento desperdiçado. Entender como seu banco de dados realmente lê e grava dados é o primeiro passo para construir uma arquitetura resiliente.

Neste post, vamos detalhar as diferenças fundamentais entre IOPS e throughput, analisar como elas se aplicam a cargas de trabalho intensivas de banco de dados, observar gargalos arquiteturais comuns, como os limites das máquinas virtuais, e explorar como os modelos de armazenamento compartilhado mudam o jogo para ambientes modernos de nuvem.

Introdução às métricas de desempenho de banco de dados

Desempenho de armazenamento não é uma medida única para todos os casos. Quando você analisa armazenamento em nuvem ou hardware SAN tradicional, os fornecedores costumam apresentar números impressionantes sobre a velocidade com que os dados podem se movimentar e quantas operações um disco consegue processar. No entanto, um mecanismo de banco de dados se comporta de forma completamente diferente de um serviço de streaming de vídeo ou de um grande servidor de arquivos. Enquanto um servidor de vídeo precisa enviar grandes fluxos contínuos de dados por um canal, um banco de dados passa o tempo buscando linhas específicas, atualizando logs de transações e armazenando páginas em cache na memória.

Para projetar um ambiente que não sucumba sob pressão, primeiro é preciso entender as características distintas das suas cargas de trabalho. Isso começa com uma análise aprofundada dos dois pilares do desempenho de armazenamento: Input/Output Operations Per Second (IOPS) e Megabytes por segundo (Throughput).

Definindo IOPS: por que os bancos de dados dependem de leituras e gravações pequenas

IOPS significa Input and Output Operations Per Second (operações de entrada e saída por segundo). É uma medida de quantas solicitações individuais de armazenamento um dispositivo consegue atender em um único segundo. Para plataformas de banco de dados intensivas, como o SQL Server, o IOPS costuma ser a métrica mais importante.

Bancos de dados são transacionais por natureza. Quando um usuário faz login em uma aplicação, o banco de dados normalmente não lê nem grava de uma vez um arquivo enorme, de vários gigabytes. Em vez disso, executa milhares de operações pequenas e direcionadas. Ele pode ler uma página de dados de 8 KB para buscar o perfil de um usuário, gravar algumas centenas de bytes em um log de transações ou atualizar um índice. Como essas operações são muito pequenas, a capacidade do subsistema de armazenamento de processar um grande volume de comandos individuais, ou seja, sua capacidade de IOPS, torna-se o principal fator de desempenho. Se o seu banco de dados precisa de 10.000 IOPS para acompanhar as transações dos usuários, mas o disco de armazenamento entrega apenas 3.000, as consultas vão entrar em fila, os bloqueios vão se acumular em cascata e os tempos de resposta da aplicação vão despencar.

Definindo throughput: quando a largura de banda importa mais

Enquanto o IOPS mede a *quantidade* de operações, o throughput mede o *volume* de dados movimentados em um determinado período, normalmente expresso em megabytes por segundo (MB/s). Pense no IOPS como o número de carros trafegando por uma rodovia, e no throughput como o peso total da carga que eles transportam.

Há cenários em que o throughput importa muito mais do que o IOPS. Considere uma rotina noturna de backup do banco de dados, uma grande importação para um data warehouse ou consultas analíticas que varrem milhões de linhas de uma tabela. Essas tarefas não se preocupam tanto com quantas solicitações individuais são processadas por segundo; o que importa é a velocidade com que um fluxo contínuo de dados volumosos pode ser ingerido ou exportado. Se você tentar executar uma migração de dados de grande porte em um armazenamento com alto IOPS, mas com limites baixos de throughput, perceberá que a migração levará horas a mais do que o previsto, porque o canal de dados simplesmente não é largo o suficiente.

Mapeando cargas de trabalho de aplicações para configurações de armazenamento

Cada aplicação da sua empresa tem um perfil de armazenamento único. Arquitetar com sucesso o seu ambiente significa mapear esses padrões específicos de leitura e gravação para a configuração de armazenamento adequada. Por exemplo, um banco de dados de processamento de transações (OLTP) exige capacidade alta de IOPS para atender solicitações simultâneas de usuários sem picos de latência. Por outro lado, um data lake ou um servidor de relatórios pode precisar de throughput elevado para processar consultas analíticas.

O desafio surge quando um ambiente hospeda várias cargas de trabalho com padrões conflitantes. Um banco de dados SQL pode atingir o pico durante o fechamento financeiro de fim de mês, um servidor de relatórios pode ter um aumento de demanda todas as manhãs às 8:00, e um sistema de backup pode sobrecarregar a rede com tráfego durante a noite. Historicamente, os administradores provisionavam discos separados para cada um desses picos, o que levava a um superdimensionamento enorme e a recursos ociosos.

O gargalo da máquina virtual: além dos discos

Mesmo que você calcule com todo cuidado os requisitos de IOPS e de throughput do seu banco de dados e provisione os discos mais rápidos disponíveis, você ainda pode esbarrar em limites graves de desempenho. O problema muitas vezes não está no meio de armazenamento em si, mas na máquina virtual à qual ele está conectado.

As máquinas virtuais do Azure, por exemplo, impõem limites rígidos de IOPS e throughput total de disco, dependendo do tamanho e do nível da VM selecionada. Você pode conectar discos de alto desempenho, de nível empresarial, a um tamanho modesto de máquina virtual, mas a VM vai limitar o tráfego de armazenamento ao seu próprio máximo. O sistema de armazenamento pode ser capaz de entregar 20.000 IOPS, mas se o caminho da máquina virtual restringir você a 10.000 IOPS, esse é o seu teto. Sempre audite tanto as especificações dos seus discos quanto o dimensionamento de computação, para garantir que o caminho entre eles seja largo o suficiente para suportar suas cargas de pico.

Como os pools de armazenamento compartilhado mudam o planejamento de desempenho

Para quebrar o ciclo de provisionar discos isolados e superdimensionados para cada carga de trabalho individual, as arquiteturas modernas de nuvem recorrem a pools de armazenamento compartilhado, semelhantes às tradicionais Storage Area Networks (SANs). Em vez de prender o desempenho em contêineres separados e rígidos, um modelo compartilhado agrupa capacidade e IOPS em conjunto.

Em ambientes que usam recursos agrupados, as métricas de desempenho crescem com a capacidade. Por exemplo, no Azure Elastic SAN, cada 1 TiB de capacidade base contribui com uma quantidade específica de desempenho — como 5.000 IOPS e 200 MB por segundo de throughput — para um pool central. Esse pool compartilhado permite que diferentes volumes utilizem um orçamento de desempenho comum. Se o seu banco de dados financeiro precisar de um aumento de IOPS durante um ciclo intenso de relatórios enquanto o seu sistema de data warehouse está ocioso, esses recursos podem se ajustar dinamicamente para dar suporte à carga de trabalho ativa.

Evitando pontos de atrito: equilibrando demandas de pico e limites compartilhados

Embora os pools de armazenamento compartilhado ofereçam flexibilidade e economia impressionantes, eles não são uma solução milagrosa para desempenho ilimitado. Agrupar recursos significa apostar na probabilidade estatística de que nem todos os bancos de dados atinjam o pico absoluto de demanda exatamente no mesmo instante.

Se várias cargas de trabalho intensivas atingirem o pico simultaneamente e a demanda combinada ultrapassar os limites do pool compartilhado, ocorrerá throttling. O throttling introduz latência, deixa as consultas mais lentas e pode provocar timeouts em cascata nas aplicações. Administradores de banco de dados e arquitetos de infraestrutura precisam analisar cuidadosamente as métricas históricas, entender o seu uso simultâneo de pico e garantir que o pool de armazenamento compartilhado seja dimensionado com folga suficiente para absorver picos sobrepostos sem perder o ritmo.

Conclusão: escolhendo as métricas certas para o seu banco de dados

Dominar o equilíbrio entre IOPS e throughput é essencial para quem gerencia cargas de trabalho intensivas de banco de dados na nuvem. Ao diagnosticar com precisão se as suas aplicações estão limitadas por operações pequenas e rápidas ou por grande largura de banda de dados, você evita gargalos de desempenho custosos. Além disso, adotar paradigmas modernos de armazenamento, como os pools compartilhados, pode melhorar significativamente a eficiência, garantindo que a sua infraestrutura escale de forma inteligente com o crescimento do negócio. Para entender a fundo como as arquiteturas modernas de armazenamento em nuvem resolvem esses desafios de escala e desempenho, não deixe de conferir o episódio de podcast relacionado: Azure Elastic SAN — Simply Explained.