¿Qué es MongoDB? Características, modelado de documentos y cuándo usarlo

MongoDB es una base de datos que almacena datos como documentos en lugar de organizarlos principalmente en tablas relacionales. Considérelo para datos que se leen comúnmente juntos, como catálogos de productos con atributos variados o perfiles de usuario anidados, mientras se diseña el esquema y se verifica el rendimiento.

Esta guía explica el modelo de almacenamiento de MongoDB, sus características, casos de uso y criterios de adopción. Para un panorama más amplio, vea la comparación de modelos NoSQL y bases de datos relacionales.

¿Cómo almacena datos MongoDB?

Un documento consiste en pares de campo y valor. Una colección es un agrupamiento lógico de documentos, y una base de datos puede contener colecciones para diferentes propósitos, como productos, pedidos y clientes.

MongoDB almacena documentos como BSON (JSON Binario). BSON expresa estructuras JSON (Notación de Objetos de JavaScript) en forma binaria y admite tipos adicionales, incluidos fechas y valores ObjectId. Por lo tanto, MongoDB no debe entenderse como un almacén que simplemente guarda archivos de texto JSON. El documento de referencia explica los tipos y las reglas de identificación.

Este ejemplo JSON de un producto ficticio ilustra la forma de un documento. En una colección estándar, _ididentifica un documento. El ejemplo utiliza una cadena legible; una aplicación aún necesita un formato de identificador y reglas para manejar duplicados.

{
  "_id": "book-101",
  "name": "Database Basics",
  "category": "books",
  "price_krw": 24000,
  "attributes": {
    "author": "Mina Kim",
    "pages": 320
  },
  "tags": [
    "database",
    "beginner"
  ]
}

attributes es un objeto anidado y tags es un arreglo. Los libros pueden tener campos de autor y páginas, mientras que los electrónicos tienen información de la batería. Conservar las reglas compartidas para los tipos de precios, campos requeridos y valores faltantes.

Principales características y sus condiciones

Esquema flexible y validación

Un esquema define campos, tipos y condiciones requeridas. MongoDB no requiere que cada documento en una colección tenga campos idénticos por defecto. Esa flexibilidad no elimina el diseño del esquema.

La validación de esquemas puede restringir los tipos permitidos y los rangos de valores. Coordine las comprobaciones de la aplicación y la validación de la base de datos para evitar precios mezclados de números/cadenas o representaciones de fechas inconsistentes. Antes de agregar reglas a datos existentes, identifique documentos que no cumplan y decida cómo se manejarán las actualizaciones.

Consultas, agregación y datos relacionados

Las consultas de MongoDB utilizan condiciones de campo y operadores en lugar de aceptar declaraciones SQL sin cambios. Aprenda la sintaxis utilizada por el controlador de su lenguaje o la consola. La notación de puntos accede a campos anidados, y las consultas también pueden expresar condiciones de matrices.

Una canalización de agregación procesa documentos a través de etapas como filtrado, agrupamiento y cálculo. Por ejemplo, filtrar los artículos de pedido no cancelados y sumar las cantidades por producto. La guía de canalización de agregación explica cómo funcionan las etapas.

$lookup proporciona un join externo izquierdo a otra colección, por lo que “MongoDB no tiene joins” es inexacto. Revise $lookup soporte y condiciones de rendimiento. No asuma que las referencias automáticamente reciben la aplicación de integridad referencial asociada con las restricciones de clave externa relacionales.

Índices y rendimiento

Un índice es una estructura de datos que puede reducir los datos examinados para encontrar documentos coincidentes. Los índices de un solo campo y los índices compuestos sirven para diferentes patrones de acceso. La documentación de índices explica tanto los beneficios de las consultas como los costos de escritura.

Más índices requieren almacenamiento y trabajo para mantenerlos durante las escrituras. El rendimiento también depende del tamaño del documento, la proporción de lectura/escritura, la memoria, los discos y la red. Evalúe consultas representativas utilizando planes de ejecución y cargas realistas en lugar de asumir que NoSQL es inherentemente rápido.

Transacciones y garantías de lectura/escritura

Una actualización de un solo documento es atómica: no se aplica parcialmente esa actualización. Para cambios que deben tener éxito o fallar conjuntamente entre documentos, considere transacciones de múltiples documentos en conjuntos de réplicas o clústeres fragmentados. No asuma que la misma capacidad existe en un servidor independiente.

ACID significa Atomicidad, Consistencia, Aislamiento y Durabilidad. Revise las condiciones de implementación y configuración en la documentación de transacciones. Cuando la creación de pedidos y la reducción de inventario afectan documentos separados, defina los límites de la transacción, el manejo de solicitudes concurrentes y el comportamiento de reintento.

El parámetro read concern controla el estado de los datos que una lectura puede observar, mientras que el parámetro write concern controla el nivel de acuse de recibo para una escritura. Establezca las garantías necesarias antes de decirle a un usuario que un pago está completo y distinga las operaciones que pueden aceptar valores más antiguos de las réplicas.

¿Deberían los datos relacionados estar incrustados o referenciados?

Incrustar coloca los datos relacionados dentro de un documento. Referenciar enlaza con el identificador de otro documento. La guía de modelado recomienda almacenar juntos lo que se accede junto; la guía de incrustación versus referencias explica las compensaciones para relaciones y actualizaciones.

Copiar una dirección de entrega en un pedido puede preservar su significado histórico. Copiar los detalles de contacto actuales de un cliente en cada pedido crea copias para mantener cuando esos detalles cambien. Primero distinga hechos históricos de valores que siempre deben estar actualizados.

Un documento BSON regular tiene un tamaño máximo de 16 mebibytes (MiB). Añadir cada comentario o registro a un arreglo puede alcanzar ese límite y aumentar los costos de actualización. Use colecciones separadas, referencias o grupos limitados teniendo en cuenta el límite de tamaño de documento.

¿Qué casos de uso merecen consideración?

Estas son razones para evaluar un modelo de documento, en lugar de garantías basadas en etiquetas de la industria. Las lecturas y actualizaciones reales deben conducir a la elección.

También compare bases de datos relacionales cuando los informes flexibles entre tablas, las relaciones y restricciones compartidas, o las actualizaciones complejas de muchos a muchos sean requisitos centrales. Almacenar solo JSON no justifica reemplazar una base de datos existente. Verifique si un modelo de documentos mejora las consultas importantes y la carga operativa.

Un pequeño ejemplo de inserción y consulta

Los siguientes comandos usan MongoDB Shell, mongosh. Conéctese primero a una implementación de práctica separada, utilizando una cuenta con permisos de lectura, escritura y creación de índices para la base de datos objetivo y un shell instalado. Consulte la documentación de MongoDB Shell para obtener instrucciones de conexión.

El ejemplo inserta un producto en product_catalog en la base de datos mongodb_intro_demo. Comience con una colección vacía con este nombre en un entorno de práctica y verifique que su conexión apunte a ese entorno antes de ejecutar los comandos.

db = db.getSiblingDB("mongodb_intro_demo");

db.product_catalog.insertMany([
{
  "_id": "book-101",
  "name": "Database Basics",
  "category": "books",
  "price_krw": 24000,
  "attributes": {
    "author": "Mina Kim",
    "pages": 320
  },
  "tags": [
    "database",
    "beginner"
  ]
}
]);

insertMany() inserta documentos. Repetir el mismo _id en una colección estándar produce un error de clave duplicada. Para práctica repetida, utilice una base de datos de práctica nueva o identifique y gestione explícitamente solo el documento de muestra que añadió. No elimine una colección existente para resolver ese error.

Esta consulta encuentra productos en books con precios inferiores a 30 000 wones coreanos, devuelve sus identificadores, nombres y precios, y los ordena por precio ascendente. Con solo los datos de muestra presentes, book-101 cumple con las condiciones.

db.product_catalog.find(
  { category: "books", price_krw: { $lt: 30000 } },
  { _id: 1, name: 1, price_krw: 1 }
).sort({ price_krw: 1 });

$lt significa “menor que.” El segundo objeto especifica los campos devueltos, una proyección, y 1 en sort() significa orden ascendente. La referencia find() explica filtros y proyecciones.

Para filtros de precio frecuentes específicos por categoría y ordenación, considere este índice compuesto. Examine la distribución real y otras consultas antes de aplicar createIndex() en producción.

db.product_catalog.createIndex(
  { category: 1, price_krw: 1 }
);

El siguiente comando ejecuta la consulta y reporta estadísticas de ejecución sin cambiar documentos. En los resultados de explain("executionStats"), inspeccione el plan elegido, las claves y documentos examinados, y los documentos devueltos. Una colección pequeña puede usar un escaneo de colección; crear un índice por sí solo no demuestra una mejora de velocidad.

db.product_catalog.find(
  { category: "books", price_krw: { $lt: 30000 } }
).sort({ price_krw: 1 }).explain("executionStats");

La replicación y el sharding tienen trabajos diferentes

Un conjunto de réplicas es un grupo de servidores que mantienen los mismos datos. Normalmente, un primario acepta escrituras y los secundarios replican los cambios; los miembros elegibles pueden elegir un nuevo primario después de una falla. La guía de replicación explica las elecciones y la replicación asíncrona.

El cambio por falla puede causar retrasos temporales en las escrituras o errores, y las lecturas de los secundarios pueden reflejar un retraso en la replicación. La replicación no garantiza incondicionalmente un servicio ininterrumpido ni previene toda pérdida de datos. Diseñe reintentos, manejo de solicitudes duplicadas y garantías de lectura/escritura requeridas junto con la aplicación.

El sharding distribuye los datos a través de servidores para un escalamiento horizontal. Una clave de shard contiene los campos utilizados para la distribución y la ruta de las consultas. Las claves concentradas o las consultas que deben visitar cada shard pueden limitar el beneficio. La guía de sharding explica la selección de claves y la complejidad operativa.

La replicación y el sharding pueden usarse juntos, pero cumplen diferentes propósitos. Verifique el modelo, los índices y los cuellos de botella actuales antes de introducir el sharding simplemente porque los datos puedan crecer. Debe haber una razón para aceptar su complejidad y costo extra.

¿Qué debería verificar antes de adoptar MongoDB?

1. Definir operaciones importantes. Especificar filtros, ordenamiento y unidades de actualización para detalles de productos, búsquedas de precios por categoría y creación de pedidos; comparar implementaciones relacionales y de documentos reales.
2. Revisar el modelo y su corrección. Decidir sobre incrustaciones o referencias, tamaño de documentos, validación, índices, transacciones y requisitos de lectura inmediata.
3. Comparar carga representativa. Medir latencia, rendimiento y errores con datos realistas y distribución de solicitudes. Registrar versiones, hardware y configuraciones, y examinar escenarios de fallos y recuperación.
4. Elegir un modelo operativo. Decidir entre autogestión y un servicio gestionado, asignando responsabilidad para respaldo, restauración, monitoreo, actualizaciones y soporte.
5. Prepare la migración y una ruta de regreso. Defina conversiones de identificador/tipo, verificaciones de datos faltantes, escrituras durante el corte y condiciones para regresar al almacén existente.

MongoDB Atlas es un servicio administrado en la nube con una división diferente de responsabilidad operativa respecto a una implementación autogestionada. Utilice la documentación de Atlas para verificar las características necesarias y las opciones de implementación. Incluya almacenamiento, copias de seguridad, redes y trabajo operativo junto con los costos de instancia.

En producción, revise las cuentas de privilegio mínimo, las conexiones cifradas, las restricciones de red y la gestión de credenciales mediante las recomendaciones de seguridad de MongoDB apropiadas para su despliegue. Una eliminación accidental puede propagarse a las réplicas, por lo que la replicación no sustituye a las copias de seguridad. Siga la guía de métodos de copia de seguridad y compruebe que la restauración funcione.