Partilhar via

Otimizar o custo de pedido no Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL MongoDB Cassandra Gremlin Tabela

Este artigo descreve como as solicitações de leitura e gravação se traduzem em Unidades de Solicitação e como otimizar o custo dessas solicitações. As operações de leitura incluem leituras pontuais e consultas. As operações de gravação incluem inserção, substituição, exclusão e atualização de itens.

O Azure Cosmos DB oferece um conjunto avançado de operações de banco de dados que operam nos itens dentro de um contêiner. O custo associado a cada uma destas operações varia com base na CPU, E/S e memória necessárias para concluir a operação. Em vez de pensar e gerenciar recursos de hardware, você pode pensar em uma Unidade de Solicitação (RU) como uma única medida para os recursos necessários para executar várias operações de banco de dados para atender a uma solicitação.

Medição da taxa de RU de um pedido

É importante medir a cobrança de RU de suas solicitações para entender seu custo real e também avaliar a eficácia de suas otimizações. Você pode obter esse custo usando o portal do Azure ou inspecionando a resposta enviada de volta do Azure Cosmos DB por meio de um dos SDKs. Consulte Localizar a taxa de unidade de solicitação no Azure Cosmos DB para obter instruções detalhadas sobre como conseguir isso.

Leitura de dados: leituras pontuais e consultas

As operações de leitura no Azure Cosmos DB normalmente são ordenadas da mais rápida/mais eficiente para a mais lenta/menos eficiente em termos de consumo de RU da seguinte maneira:

  • Leituras de pontos (pesquisa de chave/valor em um único ID de item e chave de partição).
  • Consulta com uma cláusula de filtro dentro de uma única chave de partição.
  • Consulta sem uma cláusula de filtro de igualdade ou intervalo em qualquer propriedade.
  • Consulta sem filtros.

Papel do nível de coerência

Ao usar os níveis de consistência de obsoletos fortes ou limitados, o custo de RU de qualquer operação de leitura (leitura pontual ou consulta) é dobrado.

Ponto lê

O único fator que afeta a carga de RU de uma leitura pontual (além do nível de consistência usado) é o tamanho do item recuperado. A tabela a seguir mostra o custo RU de leituras de pontos para itens com 1 KB e 100 KB de tamanho.

Tamanho do item Custo de um ponto lido
1 KB 1 RU
100 KB 10 RUs

Como as leituras de ponto (pesquisas de chave/valor no ID do item e na chave de partição) são o tipo de leitura mais eficiente, você deve certificar-se de que o ID do item tenha um valor significativo para que possa buscar seus itens com uma leitura pontual (em vez de uma consulta) quando possível.

Nota

Na API para NoSQL, as leituras pontuais só podem ser feitas usando a API REST ou SDKs. As consultas que filtram o ID e a chave de partição de um item não são consideradas uma leitura pontual. Para ver um exemplo usando o SDK do .NET, consulte ler um item no Azure Cosmos DB para NoSQL.

Consultas

As unidades de solicitação para consultas dependem de vários fatores. Por exemplo, o número de itens do Azure Cosmos DB carregados/retornados, o número de pesquisas em relação ao índice, o tempo de compilação da consulta, etc. detalhes. O Azure Cosmos DB garante que a mesma consulta quando executada nos mesmos dados sempre consumirá o mesmo número de unidades de solicitação, mesmo com execuções repetidas. O perfil de consulta usando métricas de execução de consulta dá uma boa ideia de como as unidades de solicitação são gastas.

Em alguns casos, você pode ver uma sequência de 200 e 429 respostas e unidades de solicitação variáveis em uma execução paginada de consultas, isso porque as consultas serão executadas o mais rápido possível com base nas RUs disponíveis. Você pode ver uma divisão de execução de consulta em várias páginas/viagens de ida e volta entre o servidor e o cliente. Por exemplo, 10.000 itens podem ser retornados como várias páginas, cada um cobrado com base no cálculo realizado para essa página. Ao somar essas páginas, você deve obter o mesmo número de RUs que obteria para toda a consulta.

Métricas para solução de problemas de consultas

O desempenho e a taxa de transferência consumidos por consultas (incluindo funções definidas pelo usuário) dependem principalmente do corpo da função. A maneira mais fácil de descobrir quanto tempo a execução da consulta é gasta no UDF e o número de RUs consumidos é habilitando as métricas de consulta. Se você usar o SDK do .NET, aqui estão exemplos de métricas de consulta retornadas pelo SDK:

Retrieved Document Count                 :               1              
Retrieved Document Size                  :           9,963 bytes        
Output Document Count                    :               1              
Output Document Size                     :          10,012 bytes        
Index Utilization                        :          100.00 %            
Total Query Execution Time               :            0.48 milliseconds 
  Query Preparation Times 
    Query Compilation Time               :            0.07 milliseconds 
    Logical Plan Build Time              :            0.03 milliseconds 
    Physical Plan Build Time             :            0.05 milliseconds 
    Query Optimization Time              :            0.00 milliseconds 
  Index Lookup Time                      :            0.06 milliseconds 
  Document Load Time                     :            0.03 milliseconds 
  Runtime Execution Times 
    Query Engine Execution Time          :            0.03 milliseconds 
    System Function Execution Time       :            0.00 milliseconds 
    User-defined Function Execution Time :            0.00 milliseconds 
  Document Write Time                    :            0.00 milliseconds 
  Client Side Metrics 
    Retry Count                          :               1              
    Request Charge                       :            3.19 RUs  

Práticas recomendadas para otimizar o custo das consultas

Considere as seguintes práticas recomendadas ao otimizar consultas para custo:

  • Colocalizar vários tipos de entidade

    Tente colocalizar vários tipos de entidade dentro de um único ou menor número de contêineres. Esse método produz benefícios não apenas de uma perspetiva de preços, mas também para a execução de consultas e transações. As consultas têm como escopo um único contêiner; e as transações atômicas em vários registros por meio de procedimentos/gatilhos armazenados têm como escopo uma chave de partição dentro de um único contêiner. A colocalização de entidades dentro do mesmo contêiner pode reduzir o número de viagens de ida e volta da rede para resolver relacionamentos entre registros. Assim, ele aumenta o desempenho de ponta a ponta, permite transações atômicas em vários registros para um conjunto de dados maior e, como resultado, reduz os custos. Se a colocação de vários tipos de entidade em um único ou menor número de contêineres for difícil para o cenário, geralmente porque você está migrando um aplicativo existente e não deseja fazer alterações de código - considere provisionar a taxa de transferência no nível do banco de dados.

  • Meça e ajuste para unidades de solicitação mais baixas/segundo de uso

    A complexidade de uma consulta afeta quantas unidades de solicitação (RUs) são consumidas para uma operação. O número de predicados, a natureza dos predicados, o número de UDFs e o tamanho do conjunto de dados de origem. Todos esses fatores influenciam o custo das operações de consulta.

O Azure Cosmos DB fornece desempenho previsível em termos de taxa de transferência e latência usando um modelo de taxa de transferência provisionada. A taxa de transferência provisionada é representada em termos de Unidades de Solicitação por segundo ou RU/s. Uma Unidade de Solicitação (RU) é uma abstração lógica sobre recursos de computação como CPU, memória, E/S, etc., que são necessários para executar uma solicitação. A taxa de transferência provisionada (RUs) é reservada e dedicada ao seu contêiner ou banco de dados para fornecer taxa de transferência e latência previsíveis. A taxa de transferência provisionada permite que o Azure Cosmos DB forneça desempenho previsível e consistente, baixa latência garantida e alta disponibilidade em qualquer escala. As unidades de solicitação representam a moeda normalizada que simplifica o raciocínio sobre quantos recursos um aplicativo precisa.

A taxa de solicitação retornada no cabeçalho da solicitação indica o custo de uma determinada consulta. Por exemplo, se uma consulta retorna 1000 itens de 1 KB, o custo da operação é 1000. Como tal, dentro de um segundo, o servidor honra apenas duas dessas solicitações antes de limitar as solicitações subsequentes. Para obter mais informações, consulte o artigo unidades de solicitação e a calculadora de unidades de solicitação.

Gravando dados

O custo de RU para escrever um item depende:

  • O tamanho do item.
  • O número de propriedades cobertas pela política de indexação e que precisavam ser indexadas.

Inserir um item de 1 KB sem indexação custa cerca de ~5,5 RUs. A substituição de um item custa duas vezes a taxa necessária para inserir o mesmo item.

Otimizando gravações

A melhor maneira de otimizar o custo de RU das operações de gravação é dimensionar corretamente seus itens e o número de propriedades que são indexadas.

  • O armazenamento de itens muito grandes no Azure Cosmos DB resulta em altas taxas de RU e pode ser considerado um antipadrão. Em particular, não armazene conteúdo binário ou grandes pedaços de texto que você não precisa consultar. Uma prática recomendada é colocar esse tipo de dados no Armazenamento de Blobs do Azure e armazenar uma referência (ou link) ao blob no item que você escreve no Azure Cosmos DB.
  • Otimizar sua política de indexação para indexar apenas as propriedades nas quais suas consultas filtram pode fazer uma enorme diferença nas RUs consumidas por suas operações de gravação. Ao criar um novo contêiner, a política de indexação padrão indexa cada propriedade encontrada em seus itens. Embora esse seja um bom padrão para atividades de desenvolvimento, é altamente recomendável reavaliar e personalizar sua política de indexação ao ir para a produção ou quando sua carga de trabalho começar a receber tráfego significativo.

Ao executar a ingestão em massa de dados, também é recomendável usar a biblioteca de executores em massa do Azure Cosmos DB, pois ela foi projetada para otimizar o consumo de RU dessas operações. Opcionalmente, você também pode usar o Azure Data Factory , que é criado nessa mesma biblioteca.

Próximos passos

Em seguida, você pode continuar para saber mais sobre otimização de custos no Azure Cosmos DB com os seguintes artigos: