Otimize seu aplicativo Azure Cosmos DB usando a limitação de taxa

2024-10-02

APLICA-SE AO: NoSQL MongoDB Cassandra Gremlin Table

Este artigo fornece aos desenvolvedores uma metodologia para classificar as solicitações de limite para o Azure Cosmos DB. A implementação desse padrão pode reduzir erros e melhorar o desempenho geral de cargas de trabalho que excedem a taxa de transferência provisionada do banco de dados ou contêiner de destino.

As solicitações que excedem sua taxa de transferência provisionada no Azure Cosmos DB podem resultar em falhas transitórias, como TooManyRequests, Timeout e ServiceUnavailable. Normalmente, você tentaria essas solicitações novamente quando a capacidade estiver disponível e for bem-sucedida. No entanto, essa abordagem pode resultar em um grande número de solicitações seguindo o caminho de erro em seu código e normalmente resulta em uma taxa de transferência reduzida.

O desempenho ideal do sistema, conforme medido por custo e tempo, pode ser obtido combinando o tráfego de carga de trabalho do lado do cliente com a taxa de transferência provisionada do lado do servidor.

Considere o cenário a seguir.

Você cria uma conta do Azure Cosmos DB com 20.000 RU/segundo.
Seu aplicativo processa um trabalho de ingestão que contém 10.000 registros, cada um dos quais custa 10 RUs (unidades de solicitação). A capacidade total necessária para concluir esse trabalho é de 100.000 RU.
Se você enviar um trabalho inteiro para o Azure Cosmos DB, deverá esperar um grande número de falhas transitórias e um buffer grande de solicitações que você deve tentar novamente. Essa condição acontece porque o número total de unidades de solicitação necessárias para o trabalho (100.000) é maior do que o máximo provisionado (20.000). Aproximadamente 2.000 dos registros são aceitos no banco de dados, mas cerca de 8.000 são rejeitados. Você envia aproximadamente 8.000 registros para o Azure Cosmos DB como nova tentativa, dos quais cerca de 2.000 são aceitos e assim por diante. Você deve esperar que esse padrão envie ~30.000 registros em vez de 10.000 registros.
Em vez disso, você decide enviar essas solicitações de maneira uniforme ao longo de 5 segundos. Nesse caso, você não deverá esperar falhas e uma produtividade geral mais rápida, pois cada lote estaria em ou abaixo das 20.000 provisionadas.

A distribuição das solicitações por um período de tempo pode ser realizada introduzindo um mecanismo de limitação de taxa em seu código.

As RUs provisionadas para um contêiner serão compartilhadas de maneira precisa entre o número de partições físicas. No exemplo anterior, se o Azure Cosmos DB provisionou duas partições físicas, cada uma teria 10 mil RU.

Para obter mais informações sobre RUs (unidades de solicitação), confira Unidades de solicitação no Azure Cosmos DB. Para obter mais informações sobre como estimar o número de RUs consumidas pela carga de trabalho, consulte Considerações sobre unidade de solicitação. Para obter mais informações sobre o particionamento no Azure Cosmos DB, consulte Partição e escala horizontal no Azure Cosmos DB.

Metodologia

Uma abordagem para implementar a limitação de taxa pode ter esta aparência:

Perfil do aplicativo para que você tenha dados sobre as gravações e as solicitações de leitura que são usadas.
Defina todos os índices.
Preencha a coleção com uma quantidade razoável de dados (podem ser dados de exemplo). Se você espera que seu aplicativo normalmente tenha milhões de registros, popule-o com milhões de registros.
Escreva seus documentos representativos e grave o custo de RU.
Execute suas consultas representativas e grave o custo de RU.
Implemente uma função em seu aplicativo para determinar o custo de qualquer solicitação determinada com base em suas descobertas.
Implemente um mecanismo de limitação de fluxo em seu código para garantir que a soma de todas as operações enviadas ao Azure Cosmos DB em um segundo não exceda sua produtividade provisionada.
Faça um teste de carga em seu aplicativo e verifique se você não excede a taxa de transferência provisionada.
Teste novamente os custos de RU periodicamente e atualize sua função de custo conforme necessário.

Indexação

Ao contrário de outros bancos de dados SQL e NoSQL que você possa conhecer, a política de indexação padrão do Azure Cosmos DB para contêineres recém-criados indexa todas as propriedades. Cada propriedade indexada aumenta o custo de RU de gravações.

A política de indexação padrão pode reduzir a latência em sistemas de leitura intensa em que as condições de filtro de consulta são bem distribuídas em todos os campos armazenados. Por exemplo, os sistemas em que o Azure Cosmos DB está gastando a maior parte do tempo atendendo pesquisas ad hoc criadas pelo usuário final podem se beneficiar.

Talvez você queira excluir as propriedades que nunca são pesquisadas em relação a serem indexadas. A remoção de propriedades do índice pode melhorar o desempenho geral do sistema (custo e tempo) para sistemas que são de gravação pesada e os padrões de recuperação de registros são mais restritos.

Antes de medir qualquer custo, você deve configurar intencionalmente uma política de índice apropriada para seus casos de uso. Além disso, se você alterar os índices posteriormente, será necessário executar novamente todos os cálculos de custo.

Sempre que possível, testar um sistema em desenvolvimento com uma carga que reflete consultas típicas em condições normais e de pico de demanda ajuda a revelar qual política de indexação usar.

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

Medição do custo

Há alguns conceitos importantes ao medir o custo:

Considere todos os fatores que afetam o uso de RU, conforme descrito em considerações de unidade de solicitação.
Todas as leituras e gravações em seu banco de dados ou contêiner irão compartilhar a mesma taxa de transferência provisionada.
O consumo de RU é incorrido independentemente das APIs de Azure Cosmos DB que estão sendo usadas.
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, confira Particionamento e dimensionamento horizontal no Azure Cosmos DB.
Use documentos representativos e consultas representativas.
- Esses são documentos e consultas que você considera que estão próximos do que o sistema operacional encontrará.
- A melhor maneira de obter esses documentos e consultas representativos é instrumentar o uso do seu aplicativo. É sempre melhor tomar uma decisão orientada por dados.
Meça os custos periodicamente.
- Alterações de índice, o tamanho dos índices, pode afetar o custo.
- É útil criar algum teste repetível (talvez até mesmo automatizado) dos documentos e das consultas representativas.
- Verifique se seus documentos e consultas representativos ainda são representativos.

O método para determinar o custo de uma solicitação é diferente para cada API:

Solicitações de gravação

O custo das operações de gravação tende a ser fácil de prever. Você insere registros e documenta o custo relatado pelo Azure Cosmos DB.

Se você tiver documentos de tamanho e/ou documentos diferentes que usam índices diferentes, é importante medir todos eles. Talvez você ache que seus documentos representativos estão próximos o suficiente no custo para atribuir um único valor em todas as gravações. Por exemplo, se você encontrar custos de 13,14 RU, 16,01 RU e 12,63 RU, poderá fazer a média desses custos para 14 RU.

Solicitações de leitura

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

Se o sistema oferece suporte a consultas definidas pelo usuário, é necessário mapear as consultas de entrada para as consultas representativas para ajudar a determinar o custo. Há várias formas que esse processo pode assumir:
- Talvez seja possível corresponder exatamente às consultas. Se não houver nenhuma combinação direta, talvez seja preciso encontrar a consulta representativa mais próxima a ela.
- Você pode descobrir que pode calcular um custo com base nas características da consulta. Por exemplo, você 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 você tenha estatísticas, não é possível prever o impacto da RU do conteúdo de retorno.

É provável que você 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 você estiver usando a API para NoSQL, poderá avaliar o custo real da operação e determinar a precisão da estimativa (o ajuste dessa estimativa pode ocorrer automaticamente dentro do código).

Tratamento de falhas transitórias

Seu aplicativo ainda precisará de tratamento de falhas transitórias mesmo se você implementar um mecanismo de limitação de taxa pelos seguintes motivos:

O custo real de uma solicitação pode ser diferente do custo projetado.
As falhas transitórias podem ocorrer por motivos diferentes de TooManyRequests.

No entanto, a implementação adequada de um mecanismo de limitação de taxa em seu aplicativo reduzirá substancialmente o número de falhas transitórias.

Embora este artigo descreva a coordenação do lado do cliente e o envio em lote de cargas de trabalho, há outras técnicas que podem ser empregadas para gerenciar a taxa de transferência geral do sistema.

Dimensionamento automático

A taxa de transferência provisionada de dimensionamento automático no Microsoft Azure Cosmos DB permite que você dimensione a taxa de transferência (RU/s) do seu banco de dados ou contêiner de forma automática e instantânea. A taxa de transferência é dimensionada com base no uso, sem afetar a disponibilidade, a latência, a taxa de transferência ou o desempenho da carga de trabalho.

A taxa de transferência provisionada de dimensionamento automático é adequada para cargas de trabalho críticas que têm padrões de tráfego variáveis ou imprevisíveis e exigem Contratos de Nível de Serviço (SLAs) para alto desempenho e escala.

Para obter mais informações sobre o dimensionamento automático, consulte Criar contêineres e bancos de dados do Azure Cosmos DB com produtividade de dimensionamento automático.

Padrão de nivelamento de carga baseado em fila

Use uma fila que funcione como um buffer entre um cliente e o Azure Cosmos DB para simplificar sobrecargas intermitentes que podem causar falha no serviço ou a fazer a tarefa atingir o tempo limite.

Esse padrão é útil para qualquer aplicativo que use serviços sujeitos a sobrecarga. Esse padrão não é útil se o aplicativo esperar uma resposta do serviço com latência mínima.

Esse padrão geralmente é adequado para operações de ingestão.

Para obter mais informações, consulte Padrão de nivelamento de carga baseado em fila.

Padrão Cache-Aside

Você pode considerar carregar dados sob demanda em um cache em vez de consultar Azure Cosmos DB todas as vezes. Isso pode melhorar o desempenho e também ajuda a manter a consistência entre dados mantidos no cache e os dados no armazenamento de dados subjacente.

Para saber mais, confira o Padrão cache-aside.

Padrão de Exibição Materializada

Você pode pré-preencher exibições em outras coleções depois de armazenar os dados no Azure Cosmos DB quando os dados não estiverem formatados de maneira ideal para as operações de consulta necessárias. Isso pode ajudar a dar suporte a consultas e extração de dados eficientes, além de melhorar o desempenho do aplicativo.

Para obter mais informações, consulte Padrão de exibição materializada.