Otimize a sua aplicação DB Azure Cosmos usando a limitação da taxa

Este artigo fornece aos desenvolvedores uma metodologia para classificar os pedidos de limitação à Azure Cosmos DB. A implementação deste padrão pode reduzir os erros e melhorar o desempenho global das cargas de trabalho que excedam o rendimento previsto da base de dados-alvo ou do contentor.

Pedidos que excedam a sua produção provisionada em Azure Cosmos DB podem resultar em falhas transitórias como TooManyRequests, Timeoute ServiceUn disponíveis. Normalmente, você voltaria a tentar estes pedidos quando a capacidade está disponível e seria bem sucedido. No entanto, esta abordagem pode resultar num grande número de pedidos seguindo a trajetória de erro no seu código e normalmente resulta em redução de produção.

O desempenho ideal do sistema, medido pelo custo e pelo tempo, pode ser alcançado combinando o tráfego de carga de trabalho do lado do cliente com o produção do lado do servidor.

Considere o seguinte cenário:

  • Você fornece Azure Cosmos DB com 20 K RU/segundo.
  • A sua aplicação processa um trabalho de ingestão que contém registos de 10 K, cada um dos quais custa 10 RU. A capacidade total necessária para completar este trabalho é de 100 K RU.
  • Se enviar todo o trabalho para a Azure Cosmos DB, deve esperar um grande número de falhas transitórias e um grande tampão de pedidos que deve tentar novamente. Esta condição deve-se ao facto de o número total de RUs necessários para o trabalho (100 K) ser muito superior ao máximo previsto (20 K). ~2 K dos registos serão aceites na base de dados, mas ~8 K será rejeitado. Você enviará ~8 K registos para Azure Cosmos DB em retry, dos quais ~2 K será aceite, e assim por diante. Você deve esperar que este padrão enviaria ~30 K discos em vez de 10 K de registos.
  • Em vez disso, se enviar esses pedidos uniformemente ao longo de 5 segundos, não deverá esperar falhas e uma produção global mais rápida, uma vez que cada lote estaria a 20 K ou abaixo dos 20 K previstos.

A difusão dos pedidos através de um período de tempo pode ser realizada introduzindo um mecanismo de limitação de taxas no seu código.

As RUs previstas para um contentor serão partilhadas uniformemente em todo o número de divisórias físicas. No exemplo acima, se Azure Cosmos DB fornecesse duas divisórias físicas, cada uma teria 10 K RU.

Para obter mais informações sobre Unidades de Pedido, consulte Unidades de Pedido em Azure Cosmos DB . Para obter mais informações sobre a estimativa do número de RUs consumidas pela sua carga de trabalho, consulte considerações da Unidade de Pedido. Para obter mais informações sobre a partição Azure Cosmos DB, consulte partição e escala horizontal em Azure Cosmos DB.

Metodologia

Uma abordagem para a aplicação da limitação das taxas pode ser assim:

  1. Perfile a sua aplicação para que tenha dados sobre as escritas e leia os pedidos que são utilizados.
  2. Defina todos os índices.
  3. Povoar a recolha com uma quantidade razoável de dados (podem ser dados de amostra). Se espera que a sua aplicação tenha normalmente milhões de registos, povoe-o com milhões de registos.
  4. Escreva os seus documentos representativos e grave o custo do RU.
  5. Executar as suas consultas representativas e registar o custo ru.
  6. Implemente uma função na sua aplicação para determinar o custo de qualquer pedido dado com base nas suas conclusões.
  7. Implemente um mecanismo de limitação de taxas no seu código para garantir que a soma de todas as operações enviadas para a Azure Cosmos DB num segundo não exceda a sua produção prevista.
  8. Carregue a sua aplicação e verifique se não excede a produção prevista.
  9. Retestar os custos do RU periodicamente e atualizar a sua função de custo conforme necessário.

Indexação

Ao contrário de outras bases de dados SQL e NoSQL que você pode estar familiarizado, a política de indexação padrão da Azure Cosmos DB para índices de contentores recém-criados em cada propriedade. Cada imóvel indexado aumenta o custo ru das escritas.

A política de indexação predefinida pode reduzir a latência em sistemas pesados de leitura, onde as condições de filtro de consulta estão bem distribuídas em todos os campos armazenados. Por exemplo, os sistemas em que a Azure Cosmos DB está a passar a maior parte do seu tempo a servir pesquisas ad-hoc feitas por utilizadores finais podem beneficiar.

Pode querer excluir propriedades que nunca são pesquisadas contra serem indexadas. A remoção de propriedades do índice poderia melhorar o desempenho geral do sistema (custo e tempo) para sistemas que são pesados e padrões de recuperação de registos são mais limitados.

Antes de medir quaisquer custos, deve configurar intencionalmente uma política de índice adequada para os seus casos de utilização. Além disso, se alterar mais tarde os índices, terá de refazer todos os cálculos de custos.

Sempre que possível, testar um sistema em desenvolvimento com uma carga que reflita as consultas típicas em condições normais e de pico de procura ajudará a revelar qual a política de indexação a utilizar.

Para obter mais informações sobre índices, consulte as políticas de indexação em Azure Cosmos DB.

Custo de medição

Existem alguns conceitos-chave na medição do custo:

  • Considere todos os fatores que afetam a utilização do RU, conforme descrito nas considerações da unidade de pedido.
  • Todas as leituras e escritos na sua base de dados ou contentor partilharão o mesmo rendimento a provisionado.
  • O consumo de RU é incorrido independentemente da utilização das APIs Azure Cosmos DB.
  • A estratégia de partição para uma coleção pode ter um impacto significativo no custo de um sistema. Para obter mais informações, veja Criação de partições e dimensionamento horizontal no Azure Cosmos DB.
  • Utilize documentos representativos e consultas representativas.
    • Estes são documentos e consultas que pensa estarem próximos do que o sistema operacional vai encontrar.
    • A melhor maneira de obter estes documentos e consultas representativas é instrumentar o uso da sua aplicação. É sempre melhor tomar uma decisão baseada em dados.
  • Medir os custos periodicamente.
    • Alterações de índice, o tamanho dos índices pode afetar o custo.
    • Será útil criar algum teste repetível (talvez até automatizado) dos documentos e consultas representativas.
    • Certifique-se de que os seus documentos e consultas representativas ainda são representativos.

O método para determinar o custo de um pedido, é diferente para cada API:

Escrever pedidos

O custo das operações de escrita tende a ser fácil de prever. Vai inserir registos e documentar o custo que a Azure Cosmos reportou.

Se tiver documentos de diferentes tamanhos e/ou documentos que utilizem diferentes índices, é importante medir todos eles. Poderá descobrir que os seus documentos representativos são suficientemente caros para que possa atribuir um único valor em todas as escritas. Por exemplo, se encontrar custos de 13,14 RU, 16,01 RU e 12,63 RU, poderá ter uma média desses custos para 14 RU.

Ler pedidos

O custo das operações de consulta pode ser muito mais difícil de prever pelas seguintes razões:

  • Se o seu sistema suportar consultas definidas pelo utilizador, terá de mapear as consultas recebidas nas consultas representativas para ajudar a determinar o custo. Existem várias formas que este processo pode assumir:
    • Pode ser possível combinar com as consultas exatamente. Se não houver correspondência direta, poderá ter de encontrar a consulta representativa de que está mais próxima.
    • Poderá descobrir que pode calcular um custo com base nas características da consulta. Por exemplo, pode descobrir que cada cláusula da consulta tem um determinado custo, ou que uma propriedade indexada custa "x" enquanto uma não indexada custa "y", etc.
  • O número de resultados pode variar e, a menos que tenha estatísticas, não pode prever o impacto ru da carga útil de retorno.

É provável que não tenha um único custo de operações de consulta, mas sim alguma função que avalie a consulta e calcule um custo. Se estiver a utilizar a API Core, poderá então avaliar o custo real da operação e determinar a precisão da sua estimativa (a sintonização desta estimativa pode mesmo acontecer automaticamente dentro do código).

Processamento de falhas transitórias

A sua aplicação continuará a necessitar de tratamento transitório de falhas, mesmo que implemente um mecanismo de limitação de taxas pelas seguintes razões:

  • O custo real de um pedido pode ser diferente do seu custo projetado.
  • Falhas transitórias podem ocorrer por razões que não tooManyRequests.

No entanto, a correta implementação de um mecanismo de limitação de taxas na sua aplicação reduzirá substancialmente o número de falhas transitórias.

Embora este artigo descreva a coordenação do lado do cliente e o loteamento de cargas de trabalho, existem outras técnicas que podem ser utilizadas para gerir o rendimento geral do sistema.

Dimensionamento automático

A produção de autoescalação provisida em Azure Cosmos DB permite-lhe escalar a produção (RU/s) da sua base de dados ou contentor automaticamente e instantaneamente. A produção é dimensionada com base na utilização, sem afetar a disponibilidade, latência, produção ou desempenho da carga de trabalho.

A produção de autoescalação é adequada para cargas de trabalho críticas de missão que têm padrões de tráfego variáveis ou imprevisíveis, e requerem SLAs em alto desempenho e escala.

Para obter mais informações sobre autoscalização, consulte os recipientes e bases de dados Create Azure Cosmos com produção de autoescalação .

Padrão de Redistribuição de Carga Baseado na Fila

Pode empregar uma fila que funciona como um tampão entre um cliente e a Azure Cosmos DB, a fim de suavizar cargas pesadas intermitentes que podem fazer com que o serviço falhe ou a tarefa seja mais longa.

Este padrão é prático para qualquer aplicação que utiliza os serviços sujeitos a sobrecargas. No entanto, este padrão não é útil se a aplicação espera uma resposta do serviço com a latência mínima.

Este padrão é muitas vezes bem adequado para ingerir operações.

Para obter mais informações sobre este padrão, consulte o padrão de nivelamento de carga baseado na fila.

Padrão Cache-Aside

Você pode considerar carregar dados sobre a procura em uma cache em vez de consultar Azure Cosmos DB todas as vezes. A utilização de uma cache pode melhorar o desempenho e também ajuda a manter a consistência entre os dados mantidos na cache e os dados na loja de dados subjacente.

Para obter mais informações, consulte: Cache-Aside pattern.

Padrão de Vista Materializada

Pode pré-povoar as vistas para outras coleções depois de armazenar os dados em Azure Cosmos DB quando os dados não são formatados idealmente para operações de consulta necessárias. Este padrão pode ajudar a suportar consultas eficientes e extração de dados, e melhorar o desempenho da aplicação.

Para mais informações, consulte o padrão de visualização materializada.

Passos seguintes