MongoDB
Introducción a MongoDB como base documental: documentos BSON, colecciones, patrones de acceso, atomicidad, consultas, índices y trade-offs frente a otros sistemas.
MongoDB es un sistema de base de datos documental. Guarda información en documentos BSON agrupados en colecciones y permite consultarlos, modificarlos, indexarlos, replicarlos y distribuirlos entre varios servidores.
La palabra documental no significa que almacene archivos de texto ni que carezca de estructura. Significa que la unidad principal de información es un documento capaz de contener campos escalares, objetos anidados y arrays. Esa estructura permite representar como una sola unidad datos que el sistema suele leer y modificar juntos.
{
_id: ObjectId('...'),
businessId: ObjectId('...'),
customer: {
id: ObjectId('...'),
name: 'Laura Gómez'
},
items: [
{
productId: ObjectId('...'),
name: 'Café',
quantity: 2,
unitPrice: Decimal128('12000.00')
}
],
status: 'pending',
createdAt: ISODate('2026-07-24T12:00:00Z')
}Este documento podría representar una orden. El nombre y precio de cada producto pueden conservarse como snapshot histórico, aunque el producto real exista en otra colección.
Un sistema necesita guardar información y recuperarla según casos de uso reales. En un modelo estrictamente relacional, una orden, su cliente y sus líneas suelen dividirse entre varias tablas y reconstruirse mediante joins. MongoDB ofrece otra opción: mantener dentro del mismo documento la información relacionada que comparte acceso, ownership y ciclo de vida.
Esto puede reducir viajes, joins y coordinación entre varias escrituras. A cambio, el equipo debe decidir conscientemente:
MongoDB no elimina el diseño de datos. Lo desplaza hacia los patrones de acceso y los límites de cada aggregate documental.
necesidad del dominio
↓
patrones de lectura y escritura
↓
límite del documento
↓
colecciones y schemas
↓
consultas e índices
↓
consistencia, distribución y operaciónA nivel de ejecución:
aplicación
↓
driver oficial u ODM
↓
MongoDB Server
↓
database
↓
collection
↓
documents BSONLa aplicación no escribe directamente en archivos del servidor. Utiliza un driver que serializa valores a BSON, mantiene conexiones, selecciona nodos y envía comandos. El servidor valida, planifica, ejecuta y persiste la operación.
Es un namespace lógico que agrupa colecciones y configuración. No es un servidor independiente. Un mismo proceso puede alojar varias databases, aunque la separación operativa real requiere diseñar usuarios, recursos y despliegues.
Agrupa documentos con propósito y patrones de acceso relacionados. Puede tener documentos con variaciones estructurales, pero eso no significa que mezclar cualquier forma sea saludable. Las colecciones pueden tener validators, índices, collation y opciones especiales.
Es la unidad BSON que MongoDB lee y escribe de forma atómica en operaciones individuales. Puede contener subdocumentos y arrays. El límite del documento influye en atomicidad, localidad, crecimiento y contention.
Un campo tiene un nombre y un valor BSON. Los tipos importan para comparación, orden, índices y serialización. El número 10, la cadena '10' y un Decimal128('10.00') no son equivalentes.
Una query expresa qué documentos interesan y cómo deben filtrarse, ordenarse o proyectarse. Cuando devuelve varios resultados, el driver normalmente consume un cursor por batches; no recibe necesariamente toda la colección de una vez.
Una session permite asociar operaciones para causal consistency, retryable writes o transacciones. Un cluster puede ser un replica set o un sharded cluster; no toda instalación necesita sharding.
PostgreSQL organiza información alrededor de tablas, relaciones, constraints y joins. MongoDB permite agrupar datos relacionados dentro de documentos cuando comparten acceso y cambios. Ninguno es universalmente superior.
MongoDB suele ser atractivo cuando:
PostgreSQL puede ser una mejor base cuando:
Un key-value store recupera principalmente un valor por clave. MongoDB permite filtros sobre campos, índices secundarios, aggregation y updates parciales. Esa capacidad añade flexibilidad, pero también un planner, estructuras de índices y mayor complejidad operativa.
MongoDB puede realizar text search básico y, en entornos compatibles, integrarse con MongoDB Search. No obstante, un motor de búsqueda está especializado en relevancia, análisis lingüístico, autocomplete y recuperación textual. No conviene reemplazar esas capacidades con regex sobre una colección grande.
MongoDB ofrece atomicidad por documento para una escritura individual. También soporta transacciones multi-documento, replica sets y sharding. Sin embargo:
Supón este caso de uso:
Mostrar las 20 órdenes pendientes más recientes de un negocio, incluyendo cliente, total y fecha.
Antes de crear la colección, el diseño debería registrar:
filtro: businessId + status
orden: createdAt DESC + _id DESC
proyección: customer, total, createdAt
frecuencia: alta
consistencia: lectura desde primary después de crear una ordenEsa query shape orienta el documento y un posible índice:
db.orders.createIndex({
businessId: 1,
status: 1,
createdAt: -1,
_id: -1
});La estructura y el índice no nacieron de una lista genérica de campos. Nacieron de una operación concreta.
MongoDB puede introducir más trabajo que beneficio cuando el equipo lo elige únicamente por “flexibilidad”, sin access patterns definidos. También merece reconsiderarse si el dominio necesita relaciones transversales impredecibles, constraints referenciales complejos o reporting que cambia continuamente y depende de muchos joins.
Usar MongoDB tampoco evita aprender índices, concurrencia, backups, capacidad y seguridad. En producción, una base documental mal modelada puede generar documentos gigantes, duplicación inconsistente, scans completos y hotspots de escritura.
Los documentos siempre tienen una estructura observable. La diferencia es que el servidor puede aceptar variaciones si no se configura validación. El schema existe aunque esté implícito; la pregunta es si está diseñado, documentado y protegido.
MongoDB almacena BSON. JSON sirve para representar algunos valores, pero BSON incorpora tipos como ObjectId, Date, Binary, Decimal128 y enteros con distintos rangos.
Embedding mejora localidad cuando los datos pertenecen a la misma unidad y crecen de forma controlada. No es apropiado para relaciones ilimitadas, entidades independientes o datos que generan fan-out de actualizaciones.
Sharding requiere elegir una shard key, desplegar infraestructura, observar distribución y adaptar queries. Una clave deficiente puede crear hotspots o scatter-gather.
MongoDB no es una lista de métodos CRUD. Es un sistema de persistencia documental cuyo diseño comienza con el dominio y los access patterns. El documento funciona como unidad de localidad y atomicidad; sus límites determinan gran parte del rendimiento y la consistencia.
Arquitectura general de MongoDB.