Modelagem de dados DynamoDB e consultas

Projete partition keys do DynamoDB, GSI/LSI, Query vs Scan, modelos de consistencia e transacoes.

DynamoDB e o segundo servico mais avaliado no exame AWS DVA-C02. Entender o design de chaves e os padroes de consulta e essencial para ser aprovado.

 

O que exatamente e o DynamoDB?

Bancos de dados tradicionais como RDS ou MySQL armazenam dados em estruturas de tabelas fixas com linhas e colunas. DynamoDB e um banco de dados NoSQL — e flexivel em estrutura e extremamente rapido (tempos de resposta em milissegundos).

Pense assim: se um banco de dados tradicional e como uma planilha, DynamoDB e como um pacote de post-its. Cada post-it (item) pode ter conteudo diferente, e voce pode encontrar qualquer um de bilhoes de post-its em um instante.

 

Design de chave primaria — A base de como os dados sao armazenados

O conceito mais importante no DynamoDB e a chave primaria (Primary Key). A chave primaria determina em qual servidor (particao) os dados serao armazenados.

Partition Key (Chave de particao)

A partition key decide como os dados sao distribuidos entre varios servidores. Pense nela como os codigos postais de uma agencia dos Correios — quanto mais uniformemente os codigos postais estiverem distribuidos, mais rapidas serao as entregas.

O principio fundamental: sempre escolha um atributo com muitos valores unicos (alta cardinalidade) como partition key.

Mau exemplo: usar uma data como partition key. Milhares de registros criados no mesmo dia vao para o mesmo servidor, causando um engarrafamento. Isso e chamado de problema de particao quente (hot partition).

Bom exemplo: usar o ID do usuario como partition key. Os dados de cada usuario sao distribuidos em servidores diferentes, distribuindo a carga uniformemente.

Sort Key (Chave de classificacao)

A sort key ordena os dados dentro da mesma particao. Usar tanto uma partition key quanto uma sort key juntas permite consultas por intervalo.

Por exemplo, com o ID do usuario como partition key e o timestamp como sort key, voce pode recuperar rapidamente a atividade recente de um usuario especifico em ordem cronologica.

 

Indices — Quando voce precisa pesquisar de varias maneiras

Com apenas a chave primaria, voce so pode pesquisar dados de uma maneira. Quando quer pesquisar rapidamente por outros atributos, usa indices. Funciona como um indice em um livro — ajuda a encontrar o que voce precisa sem ler o livro inteiro.

GSI (Global Secondary Index)

Um GSI permite consultar usando partition key e sort key completamente diferentes das da tabela original. Voce pode adicionar um GSI a qualquer momento apos criar a tabela, o que o torna muito flexivel. No entanto, requer capacidade provisionada separada.

Exemplo: se sua tabela e organizada por ID de usuario mas voce tambem quer pesquisar por endereco de email, crie um GSI com o email como partition key.

LSI (Local Secondary Index)

Um LSI mantem a mesma partition key da tabela original, mas usa uma sort key diferente. A limitacao critica: um LSI so pode ser adicionado quando voce cria a tabela pela primeira vez. Nao e possivel adicionar um depois, portanto planeje com antecedencia.

 

Query vs Scan — A chave para a recuperacao eficiente de dados

Query (Consulta)

Use Query quando voce conhece a partition key. Ela pesquisa apenas a particao relevante, tornando-a muito eficiente e rapida. Pense nisso como ir diretamente a uma secao especifica de uma biblioteca para encontrar um livro.

Scan (Varredura)

Scan le a tabela inteira do inicio ao fim. Pode encontrar qualquer dado, mas como le tudo, e lento e caro. Pense nisso como abrir cada livro na biblioteca para encontrar o que voce precisa.

Evite Scan sempre que possivel. Se Scan for inevitavel, use ProjectionExpression para buscar apenas os atributos necessarios, e considere Parallel Scan para acelerar o processo processando multiplas secoes ao mesmo tempo.

!Query vs Scan no DynamoDB

Modelos de consistencia — Quao atualizados voce precisa que seus dados sejam?

Apos gravar dados no DynamoDB, pode haver um breve momento antes que todos os servidores reflitam a atualizacao. DynamoDB oferece duas opcoes de leitura para lidar com isso.

Eventualmente consistente (padrao): o modo padrao do DynamoDB. Pode haver um leve atraso antes que os dados mais recentes sejam visiveis. Custa metade do preco e e suficiente para a maioria dos casos de uso.

Fortemente consistente: garante que voce le os dados absolutamente mais recentes imediatamente. Use a opcao ConsistentRead=True para ativa-la. Custa o dobro, mas e necessario para cenarios como transacoes financeiras onde dados desatualizados nao sao aceitaveis.

 

Transacoes — Quando multiplas operacoes devem ter sucesso ou falhar juntas

Imagine uma transferencia bancaria: o dinheiro deve ser debitado da Conta A e creditado na Conta B ao mesmo tempo. Ambas as operacoes devem ter sucesso ou falhar juntas. E exatamente para isso que servem as transacoes.

TransactWriteItems: processa operacoes de escrita em multiplos itens de forma atomica — todos tem sucesso ou todos falham.

TransactGetItems: le multiplos itens de forma atomica.

As transacoes custam o dobro das operacoes normais. Use-as apenas quando a atomicidade for verdadeiramente necessaria.

 

Operacoes em lote — Processando multiplos itens de uma vez

BatchWriteItem: grava ou exclui ate 25 itens em uma unica solicitacao.

BatchGetItem: le ate 100 itens em uma unica solicitacao.

A diferenca fundamental em relacao as transacoes: operacoes em lote nao sao atomicas. Alguns itens podem ter sucesso enquanto outros falham. Os itens com falha sao retornados em UnprocessedItems e devem ser reprocessados.

 

Pontos-chave para o exame

"Design de chave para consultas eficientes" -- Partition key de alta cardinalidade

"Consultar com atributos diferentes, pode ser adicionado apos criar a tabela" -- GSI

"Mesma partition key, sort key diferente, apenas ao criar" -- LSI

"Recuperacao eficiente de dados" -- Query (baseada em partition key)

"Le a tabela inteira (ineficiente)" -- Scan

"Precisa dos dados mais recentes imediatamente" -- Consistencia forte (ConsistentRead=True)

"Escritas atomicas em multiplos itens" -- TransactWriteItems

"Escrita em massa, falhas parciais possiveis" -- BatchWriteItem (verificar UnprocessedItems)

Para evitar particoes quentes, escolha uma partition key com alta cardinalidade

Voltar à lista do blog