Diseño de tabla única en DynamoDB

Viniendo de SQL, el instinto es una tabla por entidad: customers, orders, order_items. En DynamoDB ese instinto suele estar equivocado. Una única tabla que almacena todas las entidades, distinguidas por prefijos de clave sobrecargados, te permite obtener un padre y sus hijos en una Query — sin uniones, sin N+1.

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

El diseño de tabla única almacena cada entidad — clientes, pedidos, líneas de pedido — en una sola tabla de DynamoDB, distinguidas por prefijos sobrecargados de clave de partición y de clave de ordenación. Como las claves se diseñan en torno a tus patrones de acceso en lugar de a tus entidades, un padre y todos sus hijos viven en una colección de Items y vuelven en una sola Query — sin uniones, sin lecturas N+1.

La idea

Elige nombres de clave genéricos (PK, SK) y codifica el tipo de entidad en el valor:

Ahora una Query PK = "CUSTOMER#42" devuelve el perfil y cada pedido en una única lectura facturada. SK begins_with "ORDER#" la acota solo a los pedidos.

Visualmente, los Items sobrecargados se apilan bajo una sola clave de partición como una única colección de Items:

Una lectura de la partición devuelve el cliente y todos los pedidos juntos.

GSI sobrecargados

El mismo truco funciona en los índices. Pon un GSI1PK/GSI1SK genérico en los Items, y un único GSI sirve varios patrones de acceso según lo que cada Item escriba en esos atributos:

Ahora Query GSI1 WHERE GSI1PK = "STATUS#OPEN" lista los pedidos abiertos por fecha — un patrón que la tabla base no puede responder. Una entidad distinta puede reutilizar GSI1 con su propio significado (p. ej. CATEGORY#books). Un índice, muchas consultas.

De muchos a muchos: la lista de adyacencia

Para las relaciones (un usuario en muchos equipos, un equipo con muchos usuarios), escribe la arista dos veces con los ids intercambiados: PK=USER#1, SK=TEAM#9 y PK=TEAM#9, SK=USER#1. Consultar cualquier lado lista el otro — el sustituto de DynamoDB para una tabla de unión.

Cuándo no usar tabla única

No sale gratis. Una tabla sobrecargada es más difícil de razonar, más difícil de evolucionar y hostil para la analítica. Si tus patrones de acceso son genuinamente desconocidos o cambian constantemente, o los datos son mayormente analíticos, tablas separadas (u otro almacén) pueden ser la decisión más sensata. La tabla única gana cuando los patrones son conocidos y de alto volumen.

El coste de la forma equivocada

Modelar como tablas separadas obliga a un Scan o a una unión en el lado del cliente para reensamblar un cliente, y esa es la trampa del Scan. Modela primero los patrones de acceso, luego diseña las claves para que cada uno sea una Query. (Para la pregunta ad hoc entre entidades que nunca modelaste, el SQL Workbench de DynoTable ejecuta el JOIN en el lado del cliente — explorar no tiene que esperar a un remodelado.)

Esboza el propio diseño con la herramienta de diseño de tabla única gratuita — convierte tu lista de patrones de acceso en un plan de PK/SK/GSI con Items de ejemplo y pistas de coste. Estima cuánto cuestan estos Items por lectura con la calculadora de tamaño de Items y capacidad, y prueba DynoTable para explorar un esquema de tabla única y ver las colecciones sobrecargadas una al lado de la otra.