NoSQL: MongoDB, Redis y DynamoDB

MongoDB guarda documentos en colecciones. Internamente usa BSON, un JSON binario con tipos adicionales como fechas, ObjectId o decimales exactos. El esquema es flexible: dos documentos de la misma colección pueden tener campos distintos, y puedes incrustar datos relacionados, como las líneas de un pedido dentro del pedido, para leerlo todo de una vez sin uniones.

Las consultas se escriben como objetos de filtro, y los análisis, con el pipeline de agregación: una lista de etapas que transforman los documentos paso a paso ($match filtra, $group agrupa, $sort ordena, $lookup une con otra colección). Admite índices simples, compuestos, sobre arrays, de texto y geográficos, transacciones con varios documentos, replicación y sharding integrados.

Redis guarda pares clave-valor en memoria, pero el valor no es solo un texto: es una estructura de datos. Strings, que también sirven de contadores atómicos con INCR; hashes, objetos de campos y valores; listas, que funcionan como colas; sets, conjuntos sin repetidos; y sorted sets, elementos ordenados por una puntuación, perfectos para rankings. Como todo está en RAM, las operaciones son rapidísimas.

Cada clave puede tener un TTL (tiempo de vida) y desaparecer sola al caducar, lo que lo hace ideal para cachés y sesiones. Para no perderlo todo al reiniciar, ofrece dos formas de persistencia: RDB, instantáneas periódicas, y AOF, un registro de cada escritura; puedes combinarlas o desactivarlas si solo lo usas como caché.

En 2024 Redis dejó de publicarse con su licencia libre original y, como respuesta, la Linux Foundation impulsó Valkey, un fork compatible con los comandos de Redis. Desde entonces los dos proyectos siguen caminos propios, así que, si usas un servicio gestionado, comprueba cuál de los dos tienes detrás. Verás Redis como caché a fondo en el módulo de caché y mensajería.

DynamoDB es un servicio totalmente gestionado de AWS: no hay servidores que administrar ni conexiones que agotar, y ofrece latencias bajas y estables tenga la tabla mil elementos o mil millones. Cada elemento se identifica por su clave primaria, que puede ser solo una clave de partición o una clave de partición más una clave de ordenación.

La clave de partición decide en qué partición física se guarda el elemento; la de ordenación ordena los elementos dentro de esa partición y permite consultar rangos, como «los pedidos de este cliente en noviembre». Leer por clave (GetItem, Query) es rápido y barato; un Scan recorre la tabla entera. Los índices secundarios globales (GSI) permiten consultar por otras claves.

Es habitual el diseño de tabla única (single-table design): guardar varios tipos de entidad en la misma tabla con claves genéricas, como PK = CLIENTE#7 y SK = PEDIDO#2026-11-02, para que una sola consulta traiga un cliente y sus pedidos. En capacidad eliges entre bajo demanda, pagas por petición, sin planificar, y aprovisionada, reservas capacidad de lectura y escritura, más barata con tráfico estable.

En una base relacional modelas las entidades y sus relaciones, normalizas, y casi cualquier consulta futura se resuelve con un JOIN. En NoSQL, sobre todo en DynamoDB y en buena medida en MongoDB, se trabaja al revés: empiezas por la lista de patrones de acceso, las preguntas concretas que hará tu app, y diseñas claves, índices y documentos para que cada una se responda con una sola lectura.

Eso suele implicar duplicar datos a propósito, por ejemplo guardar el nombre del cliente dentro de cada pedido: es la desnormalización, que verás en la próxima lección. Lo que ganas es que cada lectura sea directa y predecible, tenga la tabla el tamaño que tenga.

Las fronteras entre familias se han difuminado. PostgreSQL guarda e indexa documentos con JSONB; MongoDB ofrece transacciones con varios documentos y uniones con $lookup; Redis añade módulos y funciones para documentos JSON o búsquedas. Una base de datos multimodelo es la que combina varios de estos modelos en un mismo motor.

La consecuencia práctica: a menudo no necesitas una base de datos distinta para cada tipo de dato. Una sola bien elegida cubre varios casos y te ahorra operar, respaldar y vigilar más piezas.