MongoDB
Explica cuándo embeber datos relacionados dentro de un documento para mejorar localidad, atomicidad y lecturas, y qué límites impone el crecimiento.
significa guardar información relacionada dentro del mismo documento. No es una regla general de MongoDB, sino una estrategia útil cuando los datos comparten ownership, ciclo de vida, acceso y cambios.
{
_id: ObjectId('...'),
customer: {
id: ObjectId('...'),
name: 'Laura Gómez'
},
items: [
{
productId: ObjectId('...'),
name: 'Café molido',
quantity: 2,
unitPrice: Decimal128('18900.00')
}
],
total: Decimal128('37800.00'),
status: 'pending'
}En este ejemplo, la orden contiene un snapshot del cliente y de los productos comprados. Esos datos se consultan con la orden y deben conservar el estado histórico de la venta.
Cuando una operación necesita recuperar o modificar información relacionada como una unidad, dividirla entre varias colecciones puede introducir:
$lookup o joins en la aplicación;Embedding acerca datos que se usan juntos y permite aprovechar la atomicidad por documento.
order
├── customer snapshot
├── items[]
├── payment summary
└── delivery addressLa frontera del documento se convierte en frontera de lectura, escritura, atomicidad y crecimiento.
Un perfil de preferencias que no tiene sentido fuera del usuario puede vivir dentro del documento:
{
_id: userId,
profile: {
displayName: 'Nicolás',
locale: 'es-CO'
},
preferences: {
theme: 'dark',
notifications: true
}
}Separarlo en varias colecciones no aporta integridad adicional y obliga a recomponer datos que siempre se usan juntos.
Direcciones recientes, métodos de contacto o una cantidad pequeña de configuraciones pueden embeberse si el crecimiento está acotado.
La palabra importante es acotado. “Normalmente hay pocos” no basta; debe existir una regla del dominio o una estrategia de límite.
Los items de una orden pertenecen a esa orden. Aunque hagan referencia a productos, la línea de venta no se administra como entidad independiente.
Un pedido debe conservar nombre y precio vendidos, incluso si el producto cambia después.
{
productId: ObjectId('...'),
name: 'Café molido',
unitPrice: Decimal128('18900.00')
}productId mantiene trazabilidad y los campos duplicados conservan el hecho histórico.
Una escritura sobre un único documento es atómica. Si una orden contiene items y total, se pueden actualizar juntos dentro de una operación:
db.orders.updateOne(
{
_id: orderId,
status: 'draft'
},
{
$push: {
items: {
productId,
name,
quantity: 2,
unitPrice
}
},
$inc: {
totalInCents: 37_800
}
}
);El documento no queda visible con el item agregado y el total antiguo. Sin embargo, esto no garantiza que el cálculo sea correcto si el valor enviado por la aplicación es erróneo. Atomicidad protege indivisibilidad, no lógica de negocio.
También debe analizarse concurrencia. Dos clientes pueden añadir items al mismo documento sin perder necesariamente cambios si usan operadores atómicos, pero un patrón read-modify-replace puede sobrescribir actualizaciones.
Embedding puede mejorar localidad porque la información se recupera desde una sola unidad lógica. Esto reduce round trips y coordinación.
Sin embargo, “una query” no equivale automáticamente a “más rápido”. Un documento muy grande puede obligar a leer y transferir datos innecesarios. La proyección ayuda, pero el tamaño, cache y patrón de actualizaciones siguen importando.
El principal riesgo de embedding aparece cuando la estructura crece sin límite.
Ejemplo problemático:
{
_id: productId,
reviews: [
// millones de reviews durante años
]
}Aunque el documento tarde en alcanzar 16 MiB, pueden aparecer antes:
Alternativas:
Un documento puede volverse hotspot cuando muchas operaciones intentan modificarlo.
Ejemplo:
{
_id: businessId,
everyOrderEver: [/* ... */]
}Todas las órdenes de un negocio competirían sobre la misma unidad. El problema no es solo tamaño: también es concentración de escrituras.
Embedding funciona mejor cuando la unidad representa un aggregate natural y las escrituras se distribuyen entre muchos documentos.
Embedding suele implicar duplicación. Esa duplicación puede ser correcta si se define su semántica.
No se actualiza cuando cambia la fuente.
order.customer.name
→ nombre al momento de comprarDebe actualizarse cuando cambia la fuente, quizá de forma eventual.
post.authorName
→ nombre visible actual del autorEn el segundo caso debe definirse:
Duplicar sin esa política produce datos ambiguos.
Una orden puede embeber la dirección utilizada:
{
deliveryAddress: {
recipient: 'Laura Gómez',
line1: 'Calle 10 # 20-30',
city: 'Bogotá',
countryCode: 'CO'
}
}¿Por qué no guardar solo addressId?
Porque si el usuario edita o elimina su dirección después, la orden debe conservar dónde se entregó. La dirección embebida representa un hecho histórico, no una copia accidental del perfil.
Aun así, puede conservarse también una referencia opcional:
{
sourceAddressId: ObjectId('...'),
deliveryAddress: { /* snapshot */ }
}La referencia sirve para trazabilidad; el snapshot sirve para historia.
Los arrays permiten updates atómicos con operadores como $push, $pull, $addToSet, $[] y array filters. Pero deben analizarse:
Si los elementos necesitan su propia paginación, lifecycle, permisos o queries independientes, una colección separada suele ser más clara.
MongoDB favorece documentos que sirven access patterns, no embedding universal. Entidades independientes y relaciones ilimitadas siguen necesitando separación.
Que una pantalla muestre datos juntos no significa que tengan el mismo ownership o ciclo de vida. Puede resolverse con composición en backend, cache o una vista derivada.
Un array promedio de 10 elementos puede tener outliers de 500.000. El diseño debe considerar distribución y límites explícitos.
Cambiar el nombre en órdenes históricas puede destruir la evidencia de lo ocurrido. Define la semántica antes de implementar fan-out.
Leer el documento, modificar un array en memoria y ejecutar replaceOne puede perder cambios concurrentes. Prefiere operadores atómicos o control de versión.
Evítalo o limítalo cuando:
Embedding es una herramienta para representar una unidad coherente. Funciona bien cuando los datos comparten ownership, lifecycle, acceso y cambios, y cuando su crecimiento está controlado. El beneficio principal es localidad y atomicidad; los costes son crecimiento, duplicación, contention y menor independencia.
Referencing.