Lista de verificação de desempenho e escalabilidade do Armazenamento de blobs
A Microsoft desenvolveu várias práticas comprovadas para desenvolver aplicativos de alto desempenho com armazenamento de Blob. Esta lista de verificação identifica as principais práticas que os desenvolvedores podem seguir para otimizar o desempenho. Tenha essas práticas em mente ao projetar 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 obter mais informações sobre as metas de escalabilidade do Armazenamento do Azure, consulte Metas de escalabilidade e desempenho para contas de armazenamento padrão e Metas de escalabilidade e desempenho para armazenamento de Blob.
Lista de Verificação
Este artigo organiza práticas comprovadas de desempenho em uma lista de verificação que você pode seguir ao desenvolver seu aplicativo de armazenamento de Blob.
Metas de escalabilidade
Se seu aplicativo se aproximar ou exceder qualquer um dos destinos de escalabilidade, ele poderá encontrar latências de transação ou limitação aumentadas. Quando o Armazenamento do Azure limita seu aplicativo, o serviço começa a retornar códigos de erro 503 (Servidor ocupado) ou 500 (Tempo limite de operação). Evitar esses erros permanecendo dentro dos limites das metas de escalabilidade é uma parte importante para melhorar o desempenho do seu aplicativo.
Para obter mais informações sobre metas de escalabilidade para o serviço de fila, consulte Metas de desempenho e escalabilidade 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 permitido para uma determinada combinação de assinatura/região, avalie seu cenário e determine se alguma das seguintes condições se aplica:
- Você está usando contas de armazenamento para armazenar discos não gerenciados e adicionando esses discos às suas máquinas virtuais (VMs)? Para esse cenário, a Microsoft recomenda o uso de discos gerenciados. Os discos gerenciados são dimensionados automaticamente e sem a necessidade de criar e gerenciar contas de armazenamento individuais. Para obter mais informações, consulte Introdução aos discos gerenciados do Azure
- Você está usando uma conta de armazenamento por cliente, para fins de isolamento de dados? Para esse cenário, a Microsoft recomenda o uso de um contêiner de blob para cada cliente, em vez de uma conta de armazenamento inteira. O Armazenamento do Azure agora permite que você atribua funções do Azure por contêiner. Para obter mais informações, veja Atribuir uma função do Azure para acesso aos dados de blobs.
- Você está usando várias contas de armazenamento para fragmentar para aumentar a entrada, saída, operações de E/S por segundo (IOPS) ou capacidade? Nesse cenário, a Microsoft recomenda que você aproveite os limites maiores para contas de armazenamento para 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 limites maiores para sua conta de armazenamento.
Capacidade e metas de transação
Se seu aplicativo estiver se aproximando das metas de escalabilidade para uma única conta de armazenamento, considere adotar uma das seguintes abordagens:
- Se seu aplicativo atingir o destino da transação, considere o uso de contas de armazenamento de blob de bloco, que são otimizadas para altas taxas de transação e latência baixa e consistente. Para mais informações, veja Visão geral de conta de armazenamento do Azure.
- Reconsidere a carga de trabalho que faz com que seu aplicativo se aproxime ou exceda a meta de escalabilidade. Você pode projetá-lo de forma diferente para usar menos largura de banda ou capacidade, ou menos transações?
- Se seu aplicativo precisar exceder um dos destinos de escalabilidade, crie várias contas de armazenamento e particione os dados do aplicativo entre essas várias contas de armazenamento. Se você usar esse padrão, certifique-se de projetar seu aplicativo para que possa adicionar mais contas de armazenamento no futuro para balanceamento de carga. As próprias contas de armazenamento não têm nenhum custo além do seu uso em termos de dados armazenados, transações feitas ou dados transferidos.
- Se seu aplicativo estiver se aproximando dos destinos de largura de banda, considere compactar dados no lado do 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 da rede, também pode ter efeitos negativos no desempenho. Avalie o impacto no desempenho dos requisitos de processamento adicionais para compactação e descompactação de dados no lado do cliente. Lembre-se de que o armazenamento de dados compactados pode dificultar a solução de problemas porque pode ser mais difícil visualizar os dados usando ferramentas padrão.
- Se seu aplicativo estiver se aproximando das metas de escalabilidade, certifique-se de que você está usando um backoff exponencial para tentativas. É melhor tentar evitar atingir as metas de escalabilidade implementando as recomendações descritas neste artigo. No entanto, usar um backoff exponencial para novas tentativas impede que seu aplicativo tente novamente rapidamente, o que pode piorar a limitação. Para obter mais informações, consulte a seção intitulada Tempo limite e erros de servidor ocupado.
Vários clientes acessando um único blob simultaneamente
Se você tiver um grande número de clientes acessando um único blob simultaneamente, precisará considerar os destinos de escalabilidade por blob e por conta de armazenamento. O número exato de clientes que podem acessar um único blob varia dependendo de 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 pode ser distribuído através de uma CDN, como imagens ou vídeos servidos a partir de um site, então você pode usar uma CDN. Para obter mais informações, 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, você tem duas opções. A primeira é escalonar o acesso da sua carga de trabalho de forma que o blob seja acessado por um período de tempo versus ser acessado simultaneamente. Como alternativa, você pode copiar temporariamente o blob para várias contas de armazenamento para aumentar o total de IOPS por blob e entre contas de armazenamento. Os resultados variam dependendo do comportamento do seu aplicativo, portanto, certifique-se de testar padrões de simultaneidade durante o design.
Largura de banda e operações por blob
Um único blob suporta até 500 solicitações por segundo. Se você tiver vários clientes que precisam ler o mesmo blob e pode exceder esse limite, considere usar uma conta de armazenamento de blob de bloco. Uma conta de armazenamento de blob de bloco fornece uma taxa de solicitação mais alta ou operações de E/S por segundo (IOPS).
Você também pode usar uma rede de entrega de conteúdo (CDN), como a CDN do Azure, para distribuir operações no blob. Para obter mais informações sobre a CDN do Azure, consulte Visão geral da CDN do Azure.
Criação de partições
Compreender como o Armazenamento do Azure particiona seus dados de blob é útil para melhorar o desempenho. O Armazenamento do Azure pode servir dados em uma única partição mais rapidamente do que os dados que abrangem várias partições. Ao nomear seus blobs adequadamente, você pode melhorar a eficiência das solicitações de leitura.
O armazenamento de Blob usa um esquema de particionamento baseado em intervalo para dimensionamento e balanceamento de carga. Cada blob tem uma chave de partição composta pelo nome completo do blob (account+container+blob). A chave de partição é usada para particionar dados de blob em intervalos. Os intervalos são então balanceados em todo o armazenamento de Blob.
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 colocalizadas no mesmo servidor de partições até que o aumento da carga exija que elas sejam divididas em intervalos menores. A colocalização de blobs no mesmo servidor de partição melhora o desempenho, portanto, uma parte importante do aprimoramento do desempenho envolve nomear blobs de uma maneira que os organize de forma mais eficaz.
Por exemplo, todos os blobs dentro de um contêiner podem ser servidos por um único servidor até que a carga nesses blobs exija um rebalanceamento adicional dos intervalos de partição. Da mesma forma, um grupo de contas levemente carregadas com seus nomes organizados em ordem lexical pode ser servido por um único servidor até que a carga em uma ou todas essas contas exija que elas 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 uma explosão repentina 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 entre em ação e reequilibre o intervalo de chaves de partição.
Você pode seguir algumas práticas recomendadas para reduzir a frequência dessas operações.
Se possível, use tamanhos de blob ou bloco superiores a 256 KiB para contas de armazenamento padrão e premium. Tamanhos maiores de blob ou bloco ativam automaticamente blobs de bloco de alta taxa de transferência. Os blobs de bloco de alta taxa de transferência fornecem ingestão de alto desempenho que não é afetada pela nomeação de partições.
Examine a convenção de nomenclatura usada para contas, contêineres, blobs, tabelas e filas. Considere adicionar um hash de três dígitos como prefixo ao nome da conta, contentor ou blob através da função hash mais adequada às suas necessidades.
Se você organizar seus dados usando carimbos de data/hora ou identificadores numéricos, certifique-se de que não está usando um padrão de tráfego somente acréscimo (ou somente pendente). Esses padrões não são adequados para um sistema de particionamento baseado em intervalo. Esses padrões podem levar a que todo o tráfego vá para uma única partição e limitar o sistema de balanceamento de carga eficaz.
Por exemplo, se você tiver operações diárias que usam um blob com um carimbo de data/hora, como aaaammdd, todo o tráfego dessa operação diária será direcionado para um único blob, que é servido por um único servidor de partição. Considere se os limites por blob e por partição atendem às suas necessidades e considere dividir essa operação em vários blobs, se necessário. Da mesma forma, se você armazenar dados de séries temporais em suas tabelas, todo o tráfego poderá ser direcionado para a última parte do namespace de chave. Se você estiver usando IDs numéricos, prefixe o 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, ssyyyymmdd. 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 alguns casos, um prefixo aleatório pode ser suficiente.
Para obter mais informações sobre o esquema de particionamento usado no Armazenamento do Azure, consulte Armazenamento do Azure: um serviço de armazenamento em nuvem altamente disponível com forte consistência.
Rede
As restrições de rede física do aplicativo podem ter um impacto significativo no desempenho. As seções a seguir descrevem algumas das limitações que os usuários podem encontrar.
Capacidade de rede do cliente
A largura de banda e a qualidade do link de rede desempenham papéis importantes no desempenho do aplicativo, conforme descrito nas seções a seguir.
Débito
Para a largura de banda, o problema é muitas vezes as capacidades do cliente. Instâncias maiores do Azure têm NICs com maior capacidade, portanto, você deve considerar o uso de uma instância maior ou mais VMs se precisar de limites de rede mais altos de uma única máquina. Se você estiver acessando o Armazenamento do Azure a partir de um aplicativo local, a mesma regra se aplica: entender os recursos de rede do dispositivo cliente e a conectividade de rede com o local de Armazenamento do Azure e melhorá-los conforme necessário ou projetar seu aplicativo para funcionar dentro de seus recursos.
Qualidade do link
Como em qualquer uso de rede, tenha em mente que as condições de rede que resultam em erros e perda de pacotes retardam a taxa de transferência efetiva. Usar o WireShark ou o NetMon pode ajudar no diagnóstico desse problema.
Localização
Em qualquer ambiente distribuído, colocar o cliente perto do servidor proporciona o melhor desempenho. Para acessar o Armazenamento do Azure com a menor latência, o melhor local para seu cliente está dentro da mesma região do Azure. Por exemplo, se você tiver um aplicativo Web do Azure que usa o Armazenamento do Azure, localize ambos em uma única região, como Oeste dos EUA ou Sudeste da Ásia. A colocalização de recursos reduz a latência e o custo, já que o uso da largura de banda em uma única região é gratuito.
Se os aplicativos cliente acessarem o Armazenamento do Azure, mas não estiverem hospedados no Azure, como aplicativos de dispositivo móvel ou serviços empresariais locais, localizar a conta de armazenamento em uma região próxima a esses clientes pode reduzir a latência. Se seus 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 blob, use uma rede de entrega de conteúdo, como a CDN do Azure. Para obter mais informações sobre a CDN do Azure, consulte CDN do Azure.
SAS e CORS
Suponha que você precise autorizar um código como JavaScript em execução no navegador da Web de um usuário ou em um aplicativo de celular para acessar dados no Armazenamento do Azure. Uma abordagem é criar um aplicativo de serviço que atue como um proxy. O dispositivo do usuário é autenticado com o serviço, que, por sua vez, autoriza o acesso aos recursos do Armazenamento do Azure. Desta forma, pode evitar expor as chaves da sua conta de armazenamento em dispositivos inseguros. No entanto, essa abordagem coloca uma sobrecarga significativa no aplicativo de serviço, porque todos os dados transferidos entre o dispositivo do usuário e o Armazenamento do Azure devem passar pelo aplicativo de serviço.
Você pode evitar usar um aplicativo de serviço como um proxy para o Armazenamento do Azure usando assinaturas de acesso compartilhado (SAS). Usando o SAS, você pode habilitar o dispositivo do usuário para fazer solicitações diretamente ao Armazenamento do Azure usando um token de acesso limitado. Por exemplo, se um usuário quiser carregar uma foto para seu aplicativo, seu aplicativo de serviço poderá gerar uma SAS e enviá-la para o dispositivo do usuário. O token SAS pode conceder permissão para gravar em um recurso de Armazenamento do Azure por um intervalo de tempo especificado, após o qual o token SAS expira. Para obter mais informações sobre SAS, consulte Conceder acesso limitado aos recursos do Armazenamento do Azure usando assinaturas de acesso compartilhado (SAS).
Normalmente, um navegador da Web não permite que 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 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 compartilhamento de recursos entre origens (CORS) é um recurso do navegador que permite que o domínio de destino comunique ao navegador que confia nas solicitações originadas no domínio de origem.
Por exemplo, suponha que um aplicativo Web em execução no Azure faça uma solicitação de um recurso para uma conta de 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 qualquer um dos serviços de Armazenamento do Azure para comunicar ao navegador da Web que as solicitações do domínio de origem são confiáveis pelo Armazenamento do Azure. Para obter mais informações sobre CORS, consulte Suporte de compartilhamento de recursos entre origens (CORS) para o Armazenamento do Azure.
Tanto o SAS quanto o CORS podem ajudá-lo a evitar cargas desnecessárias em seu aplicativo Web.
Colocação em cache
O cache desempenha um papel importante no desempenho. As seções a seguir discutem as práticas recomendadas de cache.
Ler os dados
Em geral, ler dados uma vez é preferível a lê-los duas vezes. Considere o exemplo de um aplicativo Web que recuperou um blob de 50 MiB do Armazenamento do Azure para servir como conteúdo para um usuário. Idealmente, o aplicativo armazena o blob em cache localmente no disco e, em seguida, recupera a versão em cache para solicitações subsequentes do usuário.
Uma maneira de evitar recuperar um blob se ele não tiver sido 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 última hora modificada for após o tempo em que o blob foi armazenado em cache, o blob será recuperado e armazenado novamente em cache. Caso contrário, o blob armazenado em cache será recuperado para um desempenho ideal.
Você também pode decidir projetar seu aplicativo para assumir que o blob permanece inalterado por um curto período após recuperá-lo. Nesse caso, o aplicativo não precisa verificar se o blob foi modificado durante esse intervalo.
Dados de configuração, dados de pesquisa e outros dados que são usados com freqüência pelo aplicativo são bons candidatos para cache.
Para obter mais informações sobre como usar cabeçalhos condicionais, consulte Especificando cabeçalhos condicionais para operações de serviço de Blob.
Upload de dados em lotes
Em alguns cenários, você pode agregar dados localmente e, em seguida, carregá-los periodicamente em um lote em vez de carregar cada parte dos dados imediatamente. Por exemplo, suponha que um aplicativo Web mantenha um arquivo de log de atividades. O aplicativo pode carregar detalhes de cada atividade como acontece com uma tabela (o que requer muitas operações de armazenamento), ou pode salvar detalhes da atividade em um arquivo de log local e, em seguida, carregar periodicamente todos os detalhes da atividade como um arquivo delimitado para um blob. Se cada entrada de log tiver 1 KB, você poderá carregar 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 do aplicativo deve projetar para a possibilidade de dispositivo cliente ou falhas de upload. Se os dados de atividade precisarem ser baixados por um intervalo de tempo em vez de uma única atividade, recomenda-se o uso do armazenamento de Blob no armazenamento de tabela.
Configuração do .NET
Para projetos que usam o .NET Framework, esta seção lista algumas definições de configuração rápida que você pode usar para fazer melhorias significativas de desempenho. Se você estiver usando um idioma diferente do .NET, verifique se conceitos semelhantes se aplicam no idioma escolhido.
Aumentar o limite de conexão padrão
Nota
Esta seção se aplica a projetos que usam o .NET Framework, pois o pool de conexões é controlado pela classe ServicePointManager. O .NET Core introduziu uma mudança significativa em torno do gerenciamento do pool de conexões, onde 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. O uso da versão mais recente do .NET é recomendado, 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 de conexão padrão (que geralmente é dois em um ambiente de cliente ou dez em um ambiente de servidor) para 100. Normalmente, você deve definir o valor para aproximadamente o número de threads usados pelo seu aplicativo. Defina o limite de conexão antes de abrir qualquer conexão.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Para saber mais sobre os limites do pool de conexões no .NET Framework, consulte Limites do pool de conexões do .NET Framework e o novo SDK do Azure para .NET.
Para outras linguagens de programação, consulte a documentação para determinar como definir o limite de conexão.
Aumentar o número mínimo de threads
Se você estiver usando chamadas síncronas juntamente 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, consulte o método ThreadPool.SetMinThreads .
Paralelismo ilimitado
Embora o paralelismo possa ser ótimo para o desempenho, tenha cuidado ao usar paralelismo ilimitado, o que significa que não há limite imposto ao número de threads ou solicitações paralelas. Certifique-se de limitar as solicitações paralelas para carregar ou baixar dados, para acessar várias partições na mesma conta de armazenamento ou para acessar vários itens na mesma partição. Se o paralelismo não for limitado, seu aplicativo poderá exceder os recursos do dispositivo cliente ou os destinos de escalabilidade da conta de armazenamento, resultando em latências e limitações mais longas.
Bibliotecas e ferramentas de clientes
Para obter o melhor desempenho, use sempre as bibliotecas de cliente e as ferramentas mais recentes fornecidas pela Microsoft. As bibliotecas de cliente do Armazenamento do Azure estão disponíveis para vários idiomas. O Armazenamento do Azure também dá suporte ao PowerShell e à CLI do Azure. A Microsoft desenvolve ativamente essas bibliotecas e ferramentas de cliente com o desempenho em mente, mantém-nas atualizadas com as versões de serviço mais recentes e garante que elas lidem com muitas das práticas de desempenho comprovadas internamente.
Gorjeta
O driver ABFS foi projetado para superar as deficiências inerentes ao WASB. A Microsoft recomenda o uso do driver ABFS sobre o driver WASB, pois o driver ABFS é otimizado especificamente para análise de big data.
Manipular erros de serviço
O Armazenamento do Azure retorna um erro quando o serviço não pode processar uma solicitação. Compreender 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 pode limitar seu aplicativo se ele se aproximar dos limites de escalabilidade. Em alguns casos, o Armazenamento do Azure pode não conseguir lidar com uma solicitação devido a alguma condição transitória. Em ambos os casos, o serviço pode retornar um erro 503 (Servidor ocupado) ou 500 (tempo limite). Esses erros também podem ocorrer se o serviço estiver reequilibrando partições de dados para permitir uma taxa de transferência mais alta. O aplicativo cliente normalmente deve tentar novamente a operação que causa um desses erros. No entanto, se o Armazenamento do Azure estiver limitando seu aplicativo porque está excedendo as metas de escalabilidade, ou mesmo se o serviço não pôde atender à solicitação por algum outro motivo, novas tentativas agressivas podem piorar o problema. Recomenda-se o uso de uma política de repetição de recuo exponencial, e as bibliotecas de cliente usam esse comportamento como padrão. Por exemplo, seu aplicativo pode tentar novamente após 2 segundos, depois 4 segundos, depois 10 segundos, depois 30 segundos e, em seguida, desistir completamente. Dessa forma, seu aplicativo reduz significativamente sua carga no serviço, em vez de exacerbar o comportamento que poderia levar à limitação.
Os erros de conectividade podem ser repetidos imediatamente, porque não são o resultado da limitação e espera-se que sejam transitórios.
Erros não repetitivos
As bibliotecas de cliente lidam com novas tentativas com um conhecimento 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 Azure diretamente, há alguns erros que você não deve tentar novamente. Por exemplo, um erro 400 (Solicitação incorreta) indica que o aplicativo cliente enviou uma solicitação que não pôde ser processada porque não estava na forma esperada. Reenviar essa solicitação resulta sempre na mesma resposta, portanto, não adianta tentar novamente. Se você estiver chamando a API REST do Armazenamento do Azure diretamente, esteja ciente de possíveis erros e se eles devem ser repetidos.
Para obter mais informações sobre códigos de erro do Armazenamento do Azure, consulte Status e códigos de erro.
Copiar e mover blobs
O Armazenamento do Azure fornece várias soluções para copiar e mover blobs dentro de uma conta de armazenamento, entre contas de armazenamento e entre sistemas locais e a nuvem. Esta seção descreve algumas dessas opções em termos de seus efeitos sobre o desempenho. Para obter informações sobre como transferir dados de ou para o armazenamento de Blob de forma eficiente, consulte Escolher uma solução do Azure para transferência de dados.
APIs de cópia de blob
Para copiar blobs entre contas de armazenamento, use a operação Colocar Bloquear de URL . Esta operação copia dados de forma síncrona de qualquer fonte de URL para um blob de bloco. O uso da operação pode reduzir significativamente a Put Block from URL largura de banda necessária ao migrar dados entre contas de armazenamento. Como a operação de cópia ocorre no lado do serviço, você não precisa baixar e recarregar os dados.
Para copiar dados dentro da mesma conta de armazenamento, use a operação Copiar Blob . A cópia de dados dentro da mesma conta de armazenamento normalmente é concluída rapidamente.
Utilizar o AZCopy
O utilitário de linha de comando AzCopy é uma opção simples e eficiente para transferência em massa de blobs para, de e entre contas de armazenamento. AzCopy é otimizado para este cenário, e pode alcançar altas taxas de transferência. AzCopy versão 10 usa a Put Block From URL operação para copiar dados de blob entre contas de armazenamento. Para obter mais informações, consulte Copiar ou mover dados para o Armazenamento do Azure usando o AzCopy v10.
Usar o Azure Data Box
Para importar grandes volumes de dados para o armazenamento de Blob, considere usar a família Azure Data Box para transferências offline. Os dispositivos Data Box fornecidos pela Microsoft são uma boa opção para mover grandes quantidades de dados para o Azure quando você está limitado por tempo, disponibilidade de rede ou custos. Para obter mais informações, consulte a Documentação do Azure DataBox.
Distribuição de conteúdos
Às vezes, um aplicativo precisa fornecer o mesmo conteúdo para muitos usuários (por exemplo, um vídeo de demonstração do produto usado na página inicial de um site), localizado na mesma região ou em várias regiões. Nesse cenário, use uma CDN (Rede de Distribuição de Conteúdo), como a Porta da Frente do Azure. O Azure Front Door é a moderna CDN na nuvem 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 Blob usando a rede de borda global da Microsoft com centenas de pontos de presença (PoPs) globais e locais. Normalmente, uma CDN pode suportar limites de saída muito mais altos do que uma única conta de armazenamento e oferece latência aprimorada para entrega de conteúdo para outras regoins.
Para obter mais informações sobre o Azure Front Door, consulte Azure Front Door.
Usar metadados
O serviço Blob suporta solicitações HEAD, que podem incluir propriedades de blob ou metadados. Por exemplo, se o seu aplicativo precisar dos 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, seu aplicativo pode armazenar os dados Exif nos metadados do blob quando o aplicativo carrega a foto. Em seguida, você pode recuperar os dados Exif em metadados usando apenas uma solicitação HEAD. Recuperar apenas metadados e não o conteúdo completo do blob economiza largura de banda significativa e reduz o tempo de processamento necessário para extrair os dados Exif. Tenha em mente que 8 KiB de metadados podem ser armazenados por blob.
Atualizações de metadados de conta e contêiner
Os metadados da conta e do 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:
- Se você estiver criando, excluindo e recriando rapidamente contas com o mesmo nome de conta na mesma região, certifique-se de que está aguardando 60 segundos para que o estado da conta se propague completamente, ou suas solicitações podem falhar.
- Quando você estabelece uma política de acesso armazenado em um contêiner, a política pode levar até 30 segundos para entrar em vigor.
Ajuste de desempenho para transferências de dados
Quando um aplicativo transfere dados usando a biblioteca de cliente do Armazenamento do Azure, há vários fatores que podem afetar a velocidade, o uso de memória e até mesmo o sucesso ou 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, consulte Ajuste de desempenho para uploads e downloads.
Carregue blobs rapidamente
Para carregar blobs rapidamente, primeiro determine se você está carregando um blob ou vários. Use as orientações abaixo para determinar o método correto a ser usado, dependendo do seu cenário. Se você estiver usando a biblioteca de cliente do Armazenamento do Azure para transferências de dados, consulte Ajuste de desempenho para transferências de dados para obter mais orientações.
Carregue um blob grande rapidamente
Para carregar um único blob grande rapidamente, um aplicativo cliente pode carregar seus blocos ou páginas em paralelo, tendo em mente as metas de escalabilidade para blobs individuais e a conta de armazenamento como um todo. As bibliotecas de cliente do Armazenamento do Azure suportam o carregamento em paralelo. As bibliotecas de cliente para outros idiomas suportados fornecem opções semelhantes.
Carregue muitos blobs rapidamente
Para carregar muitos blobs rapidamente, carregue blobs em paralelo. Carregar em paralelo é mais rápido do que carregar blobs únicos de cada vez com carregamentos de blocos paralelos porque distribui o carregamento por várias partições do serviço de armazenamento. O AzCopy executa carregamentos em paralelo por padrão e é recomendado para esse cenário. Para obter mais informações, consulte Introdução ao AzCopy.
Escolha o tipo correto de blob
O Armazenamento do Azure dá suporte a blobs de bloco, blobs de acréscimo e blobs de página. Para um determinado cenário de uso, sua escolha de tipo de blob afeta o desempenho e a escalabilidade de sua solução.
Os blobs de bloco são apropriados quando você deseja carregar grandes quantidades de dados de forma eficiente. Por exemplo, um aplicativo cliente que carrega fotos ou vídeos para o armazenamento de Blob teria como alvo blobs de bloco.
Os blobs de acréscimo são semelhantes aos blobs de bloco, pois são compostos por blocos. Quando você modifica um blob de acréscimo, os blocos são adicionados somente ao final do blob. Os blobs de acréscimo são úteis para cenários como o registro em log, quando um aplicativo precisa adicionar dados a um blob existente.
Os blobs de página são apropriados se o aplicativo precisar executar gravações aleatórias nos dados. Por exemplo, os discos de máquina virtual do Azure são armazenados como blobs de página. Para obter mais informações, consulte Noções básicas sobre blobs de bloco, blobs de acréscimo e blobs de página.