Ferramenta gratuita

Ferramenta de Single-Table Design do DynamoDB

Informe suas entidades e como você precisa lê-las — o planejador sugere modelos de chave PK/SK prefixados pela entidade, prevê as coleções de itens e adiciona um GSI apenas onde a tabela base não consegue atender um padrão.

Entidades
Padrões de acesso
Esquema de chaves sugerido
EntidadePKSK
UserUSER#<userId>USER#<userId>
Order
na coleção de itens User
USER#<userId>ORDER#<orderDate>#<orderId>
GetItem · tabela baseObter User por ID
PK = USER#<userId> AND SK = USER#<userId>
Query · tabela baseListar Order sob User
PK = USER#<userId> AND begins_with(SK, 'ORDER#') ScanIndexForward: false
  • As chaves de ordenação são comparadas como strings — armazene o atributo de ordenação em um formato ordenável (datas ISO-8601, números preenchidos com zeros).
Query · GSI1Encontrar User por email
GSI1PK = USER#EMAIL#<email>
  • Um GSI não impõe unicidade — proteja-se contra duplicatas no momento da escrita com uma condition expression no item base.
Índices secundários globais
GSI1Indexa os itens de User
GSI1PK = USER#EMAIL#<email> GSI1SK = USER#EMAIL#<email>
  • Um GSI não impõe unicidade — proteja-se contra duplicatas no momento da escrita com uma condition expression no item base.
Itens de exemplo
EntidadePKSKGSI1Atributos
UserUSER#user-1USER#user-1USER#EMAIL#user-1@example.com USER#EMAIL#user-1@example.comuserId: user-1, email: user-1@example.com
OrderUSER#user-1ORDER#2025-06-01#order-1orderId: order-1, orderDate: 2025-06-01, userId: user-1
OrderUSER#user-1ORDER#2025-06-02#order-2orderId: order-2, orderDate: 2025-06-02, userId: user-1
Definição da tabela (CreateTable JSON)
{
  "TableName": "AppTable",
  "BillingMode": "PAY_PER_REQUEST",
  "AttributeDefinitions": [
    {
      "AttributeName": "PK",
      "AttributeType": "S"
    },
    {
      "AttributeName": "SK",
      "AttributeType": "S"
    },
    {
      "AttributeName": "GSI1PK",
      "AttributeType": "S"
    },
    {
      "AttributeName": "GSI1SK",
      "AttributeType": "S"
    }
  ],
  "KeySchema": [
    {
      "AttributeName": "PK",
      "KeyType": "HASH"
    },
    {
      "AttributeName": "SK",
      "KeyType": "RANGE"
    }
  ],
  "GlobalSecondaryIndexes": [
    {
      "IndexName": "GSI1",
      "KeySchema": [
        {
          "AttributeName": "GSI1PK",
          "KeyType": "HASH"
        },
        {
          "AttributeName": "GSI1SK",
          "KeyType": "RANGE"
        }
      ],
      "Projection": {
        "ProjectionType": "ALL"
      }
    }
  ]
}

JSON simples para aws dynamodb create-table --cli-input-json — atributos PK/SK genéricos do tipo string, GSIs projetados como ALL, cobrança On-Demand.

Dicas de custo
Unidades de leitura por item (consistência eventual)
0,5 RCU
Unidades de escrita por item
1 WCU
Estimativa mensal On-Demand (us-east-1) — apenas tabela base
US$ 4,93
Incluindo a replicação de escrita dos GSIs (×1)
US$ 8,21

Cada GSI armazena sua própria cópia projetada de cada item, então uma escrita na tabela também consome capacidade de escrita em cada GSI. A estimativa pressupõe projeção completa e usa o mesmo arredondamento de 4 KB para leitura / 1 KB para escrita das nossas calculadoras de preços e de tamanho de item.

Dos padrões de acesso a um esquema de chaves

O single-table design parte das leituras, não das entidades: em vez de normalizar tabelas e fazer joins no momento da consulta, você lista todas as formas como a aplicação precisa buscar dados — obter um usuário por ID, listar os pedidos de um usuário do mais recente para o mais antigo, encontrar uma conta por e-mail — e molda as chaves para que cada uma seja um único GetItem ou Query. Todo padrão que a tabela base não consegue responder custa um índice, e essa troca deveria estar visível antes de você criar a tabela.

Este planejador torna a troca explícita. Ele aplica as regras padrão de single-table de forma determinística — chaves compostas prefixadas pela entidade, coleções de itens para padrões de um-para-muitos, GSIs invertidos ou restritos a atributos para o resto — e, onde um padrão não pode ser atendido de forma limpa, ele diz isso em vez de fingir. A tabela de itens de exemplo mostra como as linhas resultantes realmente ficam lado a lado dentro de uma partição.

A saída é um documento JSON de CreateTable simples, com atributos de chave genéricos do tipo string — nada específico da ferramenta para desfazer depois — mais dicas de custo que reutilizam o mesmo arredondamento de 4 KB para leitura / 1 KB para escrita que nossas calculadoras de preços e de tamanho de item usam.

Novo nesses conceitos ou em dúvida se a abordagem serve para a sua carga de trabalho? Nosso guia de single-table design explica a ideia a partir dos princípios fundamentais, e quando NÃO usá-lo cobre os contra-exemplos honestos. Uma vez definido o esquema, componha a solicitação de fato no Construtor de Consultas do DynamoDB ou estime a conta mensal completa com a Calculadora de Preços do DynamoDB.

Perguntas frequentes

O que é single-table design no DynamoDB?

Uma abordagem de modelagem em que todos os tipos de entidade de uma aplicação compartilham uma única tabela com atributos genéricos de chave de partição e de ordenação (PK/SK). Itens relacionados compartilham uma chave de partição, então uma única Query os busca juntos — o design é guiado pelos seus padrões de acesso, e não por formatos de entidade normalizados.

Como este planejador decide o design das chaves?

Com regras fixas e publicadas — determinísticas, não generativas. Cada entidade começa como a raiz da sua própria coleção de itens, com chaves prefixadas pela entidade; o primeiro padrão de listar filhos move o filho para a partição do pai em uma chave de ordenação composta; buscas por outros atributos, segundos pais e padrões de listar tudo viram sugestões de GSI; e um padrão que as regras não conseguem atender de forma limpa é marcado como não suportado em vez de receber um design inventado.

Quando um padrão de acesso precisa de um índice secundário global?

Quando o layout de chaves da tabela base não consegue respondê-lo: buscar um filho realocado pelo próprio ID, listar os mesmos itens sob um segundo pai, encontrar um item por um atributo que não é chave, como um e-mail, ou listar todos os itens de um tipo. Cada um deles reindexa os mesmos dados, algo que só um índice pode fazer — o planejador sugere um por formato de chave e o reutiliza entre os padrões que compartilham o formato.

Como os GSIs afetam o custo do DynamoDB?

Cada GSI mantém sua própria cópia projetada dos itens que cobre, então cada escrita na tabela também consome capacidade de escrita em todo GSI que projeta o item, e o armazenamento é cobrado por cópia. O cartão de custo mostra uma estimativa da tabela base e outra com a replicação de escrita dos GSIs incluída, usando o mesmo arredondamento de 4 KB para leitura / 1 KB para escrita das nossas calculadoras de preços e de tamanho de item.

O planejador envia meu modelo de dados para algum lugar?

Não. A página é estática e o design é calculado inteiramente no seu navegador — nomes de entidade, atributos de ID e padrões de acesso nunca chegam a um servidor. A única forma de um design sair da página é a URL do “Copiar link”, que o empacota no link para que compartilhar continue sendo um ato deliberado.

Trabalhe com o DynamoDB sem o Console

O DynoTable é um cliente desktop rápido para o DynamoDB — navegue pelas tabelas, execute consultas no estilo SQL e edite itens localmente.