Otimizar o custo de solicitação no Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL MongoDB Cassandra Gremlin Table

Este artigo descreve como as solicitações de leitura e gravação são convertidas em Unidades de Solicitação e como otimizar o custo dessas solicitações. As operações de leitura incluem leituras de ponto e consultas. As operações de gravação incluem inserir, substituir, excluir e executar upsert de itens.

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

Medindo o preço da RU de uma solicitação

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

Leitura de dados: leituras e consultas de ponto

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

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

Função do nível de consistência

Ao usar os níveis de consistência de desatualização limitada ou forte, o custo de RU de qualquer operação de leitura (leitura de ponto ou consulta) é duplicado.

Leituras de ponto

O único fator que afeta o preço da RU de um ponto lido (além do nível de consistência usado) é o tamanho do item recuperado. A tabela a seguir mostra o custo de RU de leituras de ponto para itens de 1 KB e 100 KB de tamanho.

Tamanho do item Custo de uma leitura de ponto
1 KB 1 RU
100 KB 10 RUs

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

Observação

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

Consultas

As unidades de solicitação para consultas dependem de uma série de fatores. Por exemplo, o número de itens carregados/retornados do Azure Cosmos DB, o número de pesquisas no índice, o tempo de compilação de consulta e outros 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ê poderá ver uma sequência de 200 e 429 respostas, e unidades de solicitação de variável em uma execução paginada de consultas, porque as consultas serão executadas o mais rápido possível com base nas RUs disponíveis. Você poderá ver uma execução de consulta se desmembrar em várias páginas/viagens de ida e volta entre servidor e cliente. Por exemplo, 10.000 itens poderão ser retornados como várias páginas, cada uma cobrada com base no cálculo executado para a página. Quando você soma essas páginas, deve obter o mesmo número de RUs que receberia de toda a consulta.

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

O desempenho e a taxa de transferência consumidos pelas consultas (incluindo as funções definidas pelo usuário) dependem principalmente do corpo da função. A maneira mais fácil de descobrir quanto tempo é gasto na execução da consulta nas UDFs e o número de RUs consumidas é habilitando as métricas de consulta. Se você usar o SDK do .NET, aqui estão as métricas de consulta de exemplo 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  

Melhores práticas para otimizar consultas pelo custo

Considere as seguintes melhores práticas ao otimizar consultas pelo custo:

  • Colocar vários tipos de entidade

    Tente colocar vários tipos de entidade em um único contêiner ou na menor quantidade possível. Esse método gera benefícios não apenas em termos de preço, mas também em termos de transações e execução da consulta. As consultas têm como escopo um único contêiner, e as transações atômicas em vários registros por meio de procedimentos armazenados/gatilhos têm como escopo uma chave de partição em um único contêiner. A colocação de entidades no mesmo contêiner pode reduzir o número de viagens de ida e volta na rede para resolver relacionamentos entre registros. Assim, ela aumenta o desempenho de ponta a ponta, permite transações atômicas em vários registros em um conjunto de dados maior e, como resultado, reduz os custos. Se a colocação de vários tipos de entidade em um único contêiner (ou poucos) costuma ser difícil em seu cenário, talvez porque você esteja migrando um aplicativo existente e não deseje fazer alterações de código, considere provisionar a taxa de transferência no nível do banco de dados.

  • Medir e ajustar para o uso mais baixo de unidades/segundo da solicitação

    A complexidade de uma consulta afeta a quantidade de RUs (unidades de solicitação) consumida 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 um 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 de recursos de computação como CPU, memória, e/s, etc. que são necessárias para executar uma solicitação. Taxa de transferência (RUs) é reservada e dedicada ao contêiner ou banco de dados para fornecer latência e taxa de transferência previsível. Taxa de transferência provisionada permite que o Azure Cosmos DB forneça um desempenho previsível e consistente, a garantia de baixa latência e alta disponibilidade em qualquer escala. Unidades de solicitação representam a moeda normalizada que simplifica o raciocínio sobre quantos recursos um aplicativo precisa.

A carga de solicitação retornada no cabeçalho da solicitação indica o custo de uma determinada consulta. Por exemplo, se uma consulta retorna 1.000 itens de 1 KB, o custo da operação é 1.000. Assim, em um segundo, o servidor mantém apenas duas dessas solicitações antes de limitar as solicitações subsequentes. Para saber mais, consulte o artigo Unidades de solicitação e a calculadora de unidades de solicitação.

Gravação de dados

O custo de RU para escrever um item depende de:

Inserir um item de 1 KB sem indexar custos em torno de aproximadamente 5,5 RUs. Substituir um item custa duas vezes o preço necessário para inserir o mesmo item.

Otimização de gravações

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

  • Armazenar itens muito grandes no Azure Cosmos DB resulta em preços de RU altos e pode ser considerado um antipadrão. Em particular, não armazene conteúdo binário ou grandes partes 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ê grava no Azure Cosmos DB.
  • Otimizar a política de indexação para indexar apenas as propriedades que as consultas filtram pode fazer uma grande diferença nas RUs consumidas pelas operações de gravação. Ao criar um novo contêiner, a política de indexação padrão indexa cada e todas as propriedades encontradas em seus itens. Embora esse seja um bom padrão para atividades de desenvolvimento, é altamente recomendável reavaliar e personalizar a política de indexação ao passar para a produção ou quando a 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 executor em massa do Azure Cosmos DB, pois ele foi projetado para otimizar o consumo de RU dessas operações. Você também tem a opção de usar o Azure Data Factory, que é criado na mesma biblioteca.

Próximas etapas

A seguir, você poderá saber mais sobre a otimização de custos no Azure Cosmos DB nos seguintes artigos: