Herramienta gratuita

Herramienta de diseño de tabla única de DynamoDB

Introduce tus entidades y cómo necesitas leerlas: el planificador sugiere plantillas de claves PK/SK prefijadas por entidad, previsualiza las colecciones de Items y añade un GSI solo donde la tabla base no puede servir un patrón.

Entidades
Patrones de acceso
Esquema de claves sugerido
EntidadPKSK
UserUSER#<userId>USER#<userId>
Order
en la colección de Items de User
USER#<userId>ORDER#<orderDate>#<orderId>
GetItem · tabla baseObtener User por ID
PK = USER#<userId> AND SK = USER#<userId>
Query · tabla baseListar Order bajo User
PK = USER#<userId> AND begins_with(SK, 'ORDER#') ScanIndexForward: false
  • Las claves de ordenación se comparan como cadenas: almacena el atributo de ordenación en un formato ordenable (fechas ISO-8601, números con ceros a la izquierda).
Query · GSI1Encontrar User por email
GSI1PK = USER#EMAIL#<email>
  • Un GSI no impone unicidad: protege contra duplicados en el momento de la escritura con una expresión de condición sobre el Item base.
Índices secundarios globales
GSI1Indexa los Items de User
GSI1PK = USER#EMAIL#<email> GSI1SK = USER#EMAIL#<email>
  • Un GSI no impone unicidad: protege contra duplicados en el momento de la escritura con una expresión de condición sobre el Item base.
Items de ejemplo
EntidadPKSKGSI1Atributos
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
Definición de la tabla (JSON de CreateTable)
{
  "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 simple para aws dynamodb create-table --cli-input-json: atributos PK/SK genéricos de tipo string, GSI con proyección ALL, facturación On-Demand.

Pistas de coste
Unidades de lectura por Item (consistencia eventual)
0,5 RCU
Unidades de escritura por Item
1 WCU
Estimación mensual On-Demand (us-east-1): solo la tabla base
4,93 US$
Incluyendo la replicación de escrituras en los GSI (×1)
8,21 US$

Cada GSI almacena su propia copia proyectada de cada Item, así que una escritura en la tabla también consume capacidad de escritura en cada GSI. La estimación asume una proyección completa y usa el mismo redondeo de 4 KB por lectura / 1 KB por escritura que nuestras calculadoras de precios y de tamaño de Items.

De los patrones de acceso a un esquema de claves

El diseño de tabla única parte de las lecturas, no de las entidades: en lugar de normalizar tablas y unirlas en el momento de la consulta, enumeras todas las formas en que la aplicación necesita obtener datos —obtener un usuario por ID, listar los pedidos de un usuario del más reciente al más antiguo, encontrar una cuenta por email— y das forma a las claves para que cada una sea un solo GetItem o Query. Cada patrón que la tabla base no puede responder te cuesta un índice, y esa compensación debería ser visible antes de crear la tabla.

Este planificador hace explícita esa compensación. Aplica de forma determinista las reglas estándar de tabla única —claves compuestas prefijadas por entidad, colecciones de Items para los patrones de uno a muchos, GSI invertidos o acotados por atributo para el resto— y donde un patrón no puede servirse de forma limpia, lo dice en lugar de fingir. La tabla de Items de ejemplo muestra cómo se sitúan realmente las filas resultantes unas junto a otras dentro de una partición.

La salida es un documento JSON de CreateTable simple con atributos de clave genéricos de tipo string —nada específico de la herramienta que haya que deshacer luego— más pistas de coste que reutilizan el mismo redondeo de 4 KB por lectura / 1 KB por escritura que usan nuestras calculadoras de precios y de tamaño de Items.

¿Nuevo en los conceptos o no sabes si el enfoque encaja con tu carga de trabajo? Nuestra guía de diseño de tabla única explica la idea desde los primeros principios, y cuándo NO usarlo cubre los contraejemplos honestos. Una vez definido el esquema, compón la solicitud real en el Generador de consultas de DynamoDB o estima la factura mensual completa con la Calculadora de precios de DynamoDB.

Preguntas frecuentes

¿Qué es el diseño de tabla única en DynamoDB?

Un enfoque de modelado en el que todos los tipos de entidad de una aplicación comparten una sola tabla con atributos genéricos de clave de partición y de ordenación (PK/SK). Los Items relacionados comparten una clave de partición, de modo que una sola Query los obtiene juntos: el diseño lo guían tus patrones de acceso en lugar de las formas normalizadas de las entidades.

¿Cómo decide este planificador el diseño de las claves?

Con reglas fijas y publicadas: deterministas, no generativas. Cada entidad empieza como la raíz de su propia colección de Items con claves prefijadas por entidad; el primer patrón de listar hijos mueve al hijo a la partición de su padre mediante una clave de ordenación compuesta; las búsquedas por otros atributos, los segundos padres y los patrones de listar todo se convierten en sugerencias de GSI; y un patrón que las reglas no pueden servir de forma limpia se marca como no admitido en lugar de recibir un diseño inventado.

¿Cuándo necesita un patrón de acceso un índice secundario global?

Cuando la disposición de claves de la tabla base no puede responderlo: obtener un hijo re-alojado por su propio ID, listar los mismos Items bajo un segundo padre, encontrar un Item por un atributo que no es clave como un email, o listar todos los Items de un tipo. Cada uno de esos casos vuelve a asignar claves a los mismos datos, algo que solo un índice puede hacer: el planificador sugiere uno por cada forma de clave y lo reutiliza en los patrones que comparten esa forma.

¿Cómo afectan los GSI al coste de DynamoDB?

Cada GSI mantiene su propia copia proyectada de los Items que cubre, así que cada escritura en la tabla también consume capacidad de escritura en cada GSI que proyecta el Item, y el almacenamiento se factura por copia. La tarjeta de coste muestra una estimación de la tabla base y otra que incluye la replicación de escrituras en los GSI, usando el mismo redondeo de 4 KB por lectura / 1 KB por escritura que nuestras calculadoras de precios y de tamaño de Items.

¿El planificador sube mi modelo de datos a algún sitio?

No. La página es estática y el diseño se calcula enteramente en tu navegador: los nombres de las entidades, los atributos de ID y los patrones de acceso nunca llegan a un servidor. La única forma en que un diseño sale de la página es la URL de «Copiar enlace», que lo empaqueta en el propio enlace para que compartirlo siga siendo un acto deliberado.

Trabaja con DynamoDB sin la Consola

DynoTable es un cliente de escritorio rápido para DynamoDB: explora tablas, ejecuta consultas estilo SQL y edita Items localmente.