Metas de escalabilidade e desempenho para armazenamento de Blob

Esta referência detalha as metas de escalabilidade e desempenho para o Armazenamento do Azure. As metas de escalabilidade e desempenho aqui listadas são de topo de gama, mas são alcançáveis. Em todos os casos, a taxa de pedidos e a largura de banda que a sua conta de armazenamento atinge dependem do tamanho dos objetos armazenados, dos padrões de acesso usados e do tipo de carga de trabalho que a sua aplicação realiza.

Teste o seu serviço para determinar se o seu desempenho corresponde aos seus requisitos. Se possível, evite picos repentinos na taxa de tráfego e garanta que o tráfego seja bem distribuído entre partições.

Quando a sua aplicação atinge o limite do que uma partição pode suportar para a sua carga de trabalho, o Armazenamento do Azure começa a devolver respostas com o código de erro 503 (Servidor Ocupado) ou código de erro 500 (Tempo Limite de Operação). Se ocorrerem erros 503, considere modificar a sua aplicação para utilizar uma política de adiamento exponencial para novas tentativas. O backoff exponencial diminui a carga na partição e atenua os picos de tráfego nessa partição.

Para o acordo de nível de serviço (SLA) para contas Armazenamento do Azure, veja SLA para Contas de Armazenamento.

Dimensionar destinos para armazenamento de Blob

Recurso Objetivo
Tamanho máximo de um único contentor de blob O mesmo que a capacidade máxima da conta de armazenamento
Número máximo de blocos em um blob de bloco ou blob de acréscimo 50.000 blocos
Tamanho máximo de um bloco num bloco de blob 4.000 MiB
Tamanho máximo de um blob de bloco 50.000 x 4.000 MiB (aproximadamente 190,7 TiB)
Tamanho máximo de um bloco em um blob de acréscimo 4 MiB
Tamanho máximo de um blob de acréscimo 50.000 x 4 MiB (aproximadamente 195 GiB)
Tamanho máximo de um blob de página 8TiB 2
Número máximo de políticas de acesso armazenadas por contêiner de blob 5
Taxa de requisição alvo para um único blob de bloco Até 3.000 pedidos por segundo
Taxa de pedidos alvo para um blob de uma única página Até 500 pedidos por segundo
Taxa de transferência de destino para um blob de página única Até 60 MiB por segundo2
Taxa alvo de transferência para um único blob de blocos Até limites de entrada/saída da conta de armazenamento1

1 A taxa de transferência para um único blob depende de vários fatores. Estes fatores incluem, mas não se limitam a, concorrência, tamanho do pedido, nível de desempenho, velocidade de origem para uploads e destino para downloads. Para tirar partido das melhorias de desempenho dos blobs de bloco de alta capacidade, carregue blobs ou blocos maiores. Especificamente, execute a operação Put Blob ou a operação Put Block com um tamanho de blob ou bloco superior a 256 KiB.

2 Os blobs de página ainda não são suportados em contas com um namespace hierárquico habilitado.

A tabela a seguir descreve os tamanhos máximos de bloco e blob permitidos pela versão do serviço.

Versão do serviço Tamanho máximo do bloco (via Put Block) Tamanho máximo do blob (via Put Block List) Tamanho máximo de blob através de uma única operação de escrita (via Put Blob)
Versão 2019-12-12 e posterior 4.000 MiB Aproximadamente 190,7 TiB (4.000 MiB x 50.000 blocos) 5.000 MiB
Versão 2016-05-31 até versão 2019-07-07 100 MiB Aproximadamente 4,75 TiB (100 MiB x 50.000 blocos) 256 MiB
Versões anteriores a 2016-05-31 4 MiB Aproximadamente 195 GiB (4 MiB x 50.000 blocos) 64 MiB

Partições quentes: deteção, monitorização e mitigação

Armazenamento de Blobs do Azure distribui dados e pedidos entre partições para ajudar a escalar cargas de trabalho. Uma conta de armazenamento pode ter capacidade e rendimento disponíveis, enquanto cargas de trabalho que concentram tráfego num intervalo restrito de chaves de partição enfrentam restrições de throughput ao nível de partição.

Quando uma única partição recebe significativamente mais tráfego do que outras partições, torna-se uma partição quente. A chave de partição para um blob combina o nome da conta de armazenamento, nome do contentor e nome do blob, pelo que esquemas de nomes sequenciais ou apenas adicionáveis podem concentrar o tráfego numa única partição.

Quando uma partição se torna quente, a sua aplicação pode observar um aumento da latência e receber respostas HTTP 503 (Server Busy) ou HTTP 500 (Operation Timeout) antes de a conta de armazenamento se aproximar dos limites de escalabilidade documentados.

Para mitigar partições quentes:

  • Evite esquemas de nomenclatura de blob sequenciais ou apenas com acréscimos que concentrem o tráfego numa única partição.

  • Utilize uma estratégia de retentativa de recuo exponencial quando ocorrerem erros de limitação.

  • Aumenta gradualmente as taxas de pedidos quando introduzires novas cargas de trabalho.

Para detetar throttling e identificar a origem da procura excessiva, utilize métricas e registos de recursos do Azure Monitor.

Para mais informações, veja Mitigar partições quentes no Armazenamento de Blobs do Azure.

Ver também