Esta é uma pequena série que eu queria compartilhar há muito tempo sobre os fundamentos da “Otimização de Custos” na AWS.

Vamos começar esta jornada com o DocumentDB !

Não hesite em 👏 se gostou deste post ;)

Ok, para ser honesto, este título é clickbait *.*

Eu definitivamente poderia escrever algo como “como fiz otimização de custos em nossa infraestrutura AWS respeitando algumas diretrizes comuns fornecidas na documentação ” mas é muito menos cativante, não?

Talvez alguns de vocês já conheçam esses truques e boas práticas.

Se você está procurando diretamente a lista de verificação que estou sugerindo, role aqui.

Entenda o custo de E/S complicado do serviço DocumentDB

Se você olhar para a página de preços deles, ela é dividida por 4 dimensões de custos, eu a resumo aqui:

• O preço da instância : bem, esse custo é rapidamente compreensível: você paga por uma instância e o preço dependerá de seus recursos (CPU, RAM, etc.)
• Custos de armazenamento e armazenamento de backup : o mesmo que acima, é bastante compreensível e podemos rastrear e estimar facilmente os custos deles, fatura da AWS por GB armazenado. Legal.
• A parte complicada é o I/O do banco de dados : a AWS cobrará entre 0,20$ e 0,30$ (dependendo da região da instância) por 1 milhão de I/O!!

Então, o que está por trás do I/O?

A AWS explica que, com o serviço DocumentDB, você não precisa provisionar recursos de I/O com antecedência, o que é interessante, porque você não tem limitações de armazenamento e pode lidar facilmente com uma seleção de operações de I/O. Parece justo, já que você cobra pelo uso.

A AWS descreve em sua documentação o que cobre as operações de E/S, principalmente todas as operações como localizar, inserir, atualizar e excluir ou alguns recursos como fluxos de mudança e índices TTL (time to live).

Bem, tudo o que atingir o volume de armazenamento será cobrado de você.

Espere, o que, 0,20 $ por milhão de E/S?

Vamos fazer a AWS perder dinheiro, agora mesmo!

Há uma frase na documentação do AWS DocumentDB que vai chamar sua atenção (e carteira 💸):

Uma vez que os dados foram lidos do volume de armazenamento e continuam a residir na memória, as leituras subsequentes dos mesmos dados não incorrem em E/S adicionais.

Essa frase é a chave para entender o que está por trás das E/Ss.

Quais operações usam menos E/S?

As consultas que usam um índice provavelmente usarão menos E/S, pois você não está verificando todo o armazenamento de sua coleção. Certamente consumirá E/S, mas muito menos do que digitalizar uma coleção inteira.

Além disso, a RAM de sua instância precisa cobrir o tamanho do índice, o que permitirá que você não incorra em E/S adicionais.

Tenha em mente que você precisa respeitar alguns princípios com o uso do índice.

Lista de verificação ✅

Aqui está meu conselho/lista de verificação quando você deseja otimizar seu uso de E/S, reduzir seus custos e melhorar o desempenho.

Você verá que não sou um gênio, pois apenas agrego informações da página de documentação do AWS DocumentDB com algumas práticas recomendadas comuns que não são estritamente aplicáveis ao DocumentDB.

É sempre bom refrescar nossas mentes com princípios.

• 🧠 Em primeiro lugar, lembre-se disso : menos E/S = mais barato = melhor desempenho, aqui não se trata apenas de custos ou desempenho, mas as duas coisas estão ligadas.

• ❌ Remova índices não utilizados : você não sabe o quão caro é um índice não utilizado para uma coleção ocupada. Fiz minha empresa economizar $ 2.000 / mês assim 🤌 , excluindo índices não utilizados. E é muito fácil rastrear índices não utilizados com esta consulta:

  
  

Consulta de estatísticas de índice

A consulta produzirá as ops de campo que correspondem ao número de vezes que seu índice é atingido. Dependendo da carga do seu aplicativo, considere remover o índice não utilizado.

• 🧐 Ativar insights de desempenho e operações de criação de perfil : se você usa o RDS, pode estar ciente dos insights de desempenho , ele fornece algumas métricas e informações muito úteis sobre as consultas que estão atingindo o desempenho do DocumentDB e você pode ver rapidamente as consultas que consomem I /Os operações (e a quantidade delas), então é muito bom rastrear facilmente um gargalo. Outra forma de monitorar consultas lentas ou consultas collscan é ativando Profiling operations , como o nome sugere, é o perfil de algumas operações para você (aqui está um link para obter mais informações: ), você pode definir um limite que colocará no CloudWatch um log de um operação que está demorando mais de n ms . Muito útil para rastrear a quantidade de consultas que estão realizando COLLSCAN por exemplo. Por favor, ative ambas as opções, pois elas são muito valiosas!

  
  

• 💾 Olhe sempre primeiro para os seus dados : você precisará identificar o melhor campo de alta cardinalidade que deseja indexar, se você não está acostumado com o conceito de cardinalidade do índice, a documentação do AWS DocumentDB está bem explicada :)

  
  

• 🫠 Evite coleções pequenas complicadas : se você planeja ter uma coleção que terá três campos com um deles com uma chave única e se planeja realizar muitas atualizações/inserções, considere a modelagem de sua coleção, porque suas operações de I/O vão atingir como o inferno e, portanto, seu uso de I/O.

  
  

• ⏱️ Evite TTL, também conhecido como time-to-leave indexes : (na maioria das vezes) você pode lidar com isso sem definir um time-to-leave index, então verifique se o parâmetro TTL não está habilitado na instância ou cluster.

  
  

• 💡 Explique! Uma maneira muito simples de verificar a seletividade do índice do planejador de consulta quando você está fazendo uma nova consulta (ou não) é realizar uma operação de explicação com o parâmetro executionStats . Você ficará surpreso ao ver que algumas consultas que você está pensando atingem o índice, mas não atingem nenhum índice...

  
  

• ☯️ Não crie um índice para um campo booleano . Apenas não. Lembre-se da cardinalidade.

  
  

• ⚖️ Monitore o tamanho médio de um objeto para cada coleção que você possui com este comando: db.<mycollection>.stats(1024) Um tamanho médio extremo pode criar rapidamente um bloqueio em suas consultas e aumentar as operações de I/Os porque a RAM de sua instância não é suficiente. Por favor, monitore objetos de perto e não armazene campos desnecessários. Se precisar armazenar muitos campos, considere otimizar as consultas não selecionando todos os campos.

  
  

• ⚠️ Esteja ciente de que DocumentDB não é MongoDB. É principalmente compatível com o MongoDB, mas não é o MongoDB, pois existem alguns comportamentos específicos de merda. Por exemplo, se você deseja realizar uma consulta com o operador $regex , você precisará `hint()` seu índice, pois é obrigatório. Os operadores de exclusão nunca usarão nenhum índice, portanto, considere esses comportamentos ao criar ou otimizar seus índices!

  
  

• 👉 Nunca insinuar . Exceto pelos casos de uso muito específicos mencionados acima, você deve evitar o uso de hint , lembre-se de que, se o planejador de consultas não eleger seu índice, é por um bom motivo. Na maioria das vezes é porque é mais longo ou equivalente a digitalizar o índice em vez de todos os documentos da coleção.

• 
  

Espero que você aprecie esses truques que aprendi enquanto trabalhava no AWS Cost Optimization para minha empresa.

Fique ligado para outro post!

Não hesite em 👏 se gostou deste post ;)

PS: se algo parecer errado ou mal-entendido, não hesite em me enviar um DM.

Também publicado aqui