Otimizar o custo de pedido no Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL MongoDB Cassandra Gremlin Tabela

Este artigo descreve como os pedidos de leitura e escrita se traduzem em Unidades de Pedido e como otimizar o custo destes pedidos. As operações de leitura incluem leituras de pontos e consultas. As operações de escrita incluem inserir, substituir, eliminar e upsert de itens.

O Azure Cosmos DB oferece um conjunto avançado de operações de base de dados que operam nos itens num contentor. 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 gerir recursos de hardware, pode considerar uma Unidade de Pedido (RU) como uma única medida para os recursos necessários para realizar várias operações de base de dados para servir um pedido.

Medir o custo de RU de um pedido

É importante medir o custo de RU dos seus pedidos para compreender o custo real e também avaliar a eficácia das suas otimizações. Pode obter este custo com o portal do Azure ou inspecionar a resposta enviada do Azure Cosmos DB através de um dos SDKs. Veja Localizar o custo da unidade de pedido no Azure Cosmos DB para obter instruções detalhadas sobre como o conseguir.

Ler dados: leituras e consultas de pontos

Normalmente, as operações de leitura no Azure Cosmos DB são ordenadas do mais rápido/mais eficiente para mais lento/menos eficiente em termos de consumo de RUs da seguinte forma:

  • Leituras de pontos (pesquisa de chave/valor num único ID de item e chave de partição).
  • Consultar com uma cláusula de filtro numa única chave de partição.
  • 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 utilizar os níveis de consistência de estagnação forte ou vinculada, o custo de RU de qualquer operação de leitura (leitura ou consulta do ponto) é duplicado.

Leituras de pontos

O único fator que afeta a carga de RU de um ponto de leitura (para além do nível de consistência utilizado) é o tamanho do item obtido. A tabela seguinte mostra o custo de RU das leituras de pontos para itens com 1 KB e 100 KB de tamanho.

Tamanho do Item Custo de um ponto de leitura
1 KB 1 RU
100 KB 10 RUs

Uma vez que as leituras de pontos (pesquisas de chave/valor no ID do item e chave de partição) são o tipo de leitura mais eficiente, deve certificar-se de que o ID do item tem um valor significativo para que possa obter os seus itens com um ponto de leitura (em vez de uma consulta) sempre que possível.

Nota

Na API para NoSQL, as leituras de pontos só podem ser feitas com a API REST ou os SDKs. As consultas que filtram o ID e a chave de partição de um item não são consideradas um ponto de leitura. Para ver um exemplo com o SDK .NET, veja Ler um item no Azure Cosmos DB para NoSQL.

Consultas

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

Em alguns casos, poderá ver uma sequência de 200 e 429 respostas e unidades de pedido variável numa execução paginada de consultas, ou seja, as consultas serão executadas o mais rapidamente possível com base nas RUs disponíveis. Poderá ver uma execução de consultas a entrar em múltiplas páginas/viagens de ida e volta entre o servidor e o cliente. Por exemplo, 10 000 itens podem ser devolvidos como múltiplas páginas, cada um cobrado com base na computação realizada para essa página. Quando soma estas páginas, deverá obter o mesmo número de RUs que obteria para toda a consulta.

Métricas para resolver problemas de consultas

O desempenho e o débito consumidos pelas consultas (incluindo funções definidas pelo utilizador) dependem principalmente do corpo da função. A forma mais fácil de descobrir quanto tempo a execução da consulta é gasta no UDF e o número de RUs consumidas é ativando as métricas de consulta. Se utilizar o SDK .NET, eis as métricas de consulta de exemplo devolvidas 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 custos de consultas

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

  • Colocar vários tipos de entidades em colocação

    Tente colocar vários tipos de entidade num único ou menor número de contentores. Este método beneficia não só de uma perspetiva de preços, mas também de execução de consultas e transações. As consultas estão confinadas a um único contentor; e as transações atómicas em vários registos através de procedimentos/acionadores armazenados estão no âmbito de uma chave de partição num único contentor. Colocar entidades no mesmo contentor pode reduzir o número de viagens de ida e volta de rede para resolver relações entre registos. Assim, aumenta o desempenho ponto a ponto, permite transações atómicas em vários registos para um conjunto de dados maior e, como resultado, reduz os custos. Se a colocação de vários tipos de entidades num único ou menor número de contentores for difícil para o seu cenário, normalmente porque está a migrar uma aplicação existente e não quer fazer alterações de código, deve considerar o débito de aprovisionamento ao nível da base de dados.

  • Medir e otimizar para unidades de pedido inferior/segunda utilização

    A complexidade de uma consulta afeta o número de unidades de pedido (RUs) 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 estes fatores influenciam o custo das operações de consulta.

O Azure Cosmos DB proporciona um desempenho previsível em termos de débito e latência através de um modelo de débito aprovisionado. O débito aprovisionado é representado em termos de Unidades de Pedido por segundo ou RU/s. Uma Unidade de Pedido (RU) é uma abstração lógica sobre recursos de computação, como CPU, memória, E/S, etc. que são necessárias para efetuar um pedido. O débito aprovisionado (RUs) é reservado e dedicado ao seu contentor ou base de dados para fornecer débito e latência previsíveis. O débito aprovisionado permite ao Azure Cosmos DB proporcionar um desempenho previsível e consistente, baixa latência garantida e elevada disponibilidade em qualquer escala. As unidades de pedido representam a moeda normalizada que simplifica o raciocínio sobre quantos recursos uma aplicação precisa.

O custo do pedido devolvido no cabeçalho do pedido indica o custo de uma determinada consulta. Por exemplo, se uma consulta devolver 1000 itens de 1 KB, o custo da operação é 1000. Como tal, num segundo, o servidor honra apenas dois desses pedidos antes de a taxa limitar os pedidos subsequentes. Para obter mais informações, veja o artigo unidades de pedido e a calculadora da unidade de pedido.

Escrever dados

O custo de RU da escrita de um item depende de:

  • O tamanho do item.
  • O número de propriedades abrangidas pela política de indexação e necessário para ser indexado.

Inserir um item de 1 KB sem indexar custa cerca de ~5,5 RUs. Substituir um item custa duas vezes o custo necessário para inserir o mesmo item.

Otimizar escritas

A melhor forma de otimizar o custo de RU das operações de escrita é atribuir direitos aos seus itens e ao número de propriedades que são indexadas.

  • Armazenar itens muito grandes no Azure Cosmos DB resulta em custos elevados de RU e pode ser considerado um anti-padrão. Em particular, não armazene conteúdo binário ou grandes partes de texto em que não precisa de consultar. Uma melhor prática é colocar este tipo de dados no Armazenamento de Blobs do Azure e armazenar uma referência (ou ligação) para o blob no item que escreve no Azure Cosmos DB.
  • Otimizar a política de indexação para indexar apenas as propriedades que as suas consultas filtram pode fazer uma enorme diferença nas RUs consumidas pelas suas operações de escrita. Ao criar um novo contentor, a política de indexação predefinida indexa cada propriedade encontrada nos seus itens. Embora esta seja uma boa predefinição para atividades de desenvolvimento, é altamente recomendado reavaliar e personalizar a política de indexação quando for para produção ou quando a carga de trabalho começar a receber tráfego significativo.

Ao realizar a ingestão em massa de dados, também é recomendado utilizar a biblioteca do executor em massa do Azure Cosmos DB , uma vez que foi concebida para otimizar o consumo de RU dessas operações. Opcionalmente, também pode utilizar Azure Data Factory que se baseia nessa mesma biblioteca.

Passos seguintes

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