Exemplo de modelagem de dados relacionais no DynamoDB

Esse exemplo descreve como modelar dados relacionais no Amazon DynamoDB. O design de tabela do DynamoDB corresponde ao esquema relacional de entrada de pedidos que é mostrado em Modelagem relacional. Esse design usa várias tabelas especializadas em vez de uma única lista de adjacências, oferecendo limites operacionais claros e utilizando GSIs estratégicos para atender a todos os padrões de acesso com eficiência.

Uma abordagem usa princípios de agregação, agrupando dados com base em padrões de acesso em vez de limites rígidos de entidade. As principais decisões de design incluem o uso de tabelas separadas para entidades com baixa correlação de acesso, a incorporação de dados relacionados quando sempre acessados em conjunto e o uso de coleções de itens para identificar relações.

As seguintes tabelas e os índices que as acompanham permitem usar o esquema de entrada de pedidos relacionais:

Design de tabela de funcionários

A tabela de funcionários armazena informações sobre os funcionários como uma única entidade por item, é otimizada para consultas diretas sobre funcionários e permite vários padrões de consulta por meio de GSIs estratégicos. Ela demonstra o princípio de criar tabelas separadas para entidades com características operacionais independentes e baixa correlação de acesso entre entidades.

A tabela usa uma chave de partição simples (employee_id) sem uma chave de classificação, pois cada funcionário é uma entidade distinta. Quatro GSIs permitem consultas eficientes por atributos diferentes:

Design de tabelas de clientes

A tabela de clientes mantém informações sobre o cliente com a desnormalização estratégica de account_rep_id para permitir consultas eficientes sobre representantes de conta. Essa opção de design opta por uma pequena sobrecarga de armazenamento em prol do desempenho das consultas, eliminando a necessidade de junções entre os dados do cliente e do representante da conta.

A tabela comporta vários números de telefone por cliente usando um atributo de lista, o que demonstra a flexibilidade do esquema do DynamoDB. O GSI único permite fluxos de trabalho de representantes de contas:

Design de tabela de pedidos

A tabela de pedidos usa particionamento vertical com itens separados para cabeçalhos de pedidos e itens de pedidos. Esse design permite consultas eficientes baseadas em produtos, mantendo todos os componentes do pedido na mesma partição para que o acesso seja eficiente. Cada pedido consiste em vários itens:

A tabela inclui a desnormalização estratégica de account_rep_id (duplicada da tabela de clientes) para permitir consultas diretas aos representantes de contas sem exigir consultas sobre clientes. Em cenários de gravação de alto throughput, os pedidos OPEN incluem atributos de status e fragmento para permitir a fragmentação de gravação em várias partições.

Quatro GSIs permitem diferentes padrões de consulta com projeções otimizadas:

Design de tabela de produtos

A tabela de produtos usa o padrão de coleção de itens para armazenar metadados do produto e dados de inventário na mesma partição. Esse design utiliza a relação de identificação entre produtos e inventário: não pode haver inventário sem um produto principal. Usar PK=product_id com SK=product_id para metadados do produto e SK=warehouse_id para itens de inventário elimina a necessidade de uma tabela de inventário e GSI separados e reduz os custos em aproximadamente 50%.

Esse padrão permite consultas eficientes tanto para o inventário individual do armazém (GetItem com chave composta) quanto para todo o inventário do armazém de um produto (consulta na chave de partição). O atributo total_inventory no item de metadados do produto oferece agregação desnormalizada para pesquisas rápidas de inventário total.

Cada tabela é projetada com índices secundários globais (GSIs) específicos para atender de forma eficiente aos padrões de acesso necessários. O design usa princípios de agregação com desnormalização estratégica e indexação esparsa para otimizar o desempenho e o custo.

As principais otimizações de design incluem:

Por fim, você pode reanalisar os padrões de acesso que foram definidos anteriormente. A tabela a seguir mostra como cada padrão de acesso é atendido de forma eficiente usando o design de várias tabelas com GSIs estratégicos. Cada padrão usa pesquisas de chave diretas ou consultas de GSI único, o que evita verificações caras e oferece desempenho consistente em qualquer escala.