Otimizar o débito aprovisionado no Azure Cosmos DB

APLICA-SE A: NoSQL MongoDB Cassandra Gremlin Tabela

Ao oferecer um modelo de débito aprovisionado, o Azure Cosmos DB oferece um desempenho previsível em qualquer escala. Reservar ou aprovisionar débito antecipadamente elimina o "efeito vizinho ruidoso" no seu desempenho. Especifique a quantidade exata de débito de que precisa e o Azure Cosmos DB garante o débito configurado, apoiado pelo SLA.

Pode começar com um débito mínimo de 400 RU/seg e aumentar verticalmente para dezenas de milhões de pedidos por segundo ou até mais. Cada pedido que emitir relativamente ao contentor ou base de dados do Azure Cosmos DB, como um pedido de leitura, pedido de escrita, pedido de consulta, procedimentos armazenados, tem um custo correspondente que é deduzido do débito aprovisionado. Se aprovisionar 400 RU/s e emitir uma consulta que custe 40 RUs, poderá emitir 10 dessas consultas por segundo. Qualquer pedido que ultrapasse esse limite será limitado pela taxa e deverá repetir o pedido. Se estiver a utilizar controladores de cliente, estes 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.

Otimizar ao aprovisionar débito em diferentes níveis

  • Se aprovisionar débito numa base de dados, todos os contentores, por exemplo, coleções/tabelas/gráficos nessa base de dados podem partilhar o débito com base na carga. O débito reservado ao nível da base de dados é partilhado de forma desigual, consoante a carga de trabalho num conjunto específico de contentores.

  • Se aprovisionar débito num contentor, o débito é garantido para esse contentor, apoiado 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 contentor. Veja Artigos sobre criação de partições e dimensionamento horizontal para obter mais detalhes.

Seguem-se algumas diretrizes para decidir sobre uma estratégia de débito aprovisionado:

Considere o aprovisionamento do débito numa base de dados do Azure Cosmos DB (que contém um conjunto de contentores) se:

  1. Tem algumas dezenas de contentores do Azure Cosmos DB e quer partilhar o débito entre alguns ou todos eles.

  2. Está a migrar a partir de uma base de dados de inquilino único concebida para ser executada em VMs alojadas em IaaS ou no local, por exemplo, no NoSQL ou bases de dados relacionais para o Azure Cosmos DB. Se tiver muitas coleções/tabelas/gráficos e não quiser efetuar alterações ao seu modelo de dados. Tenha em atenção que poderá ter de comprometer algumas das vantagens oferecidas pelo Azure Cosmos DB se não estiver a atualizar o modelo de dados ao migrar a partir de uma base de dados no local. Recomenda-se que reavalie sempre o seu modelo de dados para tirar o máximo partido em termos de desempenho e também para otimizar os custos.

  3. Quer absorver picos não planeados nas cargas de trabalho em virtude do débito agrupado ao nível da base de dados sujeito a um pico inesperado na carga de trabalho.

  4. Em vez de definir débito específico em contentores individuais, preocupa-se em obter o débito agregado num conjunto de contentores na base de dados.

Considere o aprovisionamento do débito num contentor individual se:

  1. Tem alguns contentores do Azure Cosmos DB. Uma vez que o Azure Cosmos DB é agnóstico ao esquema, um contentor pode conter itens com esquemas heterogéneos e não requer que os clientes criem vários tipos de contentor, um para cada entidade. É sempre uma opção a considerar se agrupar, por exemplo, 10 a 20 contentores num único contentor, faz sentido. Com um mínimo de 400 RUs para contentores, o agrupamento de todos os 10 a 20 contentores num só pode ser mais rentável.

  2. Quer controlar o débito num contentor específico e obter o débito garantido num determinado contentor apoiado pelo SLA.

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

  1. Conforme mencionado anteriormente, o Azure Cosmos DB permite-lhe misturar e corresponder às duas estratégias acima, para que agora possa ter alguns contentores na base de dados do Azure Cosmos DB, que podem partilhar o débito aprovisionado na base de dados, bem como alguns contentores na mesma base de dados, que podem ter quantidades dedicadas de débito aprovisionado.

  2. Pode aplicar as estratégias acima para criar uma configuração híbrida, onde tem ambos débito aprovisionado ao nível da base de dados, com alguns contentores com débito dedicado.

Conforme mostrado na tabela seguinte, dependendo da escolha da API, pode aprovisionar débito em diferentes granularidades.

API Para débito partilhado , configure Para débito dedicado , 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 de chaves Tabela
API para Gremlin Conta de base de dados Graph
API para Tabela Conta de base de dados Tabela

Ao aprovisionar o débito em diferentes níveis, pode otimizar os custos com base nas características da carga de trabalho. Conforme mencionado anteriormente, pode aumentar ou diminuir programaticamente e a qualquer momento o débito aprovisionado para contentores individuais ou coletivamente num conjunto de contentores. Ao dimensionar de forma elástica o débito à medida que a carga de trabalho muda, paga apenas o débito que configurou. Se o contentor ou um conjunto de contentores for distribuído por várias regiões, é garantido que o débito configurado no contentor ou num conjunto de contentores seja disponibilizado 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, pode aprovisionar menos débito e permitir que a aplicação processe a limitação de taxa quando o débito real excede o débito aprovisionado. O servidor terminará preventivamente o pedido com RequestRateTooLarge (código de estado HTTP 429) e devolverá o x-ms-retry-after-ms cabeçalho que indica a quantidade de tempo, em milissegundos, que o utilizador tem de aguardar antes de repetir o pedido.

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 esta resposta, respeitam o cabeçalho retry-after especificado pelo servidor e repetem o pedido. A menos que a sua conta seja acedida simultaneamente por vários clientes, a próxima repetição será bem-sucedida.

Se tiver mais do que um cliente a funcionar cumulativamente acima da taxa de pedido, a contagem de repetições predefinida, que está atualmente definida como 9, poderá não ser suficiente. Nestes casos, o cliente lança um RequestRateTooLargeException com o código de estado 429 para a aplicação. A contagem de repetições predefinida pode ser alterada ao definir a RetryOptions na instância ConnectionPolicy. Por predefinição, o com código RequestRateTooLargeException de estado 429 é devolvido após um tempo de espera cumulativo de 30 segundos se o pedido continuar a funcionar acima da taxa de pedido. Isto ocorre mesmo quando a contagem de repetições atual é inferior à contagem máxima de repetições, seja a predefinição de 9 ou um valor definido pelo utilizador.

MaxRetryAttemptsOnThrottledRequests está definido como 3, pelo que, neste caso, se uma operação de pedido for limitada por exceder o débito reservado para o contentor, a operação de pedido é repetida três vezes antes de lançar a exceção para a aplicação. MaxRetryWaitTimeInSeconds está definido como 60, pelo que, neste caso, se o tempo de espera de repetição cumulativa em segundos desde que o primeiro pedido exceder 60 segundos, a exceção é emitida.

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 criação de partições é importante para otimizar os custos no Azure Cosmos DB. Confirme que não existe distorção de partições, que são expostas através de métricas de armazenamento. Confirme que não existe distorção de débito para uma partição, que é exposta com métricas de débito. Certifique-se de que não existe nenhuma distorção em relação a chaves de partição específicas. As chaves dominantes no armazenamento são expostas através de métricas, mas a chave estará dependente do padrão de acesso da aplicação. É melhor pensar na chave de partição lógica correta. 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. Por outras palavras, não deve ter algumas chaves para com a maioria dos dados e algumas chaves com menos ou nenhum dados.

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

  • Escolha uma chave de partição que tenha um vasto leque de valores.

A ideia básica é distribuir os dados e a atividade no contentor pelo conjunto de partições lógicas, para que os recursos de armazenamento e débito 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 nas suas consultas. As consultas podem ser encaminhadas com eficiência ao incluir a chave de partição no predicado de filtro. Com esta estratégia de criação de partições, a otimização do débito aprovisionado será muito mais fácil.

Estruturar itens mais pequenos para um débito mais elevado

O custo do pedido ou o custo de processamento do pedido de uma determinada operação está diretamente correlacionado com o tamanho do item. As operações em itens grandes custarão mais do que as operações em itens mais pequenos.

Padrões de acesso a dados

É sempre uma boa prática separar logicamente os seus dados em categorias lógicas com base na frequência com que acede aos dados. Ao categorizá-lo como dados frequentes, médios ou frios, pode ajustar o armazenamento consumido e o débito necessário. Consoante a frequência de acesso, pode colocar os dados em contentores separados (por exemplo, tabelas, gráficos e coleções) e ajustar o débito aprovisionado nos mesmos para acomodar as necessidades desse segmento de dados.

Além disso, se estiver a utilizar o Azure Cosmos DB e souber que não vai procurar determinados valores de dados ou que raramente irá aceder aos mesmos, deve armazenar os valores comprimidos destes atributos. Com este método, poupa espaço de armazenamento, espaço de índice e débito aprovisionado e resulta em custos mais baixos.

Otimizar alterando a política de indexação

Por predefinição, o Azure Cosmos DB indexa automaticamente todas as propriedades de cada registo. Isto destina-se a facilitar o desenvolvimento e garantir um excelente desempenho em muitos tipos diferentes de consultas ad hoc. Se tiver registos grandes com milhares de propriedades, pagar o custo de débito para indexar cada propriedade pode não ser útil, especialmente se apenas consultar 10 ou 20 dessas propriedades. À medida que se aproxima de obter um identificador sobre a sua carga de trabalho específica, a nossa documentação de orientação é ajustar a política de índice. Pode encontrar todos os detalhes sobre a política de indexação do Azure Cosmos DB aqui.

Monitorização do débito aprovisionado e consumido

Pode monitorizar o número total de RUs aprovisionadas, o número de pedidos limitados por taxa, bem como o número de RUs que consumiu no portal do Azure. A imagem seguinte mostra uma métrica de utilização de exemplo:

Monitorizar unidades de pedido no portal do Azure

Também pode definir alertas para verificar se o número de pedidos limitados por taxa excede um limiar específico. Veja Como monitorizar o Azure Cosmos DB para obter mais detalhes. Estes alertas podem enviar um e-mail para os administradores de conta ou chamar um Webhook HTTP personalizado ou uma Função do Azure para aumentar automaticamente o débito aprovisionado.

Dimensionar o débito de forma elástica e a pedido

Uma vez que lhe é faturado o débito aprovisionado, corresponder o débito aprovisionado às suas necessidades pode ajudá-lo a evitar os custos do débito não utilizado. Pode aumentar ou reduzir verticalmente o débito aprovisionado a qualquer momento, conforme necessário. Se as suas necessidades de débito forem muito previsíveis, pode utilizar Funções do Azure e utilizar um Acionador de Temporizador para aumentar ou diminuir o débito numa agenda.

  • Monitorizar o consumo das RUs e o rácio de pedidos limitados por taxa pode revelar que não precisa de manter o aprovisionado ao longo de constantes ao longo do dia ou da semana. Poderá receber menos tráfego durante a noite ou durante o fim de semana. Ao utilizar os SDKs nativos do portal do Azure ou do Azure Cosmos DB ou a API REST, pode dimensionar o débito aprovisionado em qualquer altura. A API REST do Azure Cosmos DB fornece pontos finais para atualizar programaticamente o nível de desempenho dos contentores, tornando mais simples ajustar o débito do código consoante a hora do dia ou do dia da semana. A operação é executada sem qualquer período de indisponibilidade e, normalmente, entra em vigor em menos de um minuto.

  • Uma das áreas em que deve dimensionar o débito é quando ingere dados no Azure Cosmos DB, por exemplo, durante a migração de dados. Depois de concluir a migração, pode reduzir verticalmente o débito aprovisionado para processar o estado estável da solução.

  • Lembre-se de que a faturação está na granularidade de uma hora, pelo que não poupará dinheiro se alterar o débito aprovisionado com mais frequência do que uma hora de cada vez.

Determinar o débito necessário para uma nova carga de trabalho

Para determinar o débito aprovisionado para uma nova carga de trabalho, pode utilizar os seguintes passos:

  1. Efetue uma avaliação inicial e aproximada com o capacity planner e ajuste as estimativas com a ajuda do Explorador do Azure Cosmos DB no portal do Azure.

  2. Recomenda-se criar os contentores com um débito superior ao esperado e, em seguida, reduzir verticalmente conforme necessário.

  3. É recomendado utilizar um dos SDKs nativos do Azure Cosmos DB para beneficiar de repetições automáticas quando os pedidos são limitados pela taxa. Se estiver a trabalhar numa plataforma que não é suportada e utiliza a API REST do Azure Cosmos DB, implemente a sua própria política de repetição com o x-ms-retry-after-ms cabeçalho.

  4. Certifique-se de que o código da aplicação suporta corretamente o caso quando todas as repetições falham.

  5. Pode configurar alertas a partir do portal do Azure para receber notificações de limitação de taxa. Pode começar com limites conservadores como 10 pedidos limitados por taxas nos últimos 15 minutos e mudar para regras mais ansiosas assim que descobrir o seu consumo real. Os limites de taxas ocasionais são bons, mostram que estás a jogar com os limites que definiste e é exactamente isso que queres fazer.

  6. Utilize a monitorização para compreender o padrão de tráfego, para que possa considerar a necessidade de ajustar dinamicamente o aprovisionamento de débito ao longo do dia ou de uma semana.

  7. Monitorize regularmente o rácio de débito aprovisionado vs. consumido para garantir que não aprovisionou mais do que o número necessário de contentores e bases de dados. Ter um pouco mais de débito aprovisionado é uma boa verificação de segurança.

Melhores práticas para otimizar o débito aprovisionado

Os passos seguintes ajudam-no a tornar as suas soluções altamente dimensionáveis e económicas ao utilizar o Azure Cosmos DB.

  1. Se tiver excedido significativamente o débito aprovisionado em contentores e bases de dados, deve rever as RUs aprovisionadas vs. RUs consumidas e ajustar as cargas de trabalho.

  2. Um método para estimar a quantidade de débito reservado exigido pela sua aplicação é registar o custo de RUs da unidade de pedido associado à execução de operações típicas num contentor ou base de dados representativo do Azure Cosmos DB utilizado pela sua aplicação e, em seguida, estimar o número de operações que prevê realizar a cada segundo. Certifique-se de que mede e inclui consultas típicas e a respetiva utilização. Para saber como estimar os custos de RUs das consultas através de programação ou através do portal, veja Otimizar o custo das consultas.

  3. Outra forma de obter operações e os respetivos custos em RUs é ativar os registos do Azure Monitor, o que lhe dará a discriminação da operação/duração e do custo do pedido. O Azure Cosmos DB fornece custos de pedidos para cada operação, para que cada custo de operação possa ser armazenado novamente a partir da resposta e, em seguida, utilizado para análise.

  4. Pode aumentar e reduzir verticalmente verticalmente o débito aprovisionado, uma vez que precisa de acomodar as necessidades da carga de trabalho.

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

  6. Certifique-se de que tem uma distribuição uniforme de dados e cargas de trabalho entre partições lógicas dos seus contentores. Se tiver uma distribuição de partição desigual, tal poderá fazer com que aprovisione uma quantidade de débito superior ao valor necessário. Se identificar que tem uma distribuição distorcida, recomendamos a redistribuição uniforme da carga de trabalho entre as partições ou a criação de novas partições dos dados.

  7. Se tiver muitos contentores e estes contentores não precisarem de SLAs, pode utilizar a oferta baseada na base de dados para os casos em que os SLAs de débito por contentor não se aplicam. Deve identificar quais dos contentores do Azure Cosmos DB pretende migrar para a oferta de débito ao nível da base de dados e, em seguida, migrá-los através de uma solução baseada no feed de alterações.

  8. Considere utilizar o "Escalão Gratuito do Azure Cosmos DB" (gratuito durante um ano), Experimentar o Azure Cosmos DB (até três regiões) ou o emulador transferível do Azure Cosmos DB para cenários de desenvolvimento/teste. Ao utilizar estas opções para test-dev, pode reduzir substancialmente os custos.

  9. Pode continuar a efetuar otimizações de custos específicas da carga de trabalho , por exemplo, aumentar o tamanho do lote, leituras de balanceamento de carga em várias regiões e anular 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 em unidades de pedidos necessárias ao longo do tempo. Os descontos são escalonados de modo a que quanto mais unidades de pedido utilizar durante um período mais longo, mais o seu desconto será. Estes descontos são aplicados imediatamente. Todas as RUs utilizadas acima dos valores aprovisionados são cobradas com base no custo de capacidade não reservada. Veja Capacidade reservada do Azure Cosmos DB) para obter mais detalhes. Considere comprar capacidade reservada para reduzir ainda mais os custos de débito aprovisionado.

Passos seguintes

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