Lista de verificação de desempenho e escalabilidade do Armazenamento de Blobs
A Microsoft elaborou várias práticas comprovadas para desenvolver aplicativos de alto desempenho usando o Armazenamento de Blobs. Essa lista de verificação identifica as principais práticas que os desenvolvedores podem seguir para otimizar o desempenho. Tenha essas práticas em mente enquanto estiver projetando seu aplicativo e durante todo o processo.
O Armazenamento do Azure tem metas de escalabilidade e desempenho para capacidade, taxa de transação e largura de banda. Para saber mais sobre as metas de escalabilidade do Armazenamento do Microsoft Azure, confira Metas de escalabilidade e desempenho para contas de armazenamento Standard e Metas de escalabilidade e desempenho para Armazenamento de Blobs.
Lista de verificação
Este artigo organiza as práticas comprovadas de desempenho em uma lista de verificação, a serem seguidas durante o desenvolvimento do aplicativo do Armazenamento de Blobs.
Metas de escalabilidade
Se o seu aplicativo se aproximar ou ultrapassar alguma das metas de escalabilidade, pode haver aumento da latência e restrição das transações. Quando o Armazenamento do Azure limita seu aplicativo, o serviço começa a retornar os códigos de erro 503 (Servidor ocupado) ou 500 (Tempo limite da operação). Evitar esses erros mantendo-se dentro dos limites dos destinos de escalabilidade é uma parte importante do aprimoramento do desempenho do seu aplicativo.
Para obter mais informações sobre metas de escalabilidade para o serviço Fila, confira Metas de escalabilidade e desempenho do Armazenamento do Azure.
Número máximo de contas de armazenamento
Se você estiver se aproximando do número máximo de contas de armazenamento permitidas para uma combinação específica de assinatura/região, avalie seu cenário e determine se alguma das condições a seguir se aplica:
- Você está usando contas de armazenamento para armazenar discos não gerenciados e adicionando esses discos às suas VMs (máquinas virtuais)? Para este cenário, a Microsoft recomenda o uso de discos gerenciados. O Managed Disks dimensionam automaticamente e sem a necessidade de criar e gerenciar contas de armazenamento individuais. Para saber mais, confira Introdução ao Managed Disks do Azure
- Você está usando uma conta de armazenamento por cliente, para fins de isolamento de dados? Para este cenário, a Microsoft recomenda usar um contêiner de blobs para cada cliente, em vez de uma conta inteira de armazenamento. O Armazenamento do Microsoft Azure agora permite que você atribua funções do Azure por contêiner. Para saber mais, consulte Atribuir uma função do Azure para acesso a dados de blob.
- Você está usando várias contas de armazenamento para fragmentar, com a intenção de aumentar a entrada, a saída, as operações de E/S por segundo (IOPS) ou a capacidade? Nesse cenário, a Microsoft recomenda que você use maiores limites para contas de armazenamento a fim de reduzir o número de contas de armazenamento necessárias para sua carga de trabalho, se possível. Entre em contato com o Suporte do Azure para solicitar maiores limites para sua conta de armazenamento.
Metas de capacidade e de transação
Se seu aplicativo estiver lidando com metas de escalabilidade de uma única conta de armazenamento, você pode adotar uma destas abordagens:
- Se o seu aplicativo atingir a meta da transação, considere o uso de contas de armazenamento de blob de blocos, que são otimizadas para altas taxas de transação e latência baixa e consistente. Para saber mais, confira Visão geral da conta de armazenamento do Azure.
- Repensar a carga de trabalho que faz com que o aplicativo se aproxime da meta de escalabilidade ou a ultrapasse. Você pode alterar o aplicativo para que ele use menos largura de banda, menos capacidade ou menos transações?
- Se o aplicativo ultrapassar uma das metas de escalabilidade propositalmente, crie diversas contas de armazenamento e particione os dados do seu aplicativo nessas contas. Se você usar esse padrão, crie o aplicativo de forma que seja possível adicionar mais contas de armazenamento posteriormente, para balancear a carga. O único custo das contas de armazenamento é o uso dos dados armazenados, das transações feitas ou dos dados transferidos.
- Se o aplicativo estiver atingindo as metas de largura de banda, considere compactar os dados no cliente para reduzir a largura de banda necessária para enviar os dados para o Armazenamento do Azure. Embora a compactação de dados possa economizar largura de banda e melhorar o desempenho de rede, ela também pode ter efeitos negativos sobre o desempenho. Avalie o impacto de desempenho dos requisitos de processamento adicionais para compactação e descompactação de dados no lado do cliente. Tenha em mente que armazenar dados compactados pode dificultar a solução de problemas, porque pode ser mais desafiador exibir os dados usando ferramentas padrão.
- Se o seu aplicativo estiver se aproximando das metas de escalabilidade, certifique-se de que esteja usando uma retirada exponencial para novas tentativas. É melhor tentar evitar alcançar as metas de escalabilidade implementando as recomendações descritas neste artigo. No entanto, o uso de um backoff exponencial para novas tentativas impede que seu aplicativo tente novamente com rapidez, o que pode piorar a limitação. Para obter mais informações, confira a seção intitulada Erros de Tempo Limite e Servidor Ocupado.
Vários clientes que acessam simultaneamente um único blob
Se você tiver um grande número de clientes acessando um único blob simultaneamente, será necessário considerar os alvos de escalabilidade por blob e por conta de armazenamento. O número exato de clientes que podem acessar um único blob varia de acordo com fatores como o número de clientes que solicitam o blob simultaneamente, o tamanho do blob e as condições da rede.
Se o blob puder ser distribuído por meio de CDN, como imagens ou vídeos disponibilizados em um site, então use CDN. Para saber mais, consulte a seção intitulada Distribuição de conteúdo.
Em outros cenários como simulações científicas, em que os dados são confidenciais, existem duas opções. A primeira é escalonar o acesso à carga de trabalho, de modo que o blob seja acessado por um período de tempo, em vez de ser acessado simultaneamente. Como alternativa, você pode copiar temporariamente o blob para várias contas de armazenamento, aumentando assim o IOPS total por blob e entre as contas de armazenamento. Os resultados variam de acordo com o comportamento do seu aplicativo, portanto, certifique-se de testar os padrões de simultaneidade durante o projeto.
Largura de banda e operações por blob
Um único blob suporta 500 solicitações por segundo. Se você tiver vários clientes que precisam ler o mesmo blob e esse limite pode ser excedido, considere usar uma conta de armazenamento de blob de blocos. Uma conta de armazenamento de blob de blocos fornece uma taxa mais alta de solicitação ou de operações de E/S por segundo (IOPS).
Você também pode usar uma CDN (rede de distribuição de conteúdo), como a CDN do Azure, para distribuir operações no blob. Para saber mais sobre CDN do Azure, confira Visão geral do CDN do Azure.
Particionamento
A compreensão de como o Armazenamento do Microsoft Azure particiona os dados de blob é importante para melhorar o desempenho. O Armazenamento pode servir dados em uma única partição mais rapidamente do que os dados que abrangem várias partições. Você pode melhorar a eficiência das solicitações de leitura se nomear seus blobs adequadamente.
O armazenamento do blob usa um esquema de particionamento com base em intervalos para colocação em escala e balanceamento de carga. Cada blob tem uma chave de partição composta pelo nome completo do blob (conta + contêiner + blob). A chave de partição é usada para particionar os dados do blob em intervalos. Os intervalos são então balanceados por carga no armazenamento de blobs.
O particionamento baseado em intervalo significa que as convenções de nomenclatura que usam ordenação lexical (por exemplo, mypayroll, myperformance, myemployees, etc.) ou carimbos de data/hora (log20160101, log20160102, log20160102, etc.) têm maior probabilidade de resultar em partições co-localizadas no mesmo servidor de partições até que o aumento da carga exija que elas sejam divididas em intervalos menores. A localização conjunta de blobs no mesmo servidor de partição melhora o desempenho, portanto uma parte importante do aprimoramento de desempenho envolve nomear blobs de forma a organizá-los com mais eficiência.
Por exemplo, todos os blobs em um contêiner podem ser servidos por um único servidor até que a carga nesses blobs exija mais rebalanceamento dos intervalos de partição. Da mesma forma, um grupo de contas com pouca carga, que tenham seus nomes organizados em ordem léxica, podem ser atendidas por um único servidor, até que a carga em uma ou em todas essas contas exija que sejam divididas em vários servidores de partição.
Cada operação de balanceamento de carga pode afetar a latência das chamadas de armazenamento durante a operação. A capacidade do serviço de lidar com um aumento repentino de tráfego para uma partição é limitada pela escalabilidade de um único servidor de partição, até que a operação de balanceamento de carga seja ativada e reequilibre o intervalo de chaves de partição.
Você pode seguir algumas práticas recomendadas para reduzir a frequência de tais operações.
Se possível, use o blob ou tamanhos de bloco superiores a 256 KiB para contas de armazenamento Standard e Premium. Os tamanhos maiores de blob ou bloco ativam automaticamente blobs de blocos de alta taxa de transferência. Os blobs de blocos de taxa de transferência de alto rendimento fornecem ingestão de alto desempenho que não é afetada pela nomenclatura das partições.
Examine a convenção de nomenclatura usada para contas, contêineres, blobs, tabelas e filas. Considere prefixar os nomes de conta, contêiner ou blob com um hash de três dígitos usando uma função de hash que melhor atenda às suas necessidades.
Se você organizar seus dados usando carimbos de data/hora ou identificadores numéricos, certifique-se de que não esteja usando um padrão de tráfego somente de acréscimo (ou somente de pré-inclusão). Esses padrões não são adequados para um sistema de particionamento baseado em intervalo. Esses padrões podem fazer com que todo o tráfego vá para uma única partição e limitar o sistema de fazer balanceamento de carga eficaz.
Por exemplo, se houver operações diárias que usam um blob com um carimbo de data/hora, como aaammdd, todo o tráfego para essa operação diária é direcionado para um único blob, que é servido por um único servidor de partição. Analise se os limites por blob e os limites por partição atendem às suas necessidades, e considere a divisão dessa operação em vários blobs, se necessário. Da mesma forma, se você armazenar os dados de série temporal em tabelas, todo o tráfego pode ser direcionado para a última parte do namespace principal. Se estiver usando IDs numéricas, prefixe a ID com um hash de três dígitos. Se você estiver usando carimbos de data/hora, prefixe o carimbo de data/hora com o valor de segundos, por exemplo, ssyyymmdd. Se seu aplicativo executa rotineiramente operações de listagem e consulta, escolha uma função de hash que limite seu número de consultas. Em outros casos, um prefixo aleatório pode ser suficiente.
Para saber mais sobre o esquema de partição usado no Armazenamento do Microsoft Azure, consulte Armazenamento do Microsoft Azure: um serviço de armazenamento em nuvem com alta disponibilidade e consistência robusta.
Rede
As restrições físicas da rede do aplicativo podem ter um impacto considerável no desempenho. As seções a seguir descrevem algumas das limitações que os usuários podem enfrentar.
Funcionalidade da rede do cliente
A largura de banda e a qualidade do link da rede desempenham funções importantes no desempenho do aplicativo, conforme descrito nas seções a seguir.
Produtividade
No caso da largura de banda, muitas vezes o problema está relacionado às funcionalidades do cliente. As instâncias maiores do Azure têm NICs com mais capacidade. Por isso, você deve usar uma instância maior ou mais VMs se precisar de limites de rede mais altos em um único computador. Se você estiver acessando o Armazenamento do Microsoft Azure a partir de um aplicativo local, a mesma regra se aplica: entenda os recursos de rede do dispositivo cliente e a conectividade de rede com o local de Armazenamento do Azure e aprimore-os conforme necessário ou projete seu aplicativo para funcionar dentro das capacidades deles.
Qualidade do link
Como em qualquer uso de rede, lembre-se de que as condições de rede que resultam em erros e perda de pacotes reduzem a taxa de transferência efetiva. Usar WireShark ou NetMon pode ajudar a identificar esse problema.
Location
Em todos os ambientes, colocar o cliente próximo ao servidor proporciona o melhor desempenho. Para acessar o armazenamento do Azure com o mínimo de latência, o melhor local para o cliente é a região na qual o Azure se encontra. Por exemplo, se tiver um aplicativo Web do Azure que usa o Armazenamento do Azure, localize-os dentro de uma única região, como o Oeste dos EUA ou o Sudeste Asiático. Colocalizar recursos reduz a latência e o custo, pois o uso de largura de banda em uma única região é gratuito.
Se os aplicativos cliente acessarem o Armazenamento do Microsoft Azure, mas não estiverem hospedados no Azure, como aplicativos de dispositivos móveis ou serviços corporativos locais, localizar a conta de armazenamento em uma região próxima a esses clientes poderá reduzir a latência. Se os clientes estiverem amplamente distribuídos (por exemplo, alguns na América do Norte e outros na Europa), considere usar uma conta de armazenamento por região. Essa abordagem é mais fácil de implementar se os dados que o aplicativo armazena forem específicos para usuários individuais e não exigirem a replicação de dados entre contas de armazenamento.
Para uma ampla distribuição de conteúdo de blobs, use uma rede de distribuição de conteúdos, como a CDN do Azure. Para obter mais informações, confira CDN do Azure.
SAS e CORS
Suponha que você precise autorizar um código, como o JavaScript que está sendo executado no navegador da Web de um usuário ou em um aplicativo de celular, a acessar dados no armazenamento do Azure. Uma abordagem é criar um aplicativo de serviço que funcione como um proxy. O dispositivo do usuário é autenticado no serviço que, por sua vez, autoriza o acesso aos recursos do Armazenamento do Azure. Dessa forma, você pode evitar a exposição das chaves de conta de armazenamento em dispositivos que não são seguros. No entanto, essa abordagem gera uma sobrecarga significativa no aplicativo do serviço, porque todos os dados transferidos entre o dispositivo do usuário e o Armazenamento do Azure devem passar pelo aplicativo do serviço.
Você pode evitar usar um aplicativo de serviço como um proxy para o Armazenamento do Azure usando SAS (assinaturas de acesso compartilhado). Usando SAS, você pode permitir que o dispositivo do seu usuário faça solicitações diretamente ao Armazenamento do Azure usando um token de acesso limitado. Por exemplo, se um usuário desejar fazer upload de uma foto para seu aplicativo, seu aplicativo de serviço poderá gerar uma SAS e enviá-la ao dispositivo do usuário. O token SAS pode conceder permissão para gravar em um recurso do Armazenamento do Azure durante um intervalo especificado de tempo; depois disso, o token SAS expirará. Para obter mais informações sobre SAS, confira Conceder acesso limitado a recursos de Armazenamento do Azure usando SAS (assinaturas de acesso compartilhado).
Normalmente, um navegador da Web não permite que o JavaScript em uma página hospedada por um site em um domínio execute determinadas operações, como operações de gravação, em outro domínio. Conhecida como a política de mesma origem, essa política impede que um script mal-intencionado em uma página obtenha acesso a dados em outra página da Web. No entanto, a política de mesma origem pode ser uma limitação ao criar uma solução na nuvem. O CORS (compartilhamento de recurso entre origens) é um recurso do navegador que permite que o domínio de destino se comunique com o navegador ao qual ele confia as solicitações que se originam no domínio de origem.
Por exemplo, suponha que um aplicativo Web em execução no Azure faça uma solicitação para um recurso para uma conta do Armazenamento do Azure. O aplicativo Web é o domínio de origem e a conta de armazenamento é o domínio de destino. Você pode configurar o CORS para que qualquer um dos serviços do Armazenamento do Azure se comunique com o navegador da Web cujas solicitações do domínio de origem têm a confiança do Armazenamento do Azure. Para obter mais informações sobre o CORS, confira Suporte ao CORS (compartilhamento de recurso entre origens) para o Armazenamento do Azure.
SAS e CORS podem ajudar você a evitar uma carga desnecessária em seu aplicativo Web.
Cache
O cache executa um papel importante no desempenho. As seções a seguir abordam as práticas recomendadas de cache.
Lendo dados
Em geral, ler os dados uma vez é preferível do que ler duas vezes. Analise o exemplo de um aplicativo Web que recuperou um blob de 50 MiB do Armazenamento do Microsoft Azure para servir como conteúdo a um usuário. O ideal é o aplicativo armazenar o blob em cache localmente em disco, e depois recuperar a versão em cache para solicitações subsequentes do usuário.
Uma maneira de evitar a recuperação de um blob, se ele não foi modificado desde que foi armazenado em cache, é qualificar a operação GET com um cabeçalho condicional para o tempo de modificação. Se a hora da última modificação for posterior à hora em que o blob foi armazenado em cache, o blob é recuperado e armazenado em cache novamente. Caso contrário, o blob em cache é recuperado para um desempenho otimizado.
Também se pode projetar o aplicativo para assumir que o blob permanece inalterado por um curto período após ser recuperado. Nesse caso, o aplicativo não precisa verificar se o blob foi modificado durante esse intervalo.
Dados de configuração, de pesquisa e outros dados frequentemente usados pelo aplicativo são bons candidatos para armazenamento em cache.
Para saber mais sobre como usar cabeçalhos condicionais, consulte Especificação de cabeçalhos condicionais para operações de serviço Blob.
Carregamento de dados em lotes
Em algumas situações, é possível agregar dados localmente e depois fazer upload em lotes, em vez de carregar cada dado imediatamente. Por exemplo, suponha que um aplicativo Web mantenha um arquivo de log de atividades. O aplicativo pode carregar os detalhes de cada atividade à medida que ela ocorre em uma tabela (que requer muitas operações de armazenamento) ou pode salvar os detalhes da atividade em um arquivo de log local, e fazer uploads periódicos de todos os detalhes da atividade, como por exemplo, um arquivo delimitado em um blob. Se cada entrada de log tiver 1 KB de tamanho, você pode fazer upload de milhares de entradas em uma única transação. Uma única transação suporta o upload de um blob de até 64 MiB de tamanho. O desenvolvedor de aplicativos deve projetar a possibilidade de falhas de upload ou de dispositivos do cliente. Se for necessário fazer download de atividades em um intervalo de tempo em vez de baixar uma única atividade, recomenda-se armazenar em blobs e não em tabelas.
Configuração do .NET
Para projetos que usam o .NET Framework, esta seção lista algumas definições de configurações rápidas que podem ser usadas para melhorar significativamente o desempenho. Se estiver usando uma linguagem diferente do .NET, verifique se conceitos semelhantes se aplicam à linguagem escolhida.
Aumentar limite de conexão padrão
Observação
Esta seção aplica-se a projetos que usam o .NET Framework, pois o pooling de conexões é controlado pela classe ServicePointManager. O .NET Core introduziu uma alteração significativa no gerenciamento do pool de conexões, em que o pool de conexões acontece no nível HttpClient e o tamanho do pool não é limitado por padrão. Isso significa que as conexões HTTP são dimensionadas automaticamente para satisfazer sua carga de trabalho. Recomenda-se usar a versão mais recente do .NET, quando possível, para aproveitar os aprimoramentos de desempenho.
Para projetos que usam o .NET Framework, você pode usar o código a seguir para aumentar o limite da conexão padrão (que geralmente é de dois em um ambiente de cliente ou dez em um ambiente de servidor) para 100. Normalmente, você deve definir o valor para aproximadamente igual ao número de threads utilizados pelo seu aplicativo. Defina o limite da conexão antes de abrir conexões.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Para saber mais sobre os limites do pool de conexão no .NET Framework, confira Limites do Pool de Conexão do .NET Framework e o novo SDK do Azure para .NET.
Para outras linguagens de programação, confira a documentação para verificar como definir o limite da conexão.
Aumentar o número mínimo de threads
Se você estiver usando chamadas síncronas junto com tarefas assíncronas, convém aumentar o número de threads no pool de threads:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Para obter mais informações, confira o método ThreadPool.SetMinThreads.
Paralelismo não associado
Embora o paralelismo possa ser ótimo para o desempenho, tenha cuidado ao usar o paralelismo ilimitado, o que significa que não há limite imposto ao número de threads ou solicitações paralelas. Limite as solicitações paralelas para fazer upload ou baixar dados, para acessar várias partições na mesma conta de armazenamento ou acessar vários itens na mesma partição. Se o paralelismo não estiver associado, o aplicativo poderá ultrapassar as funcionalidades do dispositivo cliente ou as metas de escalabilidade da conta de armazenamento, o que resultará em limitação e latências mais longas.
Bibliotecas de cliente e ferramentas
Para obter o melhor desempenho, sempre use as bibliotecas de cliente e ferramentas mais recentes fornecidas pela Microsoft. As bibliotecas de cliente do Armazenamento do Azure estão disponíveis para várias linguagens. O Armazenamento do Azure também dá suporte ao PowerShell e à CLI do Azure. A Microsoft desenvolve ativamente essas ferramentas e bibliotecas de cliente pensando no desempenho, os mantém atualizados com as versões de serviço mais recentes e verifica se eles lidam com muitas práticas de desempenho comprovadas internamente.
Dica
O driver ABFS foi projetado para superar as deficiências inerentes do WASB. A Microsoft recomenda usar o driver ABFS em vez do driver WASB, pois o driver ABFS é otimizado especificamente para análise de Big Data.
Manipular erros de serviço
O Armazenamento do Microsoft Azure retorna um erro quando o serviço não pode processar uma solicitação. Entender os erros que podem ser retornados pelo Armazenamento do Azure em um determinado cenário é útil para otimizar o desempenho. Para obter uma lista de códigos de erro comuns, consulte Códigos de erro comuns da API REST.
Erros de Tempo Limite e Servidor Ocupado
O Armazenamento do Azure poderá limitar seu aplicativo se ele se aproximar dos limites de escalabilidade. Em alguns casos, o Armazenamento do Azure pode ser incapaz de manipular uma solicitação devido a algumas condições transitórias. Em ambos os casos, o serviço pode retornar um erro 503 (Servidor Ocupado) ou 500 (Tempo Limite). Esses erros também poderão ocorrer se o serviço estiver reequilibrando partições de dados para permitir uma taxa de transferência mais alta. Normalmente, o aplicativo cliente deve repetir a operação que gera um erro desses erros. No entanto, se o Armazenamento do Microsoft Azure estiver limitando seu aplicativo porque ele está excedendo as metas de escalabilidade, ou mesmo se o serviço não conseguiu atender à solicitação por algum outro motivo, novas tentativas agressivas podem piorar o problema. O uso de uma política de repetição de retirada exponencial é recomendado e o padrão das bibliotecas de cliente é esse comportamento. Por exemplo, o aplicativo pode fazer uma nova tentativa em 2 segundos, 4 segundos, 10 segundos e 30 segundos para então abandonar o processo. Dessa forma, seu aplicativo reduz significativamente sua carga sobre o serviço, em vez de exacerbar o comportamento que poderia causar a limitação.
Os erros de conectividade podem ser repetidos imediatamente, porque não são o resultado de limitação e espera-se que sejam transitórios.
Erros sem nova tentativa
As bibliotecas de clientes lidam com novas tentativas com a consciência de quais erros podem ser repetidos e quais não podem ser repetidos. No entanto, se você estiver chamando a API REST do Armazenamento do Microsoft Azure diretamente, há alguns erros que não devem ser repetidos. Por exemplo, um erro 400 (Solicitação Inválida) indica que o aplicativo cliente enviou uma solicitação que não pôde ser processada porque não estava no formato esperado. Reenviar essa solicitação resulta na mesma resposta todas as vezes, portanto, não faz sentido tentar novamente. Se você estiver chamando a API REST de Armazenamento do Microsoft Azure diretamente, esteja ciente de possíveis erros e se eles devem ser repetidos.
Para obter mais informações sobre os códigos de erro do Armazenamento do Azure, confira Status e códigos de erro.
Cópia e mudança de blobs
O Armazenamento do Microsoft Azure fornece uma série de soluções para copiar e mover blobs em uma conta de armazenamento, entre contas de armazenamento e entre sistemas locais e a nuvem. Esta seção descreve algumas dessas opções em relação a seus efeitos sobre o desempenho. Para saber mais sobre como transferir dados de ou para o armazenamento de blobs de forma eficiente, consulte Escolher uma solução do Azure para transferência de dados.
APIs de cópia de blobs
Para copiar blobs entre contas de armazenamento, use a operação Colocar bloco a partir do URL. Esta operação copia dados de forma síncrona de qualquer URL para um blob de blocos. O uso da operação Put Block from URL pode reduzir significativamente a largura de banda necessária quando você estiver migrando dados entre contas de armazenamento. Como a operação de cópia ocorre no lado do serviço, você não precisa fazer o download e o upload novamente dos dados.
Para copiar dados dentro da mesma conta de armazenamento, use a operação de Cópia de blob. A cópia de dados dentro da mesma conta de armazenamento normalmente é concluída rapidamente.
Usar o AzCopy
O utilitário de linha de comando AzCopy é uma opção simples e eficiente para a transferência em massa de blobs para, de e entre contas de armazenamento. O AzCopy é otimizado para esse cenário e pode alcançar altas taxas de transferência. A versão 10 do AzCopy usa a operação Put Block From URL para copiar dados de blob entre contas de armazenamento. Para saber mais, consulte Copiar ou mover dados para o Armazenamento do Microsoft Azure usando o AzCopy v10.
Uso do Azure Data Box
Para importar grandes volumes de dados para o armazenamento de blobs, considere usar os produtos do Azure Data Box para transferências offline. Os dispositivos do Data Box fornecidos pela Microsoft são uma boa opção para mover grandes quantidades de dados para o Azure, quando houver uma limitação de tempo, disponibilidade de rede ou custos. Para saber mais, consulte a Documentação do Azure Data Box.
Distribuição de conteúdo
Às vezes um aplicativo precisa enviar o mesmo conteúdo a muitos usuários (por exemplo, um vídeo para demonstrar um produto, apresentado na página inicial de um site) localizados na mesma região ou em diversas regiões. Nesse cenário, use uma Rede de Distribuição de Conteúdo (CDN), como o Azure Front Door. O Azure Front Door é a CDN de nuvem moderna da Microsoft que fornece acesso rápido, confiável e seguro entre seus usuários e o conteúdo da Web estático e dinâmico de seus aplicativos em todo o mundo. O Azure Front Door fornece seu conteúdo de Armazenamento de Blobs usando a rede de borda global da Microsoft com centenas de pontos de presença (PoPs) globais e locais. Em geral, uma CDN pode suportar limites de saída muito mais altos do que uma única conta de armazenamento e oferece a melhor latência para a entrega de conteúdo a outras redes.
Para saber mais sobre o Azure Front Door, confira Azure Front Door.
Uso de metadados
O serviço Blob é compatível com solicitações HEAD, o que pode incluir propriedades ou metadados do blob. Por exemplo, se o aplicativo precisar de dados Exif (formato de imagem intercambiável) de uma foto, ele poderá recuperar a foto e extraí-la. Para economizar largura de banda e melhorar o desempenho, o aplicativo pode armazenar os dados Exif nos metadados do blob quando o aplicativo carregar a foto. Depois, recuperar os dados Exif nos metadados usando apenas uma solicitação HEAD. A recuperação somente dos metadados e não do conteúdo completo do blob traz uma economia significativa da largura de banda e reduz o tempo de processamento necessário para extrair os dados Exif. Tenha em mente que somente 8 KiB de metadados podem ser armazenados por blob.
Atualizações de metadados de conta e contêiner
Os metadados de conta e contêiner são propagados pelo serviço de armazenamento na região onde a conta reside. A propagação completa desses metadados pode levar até 60 segundos, dependendo da operação. Por exemplo:
- Caso esteja criando, excluindo e recriando contas com o mesmo nome de conta na mesma região, verifique se você está aguardando 60 segundos para que o estado da conta seja totalmente propagado ou suas solicitações podem falhar.
- O estabelecimento de uma política de acesso armazenada em um contêiner, a política poderá levar até 30 segundos entrar em vigor.
Ajuste de desempenho para transferências de dados
Quando um aplicativo transfere dados usando a biblioteca de clientes do Armazenamento do Azure, há vários fatores que podem afetar a velocidade, o uso de memória e até mesmo o êxito ou a falha da solicitação. Para maximizar o desempenho e a confiabilidade das transferências de dados, é importante ser proativo na configuração das opções de transferência da biblioteca do cliente com base no ambiente em que seu aplicativo é executado. Para saber mais, veja Ajuste de desempenho para uploads e downloads.
Upload rápido de blobs
Para fazer upload de blobs rapidamente, primeiro determine se está fazendo upload de um blob ou de vários. Use as informações abaixo para identificar o método de uso correto de acordo com o seu cenário. Se você estiver usando a biblioteca de clientes do Armazenamento do Azure para transferências de dados, confira Ajuste de desempenho para transferências de dados para obter mais diretrizes.
Upload rápido de um blob grande
Para carregar um único blob grande com rapidez, o aplicativo cliente deve carregar os blocos ou as páginas em paralelo, levando em consideração as metas de escalabilidade para cada blob e a conta de armazenamento como um todo. As bibliotecas de cliente do Armazenamento do Microsoft Azure suportam o carregamento em paralelo. As bibliotecas de cliente para outras linguagens compatíveis fornecem opções semelhantes.
Upload rápido de vários blobs
Para carregar diversos blobs com rapidez, carregue-os paralelamente. Fazer uploads em paralelo é mais rápido do que fazer upload de um único blob por vez com uploads de blocos paralelos, porque a carga é dividida em diversas partições do serviço de armazenamento. AzCopy executa os carregamentos em paralelo por padrão e é a opção recomendada nesse caso. Para saber mais, consulte Introdução ao AzCopy.
Escolha do tipo certo de blob
O Armazenamento do Microsoft Azure suporta blobs de blocos, blobs de acréscimos e blobs de páginas. Para um determinado cenário de uso, a escolha do tipo de blob afeta o desempenho e a escalabilidade da sua solução.
Blobs de blocos são apropriados quando se deseja carregar grandes quantidades de dados com eficiência. Por exemplo, um aplicativo cliente que carrega fotos ou vídeos no armazenamento de blobs escolheria blobs de blocos.
Os blobs de acréscimo são semelhantes aos blobs de blocos, pois são compostos por blocos. Quando se modifica um blob de acréscimo, os blocos são adicionados no final do blob. Os blobs de acréscimo são úteis para cenários como registro em log, quando um aplicativo precisa adicionar dados a um blob existente.
Os blobs de página são apropriados se o aplicativo precisa executar gravações aleatórias em dados. Poe exemplo, os discos de máquinas virtuais do Azure são armazenados como blobs de página. Para saber mais, confira Compreendendo blobs de blocos, blobs de acréscimo e blobs de páginas.