Tabelas, itens e chaves primárias

O Amazon DynamoDB é um banco de dados de chave-valor e documentos totalmente gerenciado e sem servidor, projetado para oferecer desempenho de milissegundos de um único dígito em qualquer escala. Diferentemente dos bancos de dados relacionais, o DynamoDB não exige um esquema fixo: cada item pode ter um conjunto diferente de atributos, desde que a chave primária esteja presente.

O DynamoDB armazena dados em tabelas, que são o contêiner de nível superior análogo a uma tabela SQL. As tabelas são distribuídas automaticamente entre vários nós de armazenamento em várias AZs, oferecendo redundância integrada sem exigir nenhuma configuração da sua parte.

Uma tabela do DynamoDB contém uma coleção de itens, e cada item é uma coleção de atributos. Os atributos são valores tipados: String (S), Number (N), Binary (B), Boolean (BOOL), Null (NULL), List (L), Map (M) e tipos Set (SS, NS, BS).

Todo item de uma tabela deve incluir os atributos da chave primária; todos os demais atributos são opcionais e podem variar entre os itens. Um único item pode ter no máximo 400 KB, incluindo todos os nomes e valores de seus atributos.

Uma chave primária simples consiste em um único atributo chamado chave de partição (também chamada de chave hash). O DynamoDB aplica uma função hash interna ao valor da chave de partição para determinar qual partição de armazenamento contém o item. Todos os itens com o mesmo valor de chave de partição são armazenados juntos.

Com uma chave primária simples, nenhum item da tabela pode ter o mesmo valor de chave de partição que outro item: esse valor identifica cada item exclusivamente. Esse design é adequado para tabelas nas quais você sempre acessa os dados por um identificador exclusivo, como um ID de usuário ou um ID de pedido.

Uma chave primária composta usa uma chave de partição e uma chave de ordenação (também chamada de chave de intervalo). Os itens com a mesma chave de partição são armazenados juntos e ordenados pelo valor da chave de ordenação, permitindo consultas por intervalo dentro de uma partição.

Esse design é extremamente flexível: vários itens podem compartilhar a mesma chave de partição, desde que suas chaves de ordenação sejam diferentes. Por exemplo, uma tabela Orders poderia usar CustomerId como chave de partição e OrderDate como chave de ordenação, permitindo consultar todos os pedidos de um cliente ordenados por data.

Escolher a chave de partição correta é a decisão de design mais importante no DynamoDB. Uma boa chave de partição tem alta cardinalidade (muitos valores distintos) e distribui o acesso uniformemente entre as partições. Escolhas inadequadas levam a partições sobrecarregadas, nas quais uma partição recebe tráfego desproporcional, causando limitação.

Antipadrões a evitar: usar um sinalizador booleano (apenas dois valores), uma data que agrupe todas as gravações de hoje ou um campo de status com baixa cardinalidade. Boas escolhas: ID de usuário, ID de dispositivo, UUID aleatório ou valores compostos como tenantId#entityType.

As três operações fundamentais de itens do DynamoDB são:

• PutItem: grava um novo item ou substitui completamente um item existente com a mesma chave primária
• GetItem: recupera um único item pela chave primária exata (exige a chave completa: chave de partição e, se for composta, chave de ordenação)
• DeleteItem: remove um item pela chave primária exata

As três operações são atômicas no nível do item. Por padrão, GetItem usa leituras eventualmente consistentes; adicionar --consistent-read força uma leitura fortemente consistente, que sempre retorna o valor gravado mais recentemente.

UpdateItem modifica atributos específicos de um item existente sem substituí-lo por completo, diferentemente de PutItem. Você pode adicionar ou remover atributos, ou realizar operações aritméticas atomicamente em atributos Number (por exemplo, incrementar um contador).

As expressões condicionais permitem especificar que uma operação só deve ter êxito se uma condição for verdadeira. Por exemplo, atualizar o status de um item somente se ele estiver atualmente como PENDING. Isso implementa padrões de bloqueio otimista sem transações e é uma técnica essencial de design do DynamoDB.

Query recupera itens que compartilham o mesmo valor de chave de partição, opcionalmente filtrados por condições da chave de ordenação. Query é eficiente: lê somente a partição selecionada. Você pode usar condições da chave de ordenação, como begins_with, between, =, < e >, para restringir os resultados dentro da partição.

Scan lê todos os itens da tabela e, em seguida, aplica uma expressão de filtro opcional. Scans são dispendiosos em tabelas grandes e devem ser evitados nos padrões de consulta de produção. Se você precisar usar Scans com frequência, reavalie o design da tabela ou adicione um Índice Secundário Global.

O DynamoDB armazena três cópias dos seus dados em várias AZs. As leituras eventualmente consistentes (o padrão) podem retornar um valor ligeiramente desatualizado se uma gravação recente ainda não tiver sido propagada para todas as cópias, mas consomem metade das unidades de capacidade de leitura das leituras fortemente consistentes.

As leituras fortemente consistentes sempre retornam a gravação confirmada mais recente, mas custam o dobro de RCU e não estão disponíveis em Global Secondary Indexes. Escolha leituras eventualmente consistentes para cargas de trabalho com alto volume e predominância de leituras, e leituras fortemente consistentes somente quando sua aplicação exigir os dados mais recentes.

O DynamoDB oferece transações ACID por meio de TransactWriteItems e TransactGetItems. Uma transação pode agrupar até 100 operações de gravação em vários itens e até mesmo em várias tabelas, garantindo que todas sejam concluídas com sucesso ou que todas sejam revertidas atomicamente.

Use transações em cenários como transferências de dinheiro entre contas (debitar um item e creditar outro) ou reservas de assentos (verificar a disponibilidade e reservá-lo atomicamente). As transações custam o dobro das RCU/WCU normais; portanto, use-as somente quando a atomicidade entre vários itens for realmente necessária.

O limite de 400 KB por item do DynamoDB influencia a modelagem de dados. Para conteúdos grandes (por exemplo, imagens e documentos grandes), armazene os dados binários no S3 e armazene apenas a chave do objeto do S3 no DynamoDB. Para dados hierárquicos profundamente aninhados, modele cada tipo de nó com seu próprio padrão de chave de partição usando o design de tabela única: uma tabela contém vários tipos de entidade, diferenciados pelo prefixo da chave de partição e pelo padrão da chave de ordenação.

O design de tabela única minimiza o número de tabelas e permite padrões de acesso eficientes ao manter itens relacionados na mesma partição. Essa é uma técnica avançada que reduz a sobrecarga operacional e melhora o desempenho em padrões de acesso complexos.

Nesta lição, você aprendeu que: as tabelas do DynamoDB contêm itens sem esquema, limitados a 400 KB; as chaves primárias simples usam apenas uma chave de partição, enquanto as chaves compostas adicionam uma chave de ordenação para consultas por intervalo; e chaves de partição com alta cardinalidade evitam partições sobrecarregadas. Use Query em vez de Scan para obter acesso eficiente. A seguir, exploraremos os modos de capacidade provisionada e sob demanda.