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. Se utiliza como almacén de datos estándar en arquitecturas serverless, 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, pudiendo almacenar cientos de TB de datos.
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 causa el problema de particiones calientes donde el acceso se concentra en particiones específicas. 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, reduciendo el tamaño y costo del índice. Para comprender en profundidad los patrones de diseño NoSQL, pueden ser útiles libros especializados (Amazon).
Mejores prácticas de diseño y errores comunes
El diseño de tabla única es ampliamente recomendado como mejor práctica de DynamoDB, pero 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. Al escribir más de 25 ítems con BatchWriteItem, siempre implemente lógica de reintentos para ítems no procesados. En patrones event-driven que combinan DynamoDB Streams con Lambda, note que la ejecución paralela 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, proporcionando latencia extremadamente baja para búsquedas de clave simples y consultas de rango. Las consultas JOIN complejas, agregaciones y cargas de trabajo centradas en transacciones ACID son más adecuadas para RDS (Aurora / PostgreSQL). Las transacciones de DynamoDB (TransactWriteItems / TransactGetItems) tienen un límite de 100 ítems y no soportan transacciones complejas que abarquen múltiples tablas. DynamoDB es ideal para 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, es más eficiente exportar de DynamoDB a S3 y analizar con Athena, o sincronizar a OpenSearch via DynamoDB Streams.
Optimización de precios de DynamoDB
El modo bajo demanda de DynamoDB cobra por lectura (aproximadamente 0.25 dólares/millón por 1 RRU) y escritura (aproximadamente 1.25 dólares/millón por 1 WRU). El modo provisionado cobra por hora de WCU/RCU, y para cargas de trabajo estables, la eficiencia de costos mejora combinándolo con Auto Scaling. La capacidad reservada aplica descuentos de hasta 77%. Los GSI consumen su propia capacidad, por lo que se eliminan GSI innecesarios y se minimizan los atributos de proyección para reducir costos de almacenamiento. TTL elimina automáticamente datos expirados, controlando los costos de almacenamiento.
Resumen
DynamoDB es una base de datos NoSQL que logra latencia en milisegundos 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 optimiza los costos de índice con índices dispersos. Gestiona los costos eficientemente diferenciando entre modos bajo demanda y provisionado, y con la eliminación automática de datos mediante TTL.