DynamoDB es el segundo servicio mas evaluado en el examen AWS DVA-C02. Entender el diseno de claves y los patrones de consulta es esencial para aprobar.
Que es exactamente DynamoDB?
Las bases de datos tradicionales como RDS o MySQL almacenan datos en estructuras de tablas fijas con filas y columnas. DynamoDB es una base de datos NoSQL — es flexible en estructura y extremadamente rapida (tiempos de respuesta en milisegundos).
Piensalo asi: si una base de datos tradicional es como una hoja de calculo, DynamoDB es como un monton de notas adhesivas. Cada nota adhesiva (elemento) puede tener contenido diferente, y puedes encontrar cualquiera de miles de millones de notas en un instante.
Diseno de clave primaria — La base de como se almacenan los datos
El concepto mas importante en DynamoDB es la clave primaria (Primary Key). La clave primaria determina en que servidor (particion) se almacenaran los datos.
Partition Key (Clave de particion)
La partition key decide como se distribuyen los datos entre multiples servidores. Piensala como los codigos postales de una oficina de correos: cuanto mas uniformemente distribuidos esten los codigos postales, mas rapidas seran las entregas.
El principio clave: siempre elige un atributo con muchos valores unicos (alta cardinalidad) como partition key.
Mal ejemplo: usar una fecha como partition key. Miles de registros creados el mismo dia van al mismo servidor, causando un embotellamiento. Esto se llama el problema de particion caliente (hot partition).
Buen ejemplo: usar el ID de usuario como partition key. Los datos de cada usuario se distribuyen en diferentes servidores, distribuyendo la carga uniformemente.
Sort Key (Clave de ordenacion)
La sort key ordena los datos dentro de la misma particion. Usar tanto una partition key como una sort key juntas habilita consultas por rango.
Por ejemplo, con el ID de usuario como partition key y el timestamp como sort key, puedes recuperar rapidamente la actividad reciente de un usuario especifico en orden cronologico.
Indices — Cuando necesitas buscar de multiples maneras
Con solo la clave primaria, solo puedes buscar datos de una manera. Cuando quieres buscar rapidamente por otros atributos, usas indices. Funciona igual que un indice en un libro: te ayuda a encontrar lo que necesitas sin leer todo el libro.
GSI (Global Secondary Index)
Un GSI te permite consultar usando partition key y sort key completamente diferentes a las de la tabla original. Puedes agregar un GSI en cualquier momento despues de crear la tabla, lo que lo hace muy flexible. Sin embargo, requiere capacidad provisionada separada.
Ejemplo: si tu tabla esta organizada por ID de usuario pero tambien quieres buscar por direccion de correo electronico, crea un GSI con el correo como partition key.
LSI (Local Secondary Index)
Un LSI mantiene la misma partition key que la tabla original pero usa una sort key diferente. La limitacion critica: un LSI solo se puede agregar cuando creas la tabla por primera vez. No puedes agregar uno despues, asi que planifica con anticipacion.
Query vs Scan — La clave para la recuperacion eficiente de datos
Query (Consulta)
Usa Query cuando conoces la partition key. Busca solo la particion relevante, lo que la hace muy eficiente y rapida. Piensalo como ir directamente a una seccion especifica de una biblioteca para encontrar un libro.
Scan (Escaneo)
Scan lee toda la tabla de principio a fin. Puede encontrar cualquier dato, pero como lee todo, es lento y costoso. Piensalo como abrir cada libro en la biblioteca para encontrar lo que necesitas.
Evita Scan siempre que sea posible. Si Scan es inevitable, usa ProjectionExpression para obtener solo los atributos que necesitas, y considera Parallel Scan para acelerar las cosas procesando multiples secciones a la vez.
!Query vs Scan en DynamoDB
Modelos de consistencia — Que tan recientes necesitas tus datos?
Despues de escribir datos en DynamoDB, puede haber un breve momento antes de que todos los servidores reflejen la actualizacion. DynamoDB ofrece dos opciones de lectura para manejar esto.
Eventualmente consistente (por defecto): el modo estandar de DynamoDB. Puede haber un leve retraso antes de que los datos mas recientes sean visibles. Cuesta la mitad y es suficiente para la mayoria de los casos de uso.
Fuertemente consistente: garantiza que lees los datos absolutamente mas recientes de inmediato. Usa la opcion ConsistentRead=True para habilitarlo. Cuesta el doble, pero es necesario para escenarios como transacciones financieras donde los datos desactualizados no son aceptables.
Transacciones — Cuando multiples operaciones deben tener exito o fallar juntas
Imagina una transferencia bancaria: el dinero debe deducirse de la Cuenta A y agregarse a la Cuenta B al mismo tiempo. Ambas operaciones deben tener exito juntas o fallar juntas. Para esto existen las transacciones.
TransactWriteItems: procesa operaciones de escritura en multiples elementos de forma atomica — todos tienen exito o todos fallan.
TransactGetItems: lee multiples elementos de forma atomica.
Las transacciones cuestan el doble que las operaciones normales. Usaelas solo cuando la atomicidad sea verdaderamente necesaria.
Operaciones en lote — Procesando multiples elementos a la vez
BatchWriteItem: escribe o elimina hasta 25 elementos en una sola solicitud.
BatchGetItem: lee hasta 100 elementos en una sola solicitud.
La diferencia clave con las transacciones: las operaciones en lote no son atomicas. Algunos elementos pueden tener exito mientras otros fallan. Los elementos fallidos se devuelven en UnprocessedItems y deben reintentarse.
Puntos clave para el examen
"Diseno de clave para consultas eficientes" -- Partition key de alta cardinalidad
"Consultar con diferentes atributos, se puede agregar despues de crear la tabla" -- GSI
"Misma partition key, diferente sort key, solo al crear" -- LSI
"Recuperacion eficiente de datos" -- Query (basada en partition key)
"Lee toda la tabla (ineficiente)" -- Scan
"Necesita datos mas recientes de inmediato" -- Consistencia fuerte (ConsistentRead=True)
"Escrituras atomicas en multiples elementos" -- TransactWriteItems
"Escritura masiva, fallos parciales posibles" -- BatchWriteItem (verificar UnprocessedItems)
Para evitar particiones calientes, elige una partition key con alta cardinalidad