Lista de verificação de desempenho e escalabilidade para armazenamento de tabelas
A Microsoft desenvolveu muitas práticas comprovadas para o desenvolvimento de aplicativos de alto desempenho com armazenamento de tabela. 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 tabela.
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 tabela.
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 Tabela, consulte Metas de escalabilidade e desempenho para armazenamento de tabela.
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, 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:
- 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 impedirá 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.
Metas para operações de dados
A carga do Armazenamento do Azure se equilibra à medida que o tráfego para sua conta de armazenamento aumenta, mas se o tráfego exibir picos repentinos, talvez você não consiga obter esse volume de taxa de transferência imediatamente. Espere ver limitações e/ou tempos limite durante a intermitência, pois o Armazenamento do Azure equilibra automaticamente a carga da tabela. Acelerar lentamente geralmente fornece melhores resultados, pois o sistema tem tempo para balancear a carga adequadamente.
Entidades por segundo (conta de armazenamento)
O limite de escalabilidade para acessar tabelas é de até 20.000 entidades (1 KB cada) por segundo para uma conta. Em geral, cada entidade inserida, atualizada, excluída ou digitalizada conta para esse destino. Assim, uma inserção de lote que contenha 100 entidades contaria como 100 entidades. Uma consulta que verifica 1000 entidades e retorna 5 contaria como 1000 entidades.
Entidades por segundo (partição)
Dentro de uma única partição, o destino de escalabilidade para acessar tabelas é de 2.000 entidades (1 KB cada) por segundo, usando a mesma contagem descrita na seção anterior.
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.
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.
Transações em lote
O serviço Tabela suporta transações em lote em entidades que estão na mesma tabela e pertencem ao mesmo grupo de partições. Para obter mais informações, consulte Executando transações de grupo de entidades.
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 é 2 em um ambiente de cliente ou 10 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.
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 retornados pelo Armazenamento do Azure em um determinado cenário é útil para otimizar o desempenho.
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. 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.
Configuração
Esta seção lista várias definições de configuração rápida que você pode usar para fazer melhorias significativas de desempenho no serviço Tabela:
Usar JSON
A partir da versão 2013-08-15 do serviço de armazenamento, o serviço Tabela suporta o uso de JSON em vez do formato AtomPub baseado em XML para transferir dados de tabela. O uso do JSON pode reduzir o tamanho da carga útil em até 75% e pode melhorar significativamente o desempenho do seu aplicativo.
Para obter mais informações, consulte a publicação Tabelas do Microsoft Azure: Introdução ao JSON e ao formato de carga útil para operações de serviço de tabela.
Desativar Nagle
O algoritmo de Nagle é amplamente implementado em redes TCP/IP como um meio de melhorar o desempenho da rede. No entanto, não é ideal em todas as circunstâncias (como ambientes altamente interativos). O algoritmo de Nagle tem um impacto negativo no desempenho de solicitações para o serviço de Tabela do Azure, e você deve desativá-lo se possível.
Esquema
A forma como você representa e consulta seus dados é o maior fator individual que afeta o desempenho do serviço Tabela. Embora cada aplicativo seja diferente, esta seção descreve algumas práticas gerais comprovadas relacionadas a:
- Design de mesa
- Consultas eficientes
- Atualizações de dados eficientes
Tabelas e partições
As tabelas são divididas em partições. Cada entidade armazenada em uma partição compartilha a mesma chave de partição e tem uma chave de linha exclusiva para identificá-la dentro dessa partição. As partições oferecem benefícios, mas também introduzem limites de escalabilidade.
- Benefícios: Você pode atualizar entidades na mesma partição em uma única transação em lote atômica que contém até 100 operações de armazenamento separadas (limite de 4 MB de tamanho total). Supondo o mesmo número de entidades a serem recuperadas, você também pode consultar dados dentro de uma única partição de forma mais eficiente do que os dados que abrangem partições (embora continue lendo para obter mais recomendações sobre como consultar dados de tabela).
- Limite de escalabilidade: o acesso a entidades armazenadas em uma única partição não pode ser balanceado porque as partições suportam transações em lote atômico. Por esse motivo, o destino de escalabilidade para uma partição de tabela individual é menor do que para o serviço de tabela como um todo.
Devido a essas características de tabelas e partições, você deve adotar os seguintes princípios de design:
- Localize os dados que seu aplicativo cliente frequentemente atualiza ou consulta na mesma unidade lógica de trabalho na mesma partição. Por exemplo, localize dados na mesma partição se seu aplicativo estiver agregando gravações ou se você estiver executando operações em lote atômico. Além disso, os dados em uma única partição podem ser consultados de forma mais eficiente em uma única consulta do que os dados entre partições.
- Localize dados que seu aplicativo cliente não insere, atualiza ou consulta na mesma unidade lógica de trabalho (ou seja, em uma única consulta ou atualização em lote) em partições separadas. Tenha em mente que não há limite para o número de chaves de partição em uma única tabela, portanto, ter milhões de chaves de partição não é um problema e não afetará o desempenho. Por exemplo, se o seu aplicativo for um site popular com login de usuário, usar o ID de usuário como a chave de partição pode ser uma boa escolha.
Divisórias quentes
Uma partição quente é aquela que está recebendo uma porcentagem desproporcional do tráfego para uma conta e não pode ser balanceada porque é uma única partição. Em geral, as partições quentes são criadas de duas maneiras:
Padrões Append Only e Prepend Only
O padrão "Append Only" é aquele em que todo (ou quase todo) o tráfego para uma determinada chave de partição aumenta e diminui de acordo com o tempo atual. Por exemplo, suponha que seu aplicativo use a data atual como uma chave de partição para dados de log. Esse design resulta em todas as inserções indo para a última partição em sua tabela, e o sistema não pode balancear a carga corretamente. Se o volume de tráfego para essa partição exceder o destino de escalabilidade no nível de partição, isso resultará em limitação. É melhor garantir que o tráfego seja enviado para várias partições, para permitir o balanceamento de carga das solicitações em toda a tabela.
Dados de tráfego elevado
Se o seu esquema de particionamento resultar em uma única partição que apenas tenha dados que são muito mais usados do que outras partições, você também poderá ver a limitação à medida que essa partição se aproxima do destino de escalabilidade para uma única partição. É melhor certificar-se de que seu esquema de partição resulte em nenhuma partição única se aproximando dos alvos de escalabilidade.
A consultar
Esta seção descreve práticas comprovadas para consultar o serviço Tabela.
Âmbito de consulta
Há várias maneiras de especificar o intervalo de entidades a serem consultadas. A lista a seguir descreve cada opção para o escopo da consulta.
- Consultas de ponto:- Uma consulta de ponto recupera exatamente uma entidade especificando a chave de partição e a chave de linha da entidade a ser recuperada. Essas consultas são eficientes e você deve usá-las sempre que possível.
- Consultas de partição: uma consulta de partição é uma consulta que recupera um conjunto de dados que compartilha uma chave de partição comum. Normalmente, a consulta especifica um intervalo de valores de chave de linha ou um intervalo de valores para alguma propriedade de entidade, além de uma chave de partição. Essas consultas são menos eficientes do que as consultas pontuais e devem ser usadas com moderação.
- Consultas de tabela: uma consulta de tabela é uma consulta que recupera um conjunto de entidades que não compartilham uma chave de partição comum. Essas consultas não são eficientes e você deve evitá-las se possível.
Em geral, evite varreduras (consultas maiores que uma única entidade), mas se você precisar digitalizar, tente organizar seus dados para que as varreduras recuperem os dados de que você precisa sem digitalizar ou retornar quantidades significativas de entidades de que você não precisa.
Densidade da consulta
Outro fator-chave na eficiência da consulta é o número de entidades retornadas em comparação com o número de entidades verificadas para encontrar o conjunto retornado. Se seu aplicativo executar uma consulta de tabela com um filtro para um valor de propriedade que apenas 1% dos dados compartilha, a consulta verificará 100 entidades para cada entidade retornada. Os objetivos de escalabilidade da tabela discutidos anteriormente estão relacionados ao número de entidades verificadas, e não ao número de entidades retornadas: uma baixa densidade de consulta pode facilmente fazer com que o serviço Tabela acelere seu aplicativo porque ele deve verificar muitas entidades para recuperar a entidade que você está procurando. Para obter mais informações sobre como evitar a limitação, consulte a seção intitulada Desnormalização.
Limitar a quantidade de dados devolvidos
Quando você souber que uma consulta retorna entidades que não são necessárias no aplicativo cliente, considere usar um filtro para reduzir o tamanho do conjunto retornado. Embora as entidades não devolvidas ao cliente ainda contem para os limites de escalabilidade, o desempenho do aplicativo melhora devido ao tamanho reduzido da carga útil da rede e ao número reduzido de entidades que o aplicativo cliente deve processar. Lembre-se de que os destinos de escalabilidade estão relacionados ao número de entidades verificadas, portanto, uma consulta que filtra muitas entidades ainda pode resultar em limitação, mesmo que poucas entidades sejam retornadas. Para obter mais informações sobre como tornar as consultas eficientes, consulte a seção intitulada Densidade de consulta.
Se seu aplicativo cliente precisar apenas de um conjunto limitado de propriedades das entidades em sua tabela, você poderá usar a projeção para limitar o tamanho do conjunto de dados retornado. Tal como acontece com a filtragem, a projeção ajuda a reduzir a carga da rede e o processamento do cliente.
Desnormalização
Ao contrário de trabalhar com bancos de dados relacionais, as práticas comprovadas para consultar dados de tabela de forma eficiente levam à desnormalização dos dados. Ou seja, duplicar os mesmos dados em várias entidades (uma para cada chave que você pode usar para localizar os dados) para minimizar o número de entidades que uma consulta deve verificar para encontrar os dados de que o cliente precisa, em vez de ter que verificar um grande número de entidades para encontrar os dados de que seu aplicativo precisa. Por exemplo, em um site de comércio eletrônico, você pode querer encontrar um pedido tanto pelo ID do cliente (me dê os pedidos deste cliente) quanto pela data (me dê pedidos em uma data). No Armazenamento de Tabelas, é melhor armazenar a entidade (ou uma referência a ela) duas vezes – uma vez com Nome da Tabela, PK e RK para facilitar a localização por ID do cliente, uma vez para facilitar a localização até a data.
Inserir, atualizar e excluir
Esta seção descreve práticas comprovadas para modificar entidades armazenadas no serviço Tabela.
Criação de batches
As transações em lote são conhecidas como transações de grupo de entidades no Armazenamento do Azure. Todas as operações dentro de uma transação de grupo de entidades devem estar em uma única partição em uma única tabela. Sempre que possível, use transações de grupo de entidades para executar inserções, atualizações e exclusões em lotes. O uso de transações de grupo de entidades reduz o número de viagens de ida e volta do seu aplicativo cliente para o servidor, reduz o número de transações faturáveis (uma transação de grupo de entidades conta como uma única transação para fins de faturamento e pode conter até 100 operações de armazenamento) e permite atualizações atômicas (todas as operações são bem-sucedidas ou todas falham em uma transação de grupo de entidades). Ambientes com altas latências, como dispositivos móveis, se beneficiam muito do uso de transações de grupo de entidades.
Upsert
Use operações de Upsert de tabela sempre que possível. Existem dois tipos de Upsert, que podem ser mais eficientes do que uma operação tradicional de Inserção e Atualização:
- InsertOrMerge: use esta operação quando quiser carregar um subconjunto das propriedades da entidade, mas não tiver certeza se a entidade já existe. Se a entidade existir, essa chamada atualiza as propriedades incluídas na operação Upsert e deixa todas as propriedades existentes como estão, se a entidade não existir, ela insere a nova entidade. Isso é semelhante ao uso de projeção em uma consulta, na medida em que você só precisa carregar as propriedades que estão mudando.
- InsertOrReplace: Use esta operação quando quiser carregar uma entidade totalmente nova, mas não tiver certeza se ela já existe. Use esta operação quando souber que a entidade recém-carregada está totalmente correta, pois substitui completamente a entidade antiga. Por exemplo, você deseja atualizar a entidade que armazena a localização atual de um usuário, independentemente de o aplicativo ter ou não armazenado anteriormente dados de localização para o usuário; A nova entidade de localização está completa e você não precisa de nenhuma informação de nenhuma entidade anterior.
Armazenando séries de dados em uma única entidade
Às vezes, um aplicativo armazena uma série de dados que ele frequentemente precisa recuperar todos de uma vez: por exemplo, um aplicativo pode rastrear o uso da CPU ao longo do tempo para plotar um gráfico contínuo dos dados das últimas 24 horas. Uma abordagem é ter uma entidade de tabela por hora, com cada entidade representando uma hora específica e armazenando o uso da CPU para essa hora. Para plotar esses dados, o aplicativo precisa recuperar as entidades que detêm os dados das 24 horas mais recentes.
Como alternativa, seu aplicativo pode armazenar o uso da CPU para cada hora como uma propriedade separada de uma única entidade: para atualizar cada hora, seu aplicativo pode usar uma única chamada InsertOrMerge Upsert para atualizar o valor para a hora mais recente. Para plotar os dados, o aplicativo só precisa recuperar uma única entidade em vez de 24, tornando a consulta eficiente. Para obter mais informações sobre a eficiência da consulta, consulte a seção intitulada Escopo da consulta.
Armazenando dados estruturados em blobs
Se você estiver executando inserções em lote e, em seguida, recuperando intervalos de entidades juntas, considere usar blobs em vez de tabelas. Um bom exemplo é um arquivo de log. Você pode agrupar vários minutos de logs e inseri-los e, em seguida, recuperar vários minutos de logs de cada vez. Nesse caso, o desempenho é melhor se você usar blobs em vez de tabelas, uma vez que pode reduzir significativamente o número de objetos gravados ou lidos e, possivelmente, também o número de solicitações que precisam ser feitas.