Otimizar a aplicação Azure Cosmos DB com a limitação de taxas

APLICA-SE A: NoSQL MongoDB Cassandra Gremlin Tabela

Este artigo fornece aos programadores uma metodologia para classificar os pedidos de limite para o Azure Cosmos DB. A implementação deste padrão pode reduzir os erros e melhorar o desempenho geral das cargas de trabalho que excedem o débito aprovisionado da base de dados de destino ou do contentor.

Os pedidos que excedam o débito aprovisionado no Azure Cosmos DB podem resultar em falhas transitórias, como TooManyRequests, Tempo Limite e ServiceUnavailable. Normalmente, repetiria estes pedidos quando a capacidade está disponível e seria bem-sucedida. No entanto, esta abordagem pode resultar num grande número de pedidos ao seguir o caminho de erro no código e, normalmente, resulta num débito reduzido.

O desempenho ideal do sistema, medido pelo custo e pelo tempo, pode ser alcançado ao corresponder o tráfego da carga de trabalho do lado do cliente ao débito aprovisionado do lado do servidor.

Considere o seguinte cenário:

  • Aprovisiona o Azure Cosmos DB com 20 K RU/segundo.
  • A sua aplicação processa uma tarefa de ingestão que contém 10 registos K, cada um dos quais custa 10 RU. A capacidade total necessária para concluir esta tarefa é de 100 K RU.
  • Se enviar toda a tarefa para o Azure Cosmos DB, deverá esperar um grande número de falhas transitórias e uma grande memória intermédia de pedidos que tem de repetir. Esta condição deve-se ao facto de o número total de RUs necessárias para a tarefa (100 K) ser muito maior do que o máximo aprovisionado (20 K). ~2 K dos registos serão aceites na base de dados, mas ~8 K será rejeitado. Irá enviar ~8 K registos para o Azure Cosmos DB ao tentar novamente, dos quais ~2 K serão aceites e assim sucessivamente. Deverá esperar que este padrão envie ~30 K registos em vez de 10 K de registos.
  • Em vez disso, se enviar esses pedidos uniformemente durante 5 segundos, não deverá esperar falhas e débito globalmente mais rápido, uma vez que cada lote estaria em ou abaixo dos 20 K aprovisionados.

A propagação dos pedidos por um período de tempo pode ser efetuada através da introdução de um mecanismo de limitação de taxa no seu código.

As RUs aprovisionadas para um contentor serão partilhadas uniformemente no número de partições físicas. No exemplo acima, se o Azure Cosmos DB aprovisionasse duas partições físicas, cada uma teria 10 K RU.

Para obter mais informações sobre Unidades de Pedido, veja Unidades de Pedido no Azure Cosmos DB . Para obter mais informações sobre a estimativa do número de RUs consumidas pela carga de trabalho, veja Considerações da Unidade de Pedido. Para obter mais informações sobre a criação de partições do Azure Cosmos DB, veja Criação de partições e dimensionamento horizontal no Azure Cosmos DB.

Metodologia

Uma abordagem para implementar a limitação de taxas pode ter o seguinte aspeto:

  1. Faça o perfil da sua aplicação para que tenha dados sobre as escritas e pedidos de leitura que são utilizados.
  2. Definir todos os índices.
  3. Preencha a coleção com uma quantidade razoável de dados (podem ser dados de exemplo). Se espera que a sua aplicação tenha normalmente milhões de registos, preencha-a com milhões de registos.
  4. Escreva os seus documentos representativos e registe o custo da RU.
  5. Execute as consultas representativas e registe o custo da RU.
  6. Implemente uma função na sua aplicação para determinar o custo de um determinado pedido com base nas suas conclusões.
  7. Implemente um mecanismo de limitação de taxa no seu código para garantir que a soma de todas as operações enviadas para o Azure Cosmos DB num segundo não exceda o débito aprovisionado.
  8. Teste a carga da aplicação e verifique se não excede o débito aprovisionado.
  9. Volte a atestar os custos de RU periodicamente e atualize a função de custo conforme necessário.

Indexação

Ao contrário de outras bases de dados SQL e NoSQL com as quais pode estar familiarizado, a política de indexação predefinida do Azure Cosmos DB para contentores recentemente criados indexa todas as propriedades. Cada propriedade indexada aumenta o custo de 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 o Azure Cosmos DB está a passar a maior parte do tempo a servir pesquisas ad-hoc criadas pelo utilizador final podem beneficiar.

Poderá querer excluir propriedades que nunca são pesquisadas contra a indexação. A remoção de propriedades do índice pode melhorar o desempenho geral do sistema (custo e tempo) para sistemas que são pesados de escrita e os padrões de obtenção de registos são mais restritos.

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 os índices posteriormente, terá de executar novamente todos os cálculos de custos.

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

Para obter mais informações sobre índices, veja Políticas de indexação no Azure Cosmos DB.

Medir o custo

Existem alguns conceitos fundamentais ao medir o custo:

  • Considere todos os fatores que afetam a utilização de RU, conforme descrito em considerações de unidades de pedido.
  • Todas as leituras e escritas na sua base de dados ou contentor partilharão o mesmo débito aprovisionado.
  • O consumo de RU é incorrido independentemente das APIs do Azure Cosmos DB que estão a ser utilizadas.
  • A estratégia de partição de 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 irá encontrar.
    • A melhor forma de obter estes documentos e consultas representativos é instrumentar a utilização da sua aplicação. É sempre melhor tomar uma decisão baseada em dados.
  • Medir os custos periodicamente.
    • Alterações ao índice, o tamanho dos índices pode afetar o custo.
    • Será útil criar algum teste repetível (talvez até automatizado) dos documentos e consultas representativos.
    • Certifique-se de que os seus documentos e consultas representativos ainda são representativos.

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

Pedidos de escrita

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

Se tiver documentos de tamanho e/ou documentos diferentes que irão utilizar índices diferentes, é importante medi-los a todos. Poderá constatar que os seus documentos representativos estão suficientemente próximos do custo que pode atribuir a um único valor em todas as escritas. Por exemplo, se tiver encontrado custos de 13,14 RU, 16,01 RU e 12,63 RU, poderá ter uma média desses custos para 14 RU.

Pedidos de leitura

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

  • Se o seu sistema suportar consultas definidas pelo utilizador, terá de mapear as consultas recebidas para as consultas representativas para ajudar a determinar o custo. Existem várias formas que este processo pode assumir:
    • Pode ser possível corresponder exatamente às consultas. Se não existir uma correspondência direta, poderá ter de encontrar a consulta representativa à qual está mais próxima.
    • Poderá descobrir que pode calcular um custo com base nas características da consulta. Por exemplo, pode verificar 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 da RU a partir do payload de devolução.

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

Processamento de falhas transitórias

A aplicação continuará a precisar de processamento transitório de falhas, mesmo que implemente um mecanismo de limitação de taxa pelos seguintes motivos:

  • O custo real de um pedido pode ser diferente do custo previsto.
  • As falhas transitórias podem ocorrer por motivos diferentes de TooManyRequests.

No entanto, implementar corretamente 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 lote de cargas de trabalho, existem outras técnicas que podem ser utilizadas para gerir o débito geral do sistema.

Dimensionamento automático

O débito aprovisionado do dimensionamento automático no Azure Cosmos DB permite-lhe dimensionar o débito (RU/s) da base de dados ou do contentor de forma automática e instantânea. O débito é dimensionado com base na utilização, sem afetar a disponibilidade, a latência, o débito ou o desempenho da carga de trabalho.

O débito aprovisionado de dimensionamento automático é adequado para cargas de trabalho fundamentais para a atividade que têm padrões de tráfego variáveis ou imprevisíveis e exigem SLAs em elevado desempenho e dimensionamento.

Para obter mais informações sobre o dimensionamento automático, veja Create Azure Cosmos DB containers and databases with autoscale throughput (Criar contentores e bases de dados do Azure Cosmos DB com débito de dimensionamento automático ).

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

Pode utilizar uma fila que funciona como uma memória intermédia entre um cliente e o Azure Cosmos DB para suavizar cargas pesadas intermitentes que podem fazer com que o serviço falhe ou que a tarefa exceda o tempo limite.

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 esperar uma resposta do serviço com latência mínima.

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

Para obter mais informações sobre este padrão, veja Padrão de Redistribuição de Carga Baseada em Filas.

Padrão Cache-Aside

Pode considerar carregar dados a pedido para uma cache em vez de consultar sempre o Azure Cosmos DB. 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 no arquivo de dados subjacente.

Para obter mais informações, veja Padrão Cache-Aside.

Padrão de Vista Materializada

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

Para obter mais informações, veja Padrão de Vista Materializada.

Passos seguintes