DEV Community

Camila Figueira
Camila Figueira

Posted on

11 6 6 7 8

DynamoDB: Query x Scan! Para de torrar dinheiro usando Scan em produção

Como Economizei 50 mil dólares com DynamoDB!

Eu já consegui economizar 50 mil dólares, só mudando o tipo de leitura no DynamoDB. Mas antes de explicar como eu fiz isso, vamos aos conceitos!

Conteúdo:

O que é um DynamoDB?

O DynamoDB é um banco de dados NoSQL (chave-valor) da AWS. Quando você precisa buscar informações nele, existem duas maneiras principais de fazer isso: Query e Scan.

Image description

Imagine que sua empresa está usando o DynamoDB para armazenar informações de eventos de monitoramento dos servidores. Cada evento contém um ID de servidor, um timestamp e mensagens de log.

Query: Procurando um Problema em um Servidor Específico

O que é?
O Query funciona como uma busca direcionada. Você já sabe qual servidor e qual período precisa analisar, então faz uma busca direta por esses critérios.

Características:

  • Rápido e eficiente para buscas específicas.
  • Precisa de um ID de servidor (chave primária) e pode filtrar por timestamp (chave de classificação).

Exemplo de Query:
Imagine que você precisa verificar erros ocorridos no servidor ID_123 na última hora. Você faz a seguinte consulta:


Servidor: ID_123
Horário: Entre 10:00 e 11:00
Enter fullscreen mode Exit fullscreen mode

O DynamoDB retorna apenas os eventos para o servidor específico no intervalo de tempo definido. Você lê apenas as linhas que interessam.

Scan: Procurando Problemas em Todos os Servidores

O que é?
O Scan é como uma varredura completa de todos os eventos. Se você quer procurar problemas gerais ou eventos de todos os servidores, precisa varrer a tabela inteira.

Características:

  • Lento e consome mais recursos, pois lê toda a tabela.
  • Ideal para buscas gerais, onde você não tem um ID específico.

Exemplo de Scan:
Agora, imagine que você precisa buscar erros de alta gravidade em todos os servidores ocorridos nas últimas 24 horas. Como não tem um ID de servidor específico, é necessário fazer um Scan com filtro:

Filtro: Gravidade do erro >= "Alto" e Horário >= "10:00 de ontem"
Enter fullscreen mode Exit fullscreen mode

O DynamoDB varre todos os eventos de um em um de todos os servidores para aplicar o filtro e trazer os resultados.

Tipos de Leitura no DynamoDB

O DynamoDB cobra com base em unidades de leitura (RCU) e unidades de escrita (WCU) que você usa. Para entender os custos, é preciso conhecer:

RCU (Read Capacity Unit): Medida de capacidade de leitura. 1 RCU = 1 leitura eventual de até 4 KB por segundo.

  1. Leitura Consistente:
    1 unidade de leitura é suficiente para ler até 4 KB de dados com total precisão.
    Sempre retorna dados mais recentes, bom para aplicações que não podem tolerar inconsistência.

  2. Leitura Eventual:
    1 unidade de leitura pode cobrir até 8 KB de dados, mas com uma chance de a informação estar ligeiramente desatualizada, o que consome menos RCU.

Custo de Leitura no DynamoDB

Agora a parte legal! 🎉

Obs: Os valores e informações a seguir são fictícios! 🚨

Observando o cenário da imagem abaixo:

Image description

Cenário Atual: Scan Completo

  • Quantidade de Itens na Tabela: 200.547 itens armazenados.
  • Tamanho da Tabela: 254,1 MB (convertido para 254.100 KB).
  • RCU (Unidade de Capacidade de Leitura): Cada unidade de leitura consegue processar 4 KB de dados.
  • ReadRequestUnits (Solicitações de Leitura): 64.483.473.398,00, que representa a quantidade de unidades de leitura necessárias. OBS: A cada 1 milhão de RRU's é consumida 1 RCU.

Resultado:
O custo total de leitura de toda a tabela foi de $15.650,87 no mês!

Mudança para Query: Cenário Otimizado

Antes, toda vez que a aplicação precisava consultar algo, ela consultava 100% da tabela usando Scan, percorrendo todos os itens até encontrar o que precisava.

Quando mudamos para Query, o cenário mudou. Agora, veja na tabela abaixo o impacto:

Image description

Se a consulta for feita em 10% da tabela, já há uma economia de $14.085,78.
Agora, imagine cenários em que as consultas são feitas em 1% da tabela ou até menos! É babado!

Resumo:

Query é como pedir uma lista específica de itens. Você paga apenas pelos dados que realmente lê.

Scan é como vasculhar uma caixa inteira para encontrar itens específicos. Você paga por todo o conteúdo da caixa, mesmo que precise de apenas algumas coisas.

Então, foi assim que consegui economizar 50 mil dólares mudando apenas a estratégia de leitura no DynamoDB! 😎

E aí, o que achou?

Heroku

Simplify your DevOps and maximize your time.

Since 2007, Heroku has been the go-to platform for developers as it monitors uptime, performance, and infrastructure concerns, allowing you to focus on writing code.

Learn More

Top comments (6)

Collapse
 
guidev115 profile image
Guilherme Fabrício

Artigo muito bom cami, o lance de custo de leitura me deixou bastante intrigado. Vlw pelo artigo 👍💜

Collapse
 
adrianemuller profile image
Adriane Müller

Muito bom Camila, parabéns!!

Collapse
 
danielhe4rt profile image
Daniel Reis

Dynamo sempre vai ser custoso pelo modelo deles independente de otimização…

Ótimo artigo, prima 👏

Collapse
 
clintonrocha98 profile image
Clinton Rocha

Ótimo artigo :D 💜

Collapse
 
brunociccarino profile image
Bruno Ciccarino λ

A complexidade da query é O(log n) e do scan é O(n), muito bom o artigo!

Collapse
 
carloseduardodb profile image
Carlos Eduardo Dias Batista

Ótimo artigo!

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay