Patrones de diseño de tablas en Amazon DynamoDB - Diseño de tabla única y uso de GSI
Explicamos el diseño de claves de partición en DynamoDB, el diseño de tabla única y la implementación de patrones de acceso mediante GSI.
Descripción general de DynamoDB
DynamoDB es una base de datos NoSQL completamente administrada que proporciona latencia a nivel de milisegundos. A diferencia de RDS, no tiene esquema y accede a los datos mediante la combinación de clave de partición y clave de ordenación. En arquitecturas serverless, se puede usar combinado con Lambda y API Gateway. Ofrece dos modos de capacidad: bajo demanda y provisionado. DynamoDB escala automáticamente por partición, con cada partición manejando hasta 10 GB de datos y 3,000 RCU / 1,000 WCU por segundo. No hay límite superior en el tamaño de la tabla.
Diseño de tablas
La clave de partición está directamente relacionada con la distribución de datos, por lo que se seleccionan atributos con alta cardinalidad (ID de usuario, ID de pedido). En el diseño de tabla única, se añaden prefijos como "USER#123" u "ORDER#456" a la PK, y se expresa el tipo de entidad y las relaciones en la SK. Al especificar la PK con Query, se puede obtener la información del usuario y el historial de pedidos en una sola consulta. Los GSI corresponden a diferentes patrones de acceso (buscar usuarios por email, buscar pedidos por rango de fechas) y se pueden crear hasta 20 por tabla. Elegir valores de baja cardinalidad como fechas o códigos de estado para las claves de partición a veces concentra el acceso en particiones específicas y genera particiones calientes. En este caso, se añade un sufijo a la clave (valor aleatorio o parte de la marca de tiempo) para distribuir las solicitudes.
GSI y diseño de tabla única
Los Global Secondary Index (GSI) ejecutan consultas con claves de partición y ordenación diferentes a la tabla principal. En el diseño de tabla única, se almacenan múltiples entidades (usuarios, pedidos, productos) en una sola tabla y se abordan diversos patrones de acceso mediante la sobrecarga de GSI. Se añaden prefijos como 'USER#123' a la PK y 'ORDER#456' a la SK, filtrando entidades con la condición begins_with. Los índices dispersos incluyen solo los ítems con un atributo específico en el índice, lo que permite contener el tamaño y el costo del índice.
Mejores prácticas de diseño y errores comunes
El diseño de tabla única no es adecuado para todos los casos. Para aplicaciones con relaciones complejas entre entidades y patrones de acceso que cambian frecuentemente, separar las tablas puede ser más fácil de operar. El throttling de escritura de GSI se propaga a la tabla principal, por lo que la capacidad de GSI debe diseñarse para seguir el ritmo del volumen de escritura de la tabla principal. Con BatchWriteItem, a veces una parte de las escrituras se completa y el resto no se procesa, por lo que la aplicación reintenta los ítems no procesados. En patrones event-driven que combinan DynamoDB Streams con Lambda, el número de ejecuciones paralelas de Lambda depende del número de particiones. Adaptive Capacity eleva automáticamente el throughput de las particiones calientes, pero no puede exceder la capacidad provisionada total de la tabla.
Cuándo usar DynamoDB vs. RDS
DynamoDB se especializa en lecturas y escrituras basadas en clave, procesando búsquedas de clave simples y consultas de rango con baja latencia. Para consultas JOIN complejas, agregaciones y cargas de trabajo centradas en transacciones ACID, un enfoque es usar RDS (Aurora / PostgreSQL). Las transacciones de DynamoDB (TransactWriteItems / TransactGetItems) tienen un límite de 100 ítems y pueden agrupar ítems de varias tablas dentro de la misma cuenta de AWS y la misma región. DynamoDB se utiliza para fines como perfiles de usuario, almacenes de sesión, tablas de clasificación en tiempo real e ingesta de datos de dispositivos IoT. Para cargas de trabajo centradas en reportes y consultas analíticas, una opción es exportar de DynamoDB a S3 y analizar con Athena, o sincronizar con OpenSearch vía DynamoDB Streams.
Optimización de precios de DynamoDB
El modo bajo demanda de DynamoDB cobra según el número de solicitudes de lectura (RRU) y escritura (WRU). El modo provisionado cobra por hora de WCU/RCU, y para cargas de trabajo estables, al combinarlo con Auto Scaling la capacidad puede ajustarse a la carga. La capacidad reservada aplica descuentos. Los GSI consumen su propia capacidad, por lo que eliminar los GSI innecesarios y limitar los atributos de proyección permite contener los costos de almacenamiento. TTL elimina automáticamente datos expirados, controlando los costos de almacenamiento.
Resumen
DynamoDB es una base de datos NoSQL que accede a los datos mediante el diseño de claves de partición y ordenación. Aborda diversos patrones de acceso con sobrecarga de GSI y diseño de tabla única, y mantiene bajos los costos de índice con índices dispersos. Gestiona los costos diferenciando entre modos bajo demanda y provisionado, y con la eliminación automática de datos mediante TTL.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
- Amazon DynamoDB (página oficial)
- Amazon DynamoDB Accelerator (página oficial)
- AWS Lambda (página oficial)
- Documentación de AWS (oficial)
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.