Partilhar via

Otimizar o débito aprovisionado no Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL MongoDB Cassandra Gremlin Tabela

Ao oferecer um modelo de taxa de transferência provisionada, o Azure Cosmos DB oferece desempenho previsível em qualquer escala. Reservar ou provisionar a taxa de transferência com antecedência elimina o "efeito vizinho barulhento" no seu desempenho. Você especifica a quantidade exata de taxa de transferência necessária e o Azure Cosmos DB garante a taxa de transferência configurada, apoiada pelo SLA.

Você pode começar com uma taxa de transferência mínima de 400 RU/seg e escalar para dezenas de milhões de solicitações por segundo ou até mais. Cada solicitação que você emite em seu contêiner ou banco de dados do Azure Cosmos DB, como uma solicitação de leitura, solicitação de gravação, solicitação de consulta, procedimentos armazenados tem um custo correspondente que é deduzido da sua taxa de transferência provisionada. Se você provisionar 400 RU/s e emitir uma consulta que custa 40 RUs, poderá emitir 10 consultas desse tipo por segundo. Qualquer solicitação além disso tem taxa limitada e você deve tentar novamente a solicitação. Se você estiver usando drivers de cliente, eles suportam a lógica de repetição automática.

Pode aprovisionar o débito em bases de dados ou contentores e cada estratégia pode ajudá-lo a poupar nos custos, consoante o cenário.

Otimize provisionando a taxa de transferência em diferentes níveis

  • Se você provisionar a taxa de transferência em um banco de dados, todos os contêineres, por exemplo, coleções/tabelas/gráficos dentro desse banco de dados, poderão compartilhar a taxa de transferência com base na carga. A taxa de transferência reservada no nível do banco de dados é compartilhada de forma desigual, dependendo da carga de trabalho em um conjunto específico de contêineres.

  • Se você provisionar a taxa de transferência em um contêiner, a taxa de transferência será garantida para esse contêiner, apoiada pelo SLA. A escolha de uma chave de partição lógica é crucial para a distribuição uniforme da carga em todas as partições lógicas de um contêiner. Consulte Artigos de particionamento e dimensionamento horizontal para obter mais detalhes.

A seguir estão algumas diretrizes para decidir sobre uma estratégia de taxa de transferência provisionada:

Considere provisionar a taxa de transferência em um banco de dados do Azure Cosmos DB (contendo um conjunto de contêineres) se:

  1. Você tem algumas dúzias de contêineres do Azure Cosmos DB e deseja compartilhar a taxa de transferência em alguns ou em todos eles.

  2. Você está migrando de um banco de dados de locatário único projetado para ser executado em VMs hospedadas em IaaS ou no local, por exemplo, NoSQL ou bancos de dados relacionais para o Azure Cosmos DB. E se você tiver muitas coleções/tabelas/gráficos e não quiser fazer nenhuma alteração no seu modelo de dados. Observe que talvez seja necessário comprometer alguns dos benefícios oferecidos pelo Azure Cosmos DB se não estiver atualizando seu modelo de dados ao migrar de um banco de dados local. É recomendável que você sempre reavalie seu modelo de dados para obter o máximo em termos de desempenho e também para otimizar os custos.

  3. Você deseja absorver picos não planejados em cargas de trabalho em virtude da taxa de transferência agrupada no nível do banco de dados sujeita a picos inesperados na carga de trabalho.

  4. Em vez de definir a taxa de transferência específica em contêineres individuais, você se preocupa em obter a taxa de transferência agregada em um conjunto de contêineres dentro do banco de dados.

Considere provisionar a taxa de transferência em um contêiner individual se:

  1. Você tem alguns contêineres do Azure Cosmos DB. Como o Azure Cosmos DB é independente de esquema, um contêiner pode conter itens que têm esquemas heterogêneos e não exige que os clientes criem vários tipos de contêiner, um para cada entidade. É sempre uma opção a considerar se agrupar separados, digamos, 10-20 contêineres em um único contêiner faz sentido. Com um mínimo de 400 RUs para contêineres, agrupar todos os 10-20 contêineres em um poderia ser mais econômico.

  2. Você deseja controlar a taxa de transferência em um contêiner específico e obter a taxa de transferência garantida em um determinado contêiner apoiado pelo SLA.

Considere um híbrido das duas estratégias acima:

  1. Como mencionado anteriormente, o Azure Cosmos DB permite que você misture e combine as duas estratégias acima, portanto, agora você pode ter alguns contêineres no banco de dados do Azure Cosmos DB, que podem compartilhar a taxa de transferência provisionada no banco de dados, bem como alguns contêineres dentro do mesmo banco de dados, que podem ter quantidades dedicadas de taxa de transferência provisionada.

  2. Você pode aplicar as estratégias acima para criar uma configuração híbrida, onde você tem a taxa de transferência provisionada no nível do banco de dados com alguns contêineres com taxa de transferência dedicada.

Conforme mostrado na tabela a seguir, dependendo da escolha da API, você pode provisionar a taxa de transferência em diferentes granularidades.

API Para taxa de transferência compartilhada , configure Para uma taxa de transferência dedicada , configure
API para NoSQL Base de Dados Contentor
API do Azure Cosmos DB para MongoDB Base de Dados Coleção
API para Cassandra Espaço-chave Tabela
API para Gremlin Conta de base de dados Gráfico
API para Tabela Conta de base de dados Tabela

Ao provisionar a taxa de transferência em diferentes níveis, você pode otimizar seus custos com base nas características de sua carga de trabalho. Como mencionado anteriormente, você pode programaticamente e a qualquer momento aumentar ou diminuir sua taxa de transferência provisionada para contêineres individuais ou coletivamente em um conjunto de contêineres. Ao dimensionar elasticamente a taxa de transferência à medida que sua carga de trabalho muda, você paga apenas pela taxa de transferência que configurou. Se o contêiner ou um conjunto de contêineres estiver distribuído em várias regiões, a taxa de transferência configurada no contêiner ou em um conjunto de contêineres certamente será disponibilizada em todas as regiões.

Otimizar os pedidos com a limitação da taxa

Para cargas de trabalho que não são sensíveis à latência, você pode provisionar menos taxa de transferência e permitir que o aplicativo manipule a limitação de taxa quando a taxa de transferência real exceder a taxa de transferência provisionada. O servidor terminará preventivamente a solicitação com RequestRateTooLarge (código de status HTTP 429) e retornará o x-ms-retry-after-ms cabeçalho indicando a quantidade de tempo, em milissegundos, que o usuário deve aguardar antes de tentar novamente a solicitação.

HTTP Status 429, 
 Status Line: RequestRateTooLarge 
 x-ms-retry-after-ms :100

Lógica de repetição em SDKs

Os SDKs nativos (.NET/.NET Core, Java, Node.js e Python) capturam implicitamente essa resposta, respeitam o cabeçalho retry-after especificado pelo servidor e tentam novamente a solicitação. A menos que sua conta seja acessada simultaneamente por vários clientes, a próxima tentativa será bem-sucedida.

Se você tiver mais de um cliente operando cumulativamente acima da taxa de solicitação, a contagem de repetições padrão, que atualmente está definida como 9, pode não ser suficiente. Nesses casos, o cliente lança um RequestRateTooLargeException com o código de status 429 para o aplicativo. A contagem de tentativas padrão pode ser alterada definindo o RetryOptions na instância ConnectionPolicy. Por padrão, o RequestRateTooLargeException com o código de status 429 é retornado após um tempo de espera cumulativo de 30 segundos se a solicitação continuar a operar acima da taxa de solicitação. Isso ocorre mesmo quando a contagem de tentativas atual é menor do que a contagem máxima de tentativas, seja o padrão de 9 ou um valor definido pelo usuário.

MaxRetryAttemptsOnThrottledRequests é definido como 3, portanto, nesse caso, se uma operação de solicitação for limitada por exceder a taxa de transferência reservada para o contêiner, a operação de solicitação tentará novamente três vezes antes de lançar a exceção para o aplicativo. MaxRetryWaitTimeInSeconds é definido como 60, portanto, neste caso, se o tempo de espera cumulativo de repetição em segundos desde a primeira solicitação exceder 60 segundos, a exceção será lançada.

ConnectionPolicy connectionPolicy = new ConnectionPolicy(); 
connectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 3; 
connectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 60;

Estratégia de criação de partições e custos do débito aprovisionado

Uma boa estratégia de particionamento é importante para otimizar os custos no Azure Cosmos DB. Certifique-se de que não há distorção de partições, que são expostas por meio de métricas de armazenamento. Certifique-se de que não haja distorção da taxa de transferência para uma partição, que é exposta com métricas de taxa de transferência. Certifique-se de que não há inclinação para chaves de partição específicas. As chaves dominantes no armazenamento são expostas por meio de métricas, mas a chave depende do padrão de acesso do aplicativo. É melhor pensar na chave de partição lógica certa. Espera-se que uma boa chave de partição tenha as seguintes características:

  • Escolha uma chave de partição que distribua a carga de trabalho uniformemente por todas as partições e uniformemente ao longo do tempo. Em outras palavras, você não deve ter algumas chaves com a maioria dos dados e algumas chaves com menos ou nenhum dado.

  • Escolha uma chave de partição que permita que os padrões de acesso sejam distribuídos uniformemente entre partições lógicas. A carga de trabalho é razoavelmente uniforme em todas as chaves. Em outras palavras, a maior parte da carga de trabalho não deve ser focada em algumas chaves específicas.

  • Escolha uma chave de partição que tenha uma ampla gama de valores.

A ideia básica é distribuir os dados e a atividade em seu contêiner pelo conjunto de partições lógicas, para que os recursos para armazenamento e taxa de transferência de dados possam ser distribuídos pelas partições lógicas. Os candidatos a chaves de partição podem incluir as propriedades que aparecem frequentemente como um filtro em suas consultas. As consultas podem ser encaminhadas com eficiência ao incluir a chave de partição no predicado de filtro. Com essa estratégia de particionamento, otimizar a taxa de transferência provisionada é muito mais fácil.

Projete itens menores para maior taxa de transferência

A taxa de solicitação ou o custo de processamento de solicitação de uma determinada operação está diretamente correlacionado com o tamanho do item. As operações em itens grandes custam mais do que as operações em itens menores.

Padrões de acesso a dados

É sempre uma boa prática separar logicamente seus dados em categorias lógicas com base na frequência com que você acessa os dados. Ao categorizá-los como dados quentes, médios ou frios, você pode ajustar o armazenamento consumido e a taxa de transferência necessária. Dependendo da frequência de acesso, você pode colocar os dados em contêineres separados (por exemplo, tabelas, gráficos e coleções) e ajustar a taxa de transferência provisionada neles para atender às necessidades desse segmento de dados.

Além disso, se você estiver usando o Azure Cosmos DB e souber que não pesquisará por determinados valores de dados ou raramente os acessará, armazenará os valores compactados desses atributos. Com esse método, você economiza espaço de armazenamento, espaço de índice e taxa de transferência provisionada e resulta em custos mais baixos.

Otimizar alterando a política de indexação

Por padrão, o Azure Cosmos DB indexa automaticamente todas as propriedades de cada registro. O objetivo é facilitar o desenvolvimento e garantir um excelente desempenho em muitos tipos diferentes de consultas ad hoc. Se você tiver registros grandes com milhares de propriedades, pagar o custo de taxa de transferência para indexar cada propriedade pode não ser útil, especialmente se você consultar apenas 10 ou 20 dessas propriedades. À medida que você se aproxima de controlar sua carga de trabalho específica, nossa orientação é ajustar sua política de índice. Detalhes completos sobre a política de indexação do Azure Cosmos DB podem ser encontrados aqui.

Monitorar a taxa de transferência provisionada e consumida

Você pode monitorar o número total de unidades de solicitação provisionadas, o número de solicitações limitadas por taxa e o número de RUs que você consumiu no portal do Azure. Para saber mais, consulte Analisar métricas do Azure Cosmos DB. A imagem a seguir mostra um exemplo de métrica de uso:

Monitorar unidades de solicitação no portal do Azure

Você também pode definir alertas para verificar se o número de solicitações limitadas por taxa excede um limite específico. Para saber mais sobre alertas, consulte Alertas do Azure Monitor.

Dimensione sua taxa de transferência de forma elástica e sob demanda

Como você é cobrado pela taxa de transferência provisionada, a correspondência da taxa de transferência provisionada às suas necessidades pode ajudá-lo a evitar as cobranças pela taxa de transferência não utilizada. Você pode aumentar ou diminuir a taxa de transferência provisionada a qualquer momento, conforme necessário. Se suas necessidades de taxa de transferência forem muito previsíveis, você poderá usar o Azure Functions e usar um Gatilho de Timer para aumentar ou diminuir a taxa de transferência em um cronograma.

  • Monitorar o consumo de suas RUs e a proporção de solicitações com taxa limitada pode revelar que você não precisa manter o provisionamento constante ao longo do dia ou da semana. Você pode receber menos tráfego à noite ou durante o fim de semana. Usando o portal do Azure ou SDKs nativos do Azure Cosmos DB ou API REST, você pode dimensionar sua taxa de transferência provisionada a qualquer momento. A API REST do Azure Cosmos DB fornece pontos de extremidade para atualizar programaticamente o nível de desempenho de seus contêineres, tornando simples ajustar a taxa de transferência do seu código, dependendo da hora do dia ou do dia da semana. A operação é realizada sem qualquer tempo de inatividade e normalmente entra em vigor em menos de um minuto.

  • Uma das áreas que você deve dimensionar a taxa de transferência é quando você ingere dados no Azure Cosmos DB, por exemplo, durante a migração de dados. Depois de concluir a migração, você pode dimensionar a taxa de transferência provisionada para baixo para lidar com o estado estacionário da solução.

  • Lembre-se de que o faturamento está na granularidade de uma hora, portanto, você não economizará dinheiro se alterar sua taxa de transferência provisionada com mais frequência do que uma hora de cada vez.

Determinar a taxa de transferência necessária para uma nova carga de trabalho

Para determinar a taxa de transferência provisionada para uma nova carga de trabalho, você pode usar as seguintes etapas:

  1. Execute uma avaliação inicial e aproximada usando o planejador de capacidade e ajuste suas estimativas com a ajuda do Azure Cosmos DB Explorer no portal do Azure.

  2. Recomenda-se criar os contêineres com uma taxa de transferência maior do que o esperado e, em seguida, reduzir conforme necessário.

  3. É recomendável usar um dos SDKs nativos do Azure Cosmos DB para se beneficiar de novas tentativas automáticas quando as solicitações forem limitadas por taxa. Se você estiver trabalhando em uma plataforma sem suporte e usar a API REST do Azure Cosmos DB, implemente sua própria política de repetição usando o x-ms-retry-after-ms cabeçalho.

  4. Certifique-se de que o código do aplicativo suporta normalmente o caso quando todas as novas tentativas falham.

  5. Você pode configurar alertas do portal do Azure para obter notificações para limitação de taxa. Você pode começar com limites conservadores, como 10 solicitações limitadas por taxa nos últimos 15 minutos, e mudar para regras mais ansiosas assim que descobrir seu consumo real. Limites de taxa ocasionais são bons, eles mostram que você está jogando com os limites que você definiu e é exatamente isso que você quer fazer.

  6. Use o monitoramento para entender seu padrão de tráfego, para que você possa considerar a necessidade de ajustar dinamicamente o provisionamento de taxa de transferência ao longo do dia ou de uma semana.

  7. Monitore sua taxa de transferência provisionada versus consumida regularmente para garantir que você não tenha provisionado mais do que o número necessário de contêineres e bancos de dados. Ter um pouco mais de taxa de transferência provisionada é uma boa verificação de segurança.

Práticas recomendadas para otimizar a taxa de transferência provisionada

As etapas a seguir ajudam você a tornar suas soluções altamente escaláveis e econômicas ao usar o Azure Cosmos DB.

  1. Se você tiver excedido significativamente a taxa de transferência provisionada em contêineres e bancos de dados, deverá examinar as RUs provisionadas Vs consumidas e ajustar as cargas de trabalho.

  2. Um método para estimar a quantidade de taxa de transferência reservada exigida pelo seu aplicativo é registrar a cobrança de RU da unidade de solicitação associada à execução de operações típicas em um contêiner ou banco de dados representativo do Azure Cosmos DB usado pelo seu aplicativo e, em seguida, estimar o número de operações que você prevê executar a cada segundo. Certifique-se de medir e incluir consultas típicas e seu uso também. Para saber como estimar os custos de RU de consultas programaticamente ou usando o portal, consulte Otimizando o custo de consultas.

  3. Outra maneira de obter operações e seus custos em RUs é habilitando os logs do Azure Monitor, que lhe darão o detalhamento da operação/duração e a cobrança da solicitação. O Azure Cosmos DB fornece cobrança de solicitação para cada operação, para que cada cobrança de operação possa ser armazenada de volta da resposta e, em seguida, usada para análise.

  4. Você pode aumentar e reduzir elasticamente a taxa de transferência provisionada conforme necessário para acomodar suas necessidades de carga de trabalho.

  5. Você pode adicionar e remover regiões associadas à sua conta do Azure Cosmos DB conforme necessário e controlar os custos.

  6. Certifique-se de ter uma distribuição uniforme de dados e cargas de trabalho entre partições lógicas de seus contêineres. Se você tiver uma distribuição de partição irregular, isso pode fazer com que provisione uma quantidade maior de taxa de transferência do que o valor necessário. Se você identificar que tem uma distribuição enviesada, recomendamos redistribuir a carga de trabalho uniformemente pelas partições ou reparticionar os dados.

  7. Se você tiver muitos contêineres e esses contêineres não exigirem SLAs, poderá usar a oferta baseada em banco de dados para os casos em que os SLAs de taxa de transferência por contêiner não se aplicam. Você deve identificar quais dos contêineres do Azure Cosmos DB você deseja migrar para a oferta de taxa de transferência no nível do banco de dados e, em seguida, migrá-los usando uma solução baseada em feed de alterações.

  8. Considere usar o "Nível gratuito do Azure Cosmos DB" (gratuito por um ano), Experimente o Azure Cosmos DB (até três regiões) ou o emulador do Azure Cosmos DB baixável para cenários de desenvolvimento/teste. Usando essas opções para test-dev, você pode reduzir substancialmente seus custos.

  9. Você pode ainda executar otimizações de custos específicas da carga de trabalho – por exemplo, aumentando o tamanho do lote, balanceando a carga de leituras em várias regiões e eliminando a duplicação de dados, se aplicável.

  10. Com a capacidade reservada do Azure Cosmos DB, pode obter descontos significativos até 65% durante três anos. O modelo de capacidade reservada do Azure Cosmos DB é um compromisso inicial sobre as unidades de solicitações necessárias ao longo do tempo. Os descontos são escalonados de tal forma que quanto mais unidades de solicitação você usar durante um período mais longo, maior será o seu desconto. Estes descontos são aplicados imediatamente. Todas as RUs usadas acima dos valores provisionados são cobradas com base no custo de capacidade não reservada. Consulte Capacidade reservada do Azure Cosmos DB) para obter mais detalhes. Considere a compra de capacidade reservada para reduzir ainda mais os custos de throughput provisionado.

Próximos passos

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