Límites y umbrales de MongoDB

Limitaciones de MongoDB Atlas

Las siguientes limitaciones se aplican únicamente a las implementaciones alojadas en MongoDB Atlas. Si alguna de estas limitaciones representa un problema para su organización, póngase en contacto con Soporte Atlas.

Límites de tamaño de colección y base de datos

MongoDB no impone un límite estricto en los tamaños de las colecciones o bases de datos. El tamaño máximo de una colección o base de datos depende del sistema de archivos del servidor host. Por ejemplo:

• ext4: Tamaño máximo de archivo de 16 tebibytes (TiB).

• XFS: Tamaño máximo de archivo de 8 exbibytes (EiB).

Para escalar más allá de los límites del sistema de archivos o del hardware, MongoDB ofrece estrategias como la fragmentación, que permite que las colecciones crezcan indefinidamente. Para las colecciones que se acercan a estos límites o los cuellos de botella en el rendimiento, MongoDB recomienda la fragmentación o la migración a una configuración en clúster como MongoDB Atlas, que admite el escalado automático.

Documentos BSON

Tamaño del documento BSON

El tamaño máximo de un documento BSON es de 16 mebibytes.

El tamaño máximo de un documento ayuda a garantizar que un único documento no pueda utilizar una cantidad excesiva de RAM o, durante la transmisión, una cantidad excesiva de ancho de banda. Para almacenar documentos más grandes que el tamaño máximo, MongoDB proporciona la API de GridFS. Para obtener más información sobre GridFS, se debe consultar mongofiles y la documentación para el driver.

Profundidad de anidación para documentos BSON

MongoDB admite un máximo de 100 niveles de anidamiento para documentos BSON. Cada objeto o arreglo agrega un nivel.

Restricciones de denominación

Uso de mayusculas en nombres de bases de datos

No confíe en las mayúsculas para distinguir entre bases de datos. Por ejemplo, no puede utilizar dos bases de datos con nombres como salesData y SalesData.

Después de crear una base de datos en MongoDB, debes usar mayúsculas coherentes al referirse a ella. Por ejemplo, si creas la base de datos salesData, no la menciones utilizando mayúsculas alternativas, como salesdata o SalesData.

Restricciones en los nombres de bases de datos para Windows

Para las implementaciones de MongoDB que se ejecutan en Windows, los nombres de las bases de datos no pueden contener ninguno de los siguientes caracteres:

/\. "$*<>:|?

Además, los nombres de las bases de datos no pueden contener el carácter nulo.

Restricciones sobre los nombres de bases de datos para sistemas Unix y Linux

Para las implementaciones de MongoDB que se ejecutan en sistemas Unix y Linux, los nombres de las bases de datos no pueden contener ninguno de los siguientes caracteres:

/\. "$

Además, los nombres de las bases de datos no pueden contener el carácter nulo.

Longitud de los nombres de bases de datos

Los nombres de las bases de datos no pueden estar vacíos y deben tener menos de 64 bytes.

Restricción en los nombres de colección

Los nombres de las colecciones deben comenzar con un guion bajo o un carácter de letra, y no pueden:

• contenga el $.

• ser una string vacía (por ejemplo, "").

• contiene el carácter null.

• comience con el prefijo system.. (Reservado para uso interno.)

• contiene .system..

Si el nombre de la colección incluye caracteres especiales, como el carácter de subrayado, o comienza con números, para acceder a la colección, se debe usar el método db.getCollection() en mongosh o un método similar para el driver.

Longitud del namespace:

El límite de longitud del espacio de nombres para colecciones y vistas no fragmentadas es de 255 bytes, y de 235 bytes para colecciones fragmentadas. Para una colección o vista, el espacio de nombres incluye el nombre de la base de datos, el punto (.) y el nombre de la colección/vista (p. ej., <database>.<collection>).

Restricciones en los nombres de campos

• Los nombres de campo no pueden contener el caracter null.

• El servidor permite el almacenamiento de nombres de campo que contienen puntos (.) y signos de dólar ($).

• MongodB 5.0 ofrece un mejor soporte para el uso de ($) y (.) en los nombres de campo. Existen algunas restricciones. Consulta Consideraciones sobre los nombres de campo para obtener más detalles.

Restricciones en el campo _id

El nombre del campo _id está reservado para su uso como llave primaria; su valor debe ser único en la colección, es inmutable y puede ser de cualquier tipo que no sea un arreglo o una expresión regular. Si el _id contiene subcampos, los nombres de los subcampos no pueden comenzar con el símbolo ($).

Advertencias de nombres

Namespaces

Longitud del namespace

El límite de longitud del espacio de nombres para colecciones y vistas no fragmentadas es de 255 bytes, y de 235 bytes para colecciones fragmentadas. Para una colección o vista, el espacio de nombres incluye el nombre de la base de datos, el punto (.) y el nombre de la colección/vista (p. ej., <database>.<collection>).

Tip

Restricciones de denominación

Indexes

Número de índices por colección

Una sola colección puede tener como máximo 64 índices.

Número de campos indexados en un índice compuesto

No puede haber más de 32 campos en un índice compuesto.

Las consultas no pueden utilizar índices geoespaciales y de texto

No se puede combinar la query $text, la cual requiere un índice de texto especial, con un operador de la query que requiere un tipo diferente de índice especial. Por ejemplo, no se puede combinar la query $text con el operador $near.

Los campos con índices de 2dsphere solo pueden contener geometrías

Los campos con índices 2dsphere deben contener datos geométricos en forma de pares de coordenadas o datos GeoJSON. Si intentas insertar un documento con datos no geométricos en un campo indexado 2dsphere, o compilar un índice 2dsphere en una colección donde el campo indexado tenga datos no geométricos, la operación fallará.

Tip

El límite de índices únicos en Restricciones operativas de fragmentación.

Número limitado de claves de índice 2dsphere

Para generar claves para un índice 2dsphere, mongod asigna formas GeoJSON a una representación interna. La representación interna resultante puede ser un gran arreglo de valores.

Cuando mongod genera claves de índice en un campo que contiene un arreglo, mongod genera una clave de índice para cada elemento del arreglo. Para los índices compuestos, mongod calcula el producto cartesiano de los conjuntos de claves que se generan para cada campo. Si ambos conjuntos son grandes, entonces calcular el producto cartesiano podría hacer que la operación exceda los límites de memoria.

indexMaxNumGeneratedKeysPerDocument limita el número máximo de claves generadas para un solo documento para prevenir errores de memoria insuficiente. El valor por defecto es de 100 000 claves de índice por documento. Es posible aumentar el límite, pero si una operación requiere más claves de las que el parámetro indexMaxNumGeneratedKeysPerDocument especifica, la operación fallará.

Los valores NaN devueltos por query cubiertos por el motor de almacenamiento WiredTiger siempre son de tipo double

Si el valor de un campo devuelto de una query que está cubierta por un índice es NaN, el tipo de ese valor NaN es siempre double.

Multikey Index

Los índices de múltiples claves no pueden cubrir queries sobre campos de arreglos.

Índice geoespacial

Los índices geoespaciales no pueden cubrir una query.

Uso de memoria en la creación de índices

createIndexes brinda soporte a la creación de uno o más índices en una colección. createIndexes utiliza una combinación de memoria y archivos temporales en disco para crear índices. El límite de memoria por defecto es de 200 megabytes por comando createIndexes, compartido equitativamente entre toda la creación de índices en ese comando. Por ejemplo, si se crean 10 índices con un comando createIndexes, MongoDB asigna a cada índice 20 megabytes para el proceso de creación de índices cuando se utiliza el límite de memoria por defecto de 200. Cuando se alcanza el límite de memoria, MongoDB crea archivos temporales en el subdirectorio _tmp dentro de --dbpath para completar la compilación.

Ajuste el límite de memoria con el parámetromaxIndexBuildMemoryUsageMegabytes. Aumentar este parámetro solo es necesario en casos excepcionales, como al ejecutar varias compilaciones de índices simultáneas con un solo comandocreateIndexeso al indexar un conjunto de datos de más de 500GB.

Cada createIndexes comando tiene un límite de maxIndexBuildMemoryUsageMegabytes. Al utilizar el valor maxNumActiveUserIndexBuilds por defecto de 3, el uso total de memoria para todas las creaciones de índices simultáneas puede alcanzar hasta 3 veces el valor de maxIndexBuildMemoryUsageMegabytes.

El límite maxIndexBuildMemoryUsageMegabytes se aplica a todas las creaciones de índices iniciadas por comandos de usuario como createIndexes o procesos administrativos como la sincronización inicial.

Una sincronización inicial llena solo una colección a la vez y no corre ningún riesgo de exceder el límite de memoria. Sin embargo, es posible que un usuario inicie la creación de índices en múltiples colecciones en varias bases de datos simultáneamente.

Tipos de intercalación y de índices

Los siguientes tipos de índice solo tienen soporte para la comparación binaria simple y no tienen soporte para la intercalación:

• Text indexes

• 2d indexes

Tip

Para crear un índice text o 2d en una colección que tenga una intercalación no simple, debe especificar explícitamente {collation: {locale: "simple"} } al crear el índice.

Hidden Indexes

• No puedes ocultar el índice _id.

• No puedes usar hint() en un índice oculto.

Ordena

Máximo número de claves de clasificación

• Puedes ordenar sobre un máximo de 32 claves.

• Proveer un patrón de ordenación con campos duplicados causa un error.

Datos

Máxima número de documentos en una colección con tamaño fijo

Si especifica el número máximo de documentos en una colección con tamaño fijo usando el parámetro max de create, el valor debe ser inferior a 2 ³¹ documentos.

Si no especifica un número máximo de documentos al crear una colección con tamaño fijo, no hay límite en la cantidad de documentos.

Sets de réplicas

Cantidad de nodos de un set de réplicas

Los sets de réplicas pueden tener hasta 50 nodos.

Número de nodos con derecho a voto de un set de réplicas

Los sets de réplicas pueden tener hasta siete miembros con derecho a voto. Para sets de réplicas con más de siete miembros en total, consulta Miembros sin derecho a voto.

Tamaño máximo del Oplog creado automáticamente

Si no especifica explícitamente un tamaño de oplog (es decir, con oplogSizeMB o --oplogSize), MongoDB creará un oplog que no supere los 50 gigabytes. [4]

[4]	El oplog puede crecer más allá de su límite de tamaño configurado para evitar borrar el majority commit point.

Clústeres fragmentados

Los clústeres fragmentados tienen las restricciones y los umbrales que se describen aquí.

Operaciones

Operaciones de clasificación

Si MongoDB no puede utilizar un índice o índices para obtener el orden de clasificación, MongoDB debe realizar una operación de clasificación en memoria sobre los datos.

Para obtener más información sobre la ordenación y el uso de índices, consulta Uso de la ordenación y el índice.

Etapas de la pipeline de agregación

MongoDB limita el número de etapas de la canalización de agregación permitidas en un solo pipeline a 1000.

Si un pipeline de agregación supera el límite de etapa antes o después de ser analizada, se recibe un error.

Memoria de pipeline de agregación

A partir de MongoDB 6.0, el parámetro allowDiskUseByDefault controla si las etapas del pipeline que requieren más de 100 megabytes de memoria para ejecutarse guardan archivos temporales en disco por defecto.

• Si allowDiskUseByDefault se establece en true, las etapas del pipeline que requieren más de 100 megabytes de memoria para ejecutarse guardan archivos temporales en el disco por defecto. Puedes desactivar la escritura de archivos temporales en el disco para comandos específicos find o aggregate utilizando la opción { allowDiskUse: false }.

• Si allowDiskUseByDefault se establece en false, las etapas de la pipeline que requieren más de 100 megabytes de memoria para ejecutarse generan un error por defecto. Puedes habilitar la escritura de archivos temporales en disco para find o aggregate específicos usando la opción { allowDiskUse: true }.

La $search etapa de agregación no está restringida a 100 megabytes de RAM porque se ejecuta en un proceso separado.

Estos son algunos ejemplos de las etapas que pueden guardar archivos temporales en el disco cuando allowDiskUse está en true:

• $bucket

• $bucketAuto

• $group

• $setWindowFields

• $sort cuando la operación de ordenación no está soportada por un índice

• $sortByCount

Nota

Las etapas del pipeline operan en flujos de documentos, donde cada etapa del pipeline toma documentos, realizando su procesamiento y luego produciendo los documentos resultantes.

Algunas etapas no pueden generar ningún documento hasta que hayan procesado todos los documentos entrantes. Estas etapas del pipeline deben mantener su salida en la RAM hasta que se procesen todos los documentos entrantes. Como resultado, estas etapas de la pipeline pueden requerir más espacio que el límite de 100 MB.

Si los resultados de una de las etapas del pipeline $sort exceden el límite, se debe considerar agregar una etapa $limit.

Los mensajes de registro del perfilador y los mensajes de registro de diagnóstico incluyen un indicador usedDisk si alguna etapa de agregación escribió datos en archivos temporales debido a restricciones de memoria.

Agregación y nivel de consistencia de lectura

• La etapa $out no se puede usar junto con el nivel de consistencia de lectura "linearizable". Si especificas "linearizable" nivel de consistencia de lectura para db.collection.aggregate(), no podrás incluir la etapa $out en la pipeline.

• La etapa $merge no se puede usar junto con el nivel de consistencia de lectura "linearizable". Es decir, si especificas el "linearizable" nivel de consistencia de lectura para db.collection.aggregate(), no puedes incluir la etapa $merge en la pipeline.

Las query geoespaciales 2d no pueden utilizar el operador $or

Tip

Consulte:

• $or

• Componentes internos del índice 2d

Query geoespacial

Utilizar un índice 2d para queries sobre datos esféricos puede devolver resultados incorrectos o un error. Por ejemplo, los índices 2d no admiten "queries" esféricas que envuelven los polos.

Coordenadas geoespaciales

• Los valores de longitud válidos están entre -180 y 180, ambos inclusive.

• Los valores de latitud válidos están entre -90 y 90, ambos inclusive.

Área de polígonos de GeoJSON

Para $geoIntersects o $geoWithin, si especificas un polígono de un solo anillo que tiene un área mayor que un solo hemisferio, incluye el sistema de referencia de coordenadas personalizado de MongoDB en la expresión $geometry. De lo contrario, las query $geoIntersects o $geoWithin para la geometría complementaria. Para todos los demás polígonos GeoJSON con áreas mayores que un hemisferio, las query $geoIntersects o $geoWithin para la geometría complementaria.

Transacciones multidocumento

Para transacciones multidocumento:

• Puede crear colecciones e índices en transacciones. Para más información, consulte Crear colecciones e índices en una transacción.

• Las colecciones utilizadas en una transacción pueden encontrarse en diferentes bases de datos.

  Nota

  No puedes crear nuevas colecciones en transacciones de escritura entre particiones. Por ejemplo, si guardas en una colección existente en una partición y creas implícitamente una colección en una partición diferente, MongoDB no puede realizar ambas operaciones en la misma transacción.

• No se puede escribir en colecciones con tamaño fijo.

• No puedes usar el nivel de consistencia de lectura "snapshot" al leer de una colección con tamaño fijo. (A partir de MongoDB 5.0)

• No puedes leer ni escribir en colecciones en las bases de datos config, admin o local.

• No se puede escribir en las colecciones de system.*.

• No puedes devolver el plan de query de las operaciones admitidas usando explain o comandos similares.

• Para los cursores creados fuera de una transacción, no puedes llamar a getMore dentro de la transacción.

• Para los cursores creados en una transacción, no puedes llamar a getMore fuera de la transacción.

• No puede especificar el comando killCursors como la primera operación en una transacción.

  Además, si ejecutas el comando killCursors dentro de una transacción, el servidor detiene inmediatamente los cursores especificados. No espera la confirmación de la transacción.

Las siguientes operaciones no están permitidas en las transacciones:

• Creación de nuevas colecciones en transacciones de escritura entre particiones. Por ejemplo, si usted guarda en una colección existente en una partición y crea implícitamente una colección en una partición diferente, MongoDB no puede realizar ambas operaciones en la misma transacción.

• Creación explícita de colecciones, como por ejemplo: Método db.createCollection() e índices, por ejemplo: los métodos db.collection.createIndexes() y db.collection.createIndex(), cuando se utiliza un nivel de consistencia de lectura distinto de "local".

• Los comandos listCollections y listIndexes y sus métodos asistentes.

• Otras operaciones que no son CRUD ni informativas, tales como createUser, getParameter, count, etc. y sus asistentes.

Las transacciones tienen un límite de tiempo de vida según lo especificado por transactionLifetimeLimitSeconds. El valor por defecto es 60 segundos.

Límite de tamaño de la agrupación del comando de escritura

Aunque MongoDB no tiene un límite en la cantidad de operaciones agrupadas que puede realizar, permite un máximo de 100,000 acciones de escritura en una sola operación agrupada. Un solo agrupamiento representa una única solicitud al servidor. Si la cantidad de acciones de escritura en una operación agrupada excede 100.000, el controlador del cliente divide el agrupamiento en grupos más pequeños con conteos menores o iguales a 100.000.

Vistas

Una definición de vista pipeline no puede incluir la etapa $out o la $merge. Esta restricción también se aplica a pipelines integradas, como las pipelines usadas en las etapas de $lookup o $facet.

Las vistas tienen las siguientes restricciones de operación:

• Las vistas son de solo lectura.

• No puede cambiar el nombre de vistas.

• find() Las operaciones en vistas no son compatibles con los siguientes operadores de proyección del comando find:

  • $

  • $elemMatch

  • $slice

  • $meta

• Las vistas no son compatibles con $text.

• Las vistas no dan soporte a operaciones de map-reduce.

Restricciones de proyecciones

$-Restricción de la ruta de campo con prefijo

La proyección de find() y de findAndModify() no pueden proyectar un campo que comience con $, con la excepción de los campos DBRef.Por ejemplo, la siguiente operación es inválida:

db.inventory.find( {}, { "$instock.warehouse": 0, "$item": 0, "detail.$price": 1 } )

$ Restricción de colocación de operadores posicionales

El operador de proyección $ solo puede aparecer al final de la ruta de campo, por ejemplo "field.$" o "fieldA.fieldB.$". Por ejemplo, la siguiente operación no es válida:

db.inventory.find( { }, { "instock.$.qty": 1 } )

Para resolver, elimine el componente de la ruta de campo que sigue al operador de proyección $.

Restricción de proyección de nombre de campo vacío

La proyección find() y la proyección findAndModify() no pueden incluir una proyección de un nombre de campo vacío. Por ejemplo, la siguiente operación es inválida:

db.inventory.find( { }, { "": 0 } )

En versiones anteriores, MongoDB trata la inclusión/exclusión del campo vacío de la misma manera que la proyección de campos inexistentes.

Colisión de ruta: Documentos incrustados y sus campos

No puedes proyectar un documento incrustado con ninguno de los campos del documento incrustado. Por ejemplo, considera una colección inventory con documentos que contienen un campo size:

{ ..., size: { h: 10, w: 15.25, uom: "cm" }, ... }

La siguiente operación falla con un error de Path collision porque intenta proyectar tanto el documento size como el campo size.uom:

db.inventory.find( {}, { size: 1, "size.uom": 1 } )

En versiones anteriores, la última proyección entre los documentos incrustados y sus campos determinaba la proyección:

• Si la proyección del documento incrustado viene después de todas y cada una de las proyecciones de sus campos, MongoDB proyecta el documento incrustado. Por ejemplo, el documento de proyección { "size.uom": 1, size: 1 } produce el mismo resultado que el documento de proyección { size: 1 }.

• Si la proyección del documento incrustado se realiza antes que la de cualquiera de sus campos, MongoDB proyecta el campo o los campos especificados. Por ejemplo, el documento de proyección { "size.uom": 1, size: 1, "size.h": 1 } produce el mismo resultado que el documento de proyección { "size.uom": 1, "size.h": 1 }.

Colisión de ruta: $slice de un arreglo y campos embebidos

find() y la proyección findAndModify() no pueden contener a la vez un $slice de un arreglo y un campo incrustado en el arreglo. Por ejemplo, considere una colección inventory que contiene un campo de arreglo instock:

{ ..., instock: [ { warehouse: "A", qty: 35 }, { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ], ... }

La siguiente operación falla con un error Path collision:

db.inventory.find( {}, { "instock": { $slice: 1 }, "instock.warehouse": 0 } )

En versiones anteriores, la proyección aplicaba ambas proyecciones y devolvía el primer elemento ($slice: 1) del arreglo instock, pero suprimía el campo warehouse en el elemento proyectado. A partir de MongoDB 4.4, para lograr el mismo resultado, utiliza el método db.collection.aggregate() con dos etapas $project separadas.

$ Operador posicional y restricción de $slice

Las proyecciones find() y findAndModify() no pueden incluir la expresión de proyección $slice como parte de una expresión de proyección $. Por ejemplo, la siguiente operación no es válida:

db.inventory.find( { "instock.qty": { $gt: 25 } }, { "instock.$": { $slice: 1 } } )

En versiones anteriores, MongoDB devuelve el primer elemento (instock.$) del arreglo instock que coincide con la condición de query; es decir, la proyección posicional "instock.$" tiene prioridad y la $slice:1 no realiza ninguna operación. El "instock.$": { $slice: 1 } no excluye ningún otro campo del documento.

Sesiones

Límite de sesiones y nombre de usuario $external

Para usar sesiones de cliente y garantías de coherencia causal con usuarios de autenticación $external (usuarios Kerberos, LDAP o X.509), los nombres de usuario no pueden superar los 10k bytes.

Tiempo de espera de inactividad de la sesión

Las sesiones que no reciben operaciones de lectura o escritura durante 30 minutos o que no se actualizan usando refreshSessions dentro de este umbral, son marcadas como expiradas y el servidor MongoDB puede cerrarlas en cualquier momento. Cerrar una sesión termina cualquier operación en curso y los cursores abiertos asociados con la sesión. Esto incluye cursores configurados con noCursorTimeout() o un maxTimeMS() mayor de 30 minutos.

Considera una aplicación que emite un db.collection.find(). El servidor devuelve un cursor junto con un lote de documentos definidos por la cursor.batchSize() del find(). La sesión se actualiza cada vez que la aplicación realiza una solicitud de un nuevo agrupamiento de documentos del servidor. Sin embargo, si la aplicación tarda más de 30 minutos en procesar el lote actual de documentos, la sesión se marca como expirada y se cierra. Cuando la aplicación solicita el siguiente lote de documentos, el servidor arroja un error porque el cursor se eliminó al cerrar la sesión.

Para las operaciones que devuelven un cursor, si el cursor puede estar inactivo durante más de 30 minutos, emite la operación dentro de una sesión explícita utilizando Mongo.startSession() y actualiza periódicamente la sesión utilizando el comando refreshSessions. Por ejemplo:

var session = db.getMongo().startSession()
var sessionId = session
sessionId  // show the sessionId
var cursor = session.getDatabase("examples").getCollection("data").find().noCursorTimeout()
var refreshTimestamp = new Date() // take note of time at operation start
while (cursor.hasNext()) {
  // Check if more than 5 minutes have passed since the last refresh
  if ( (new Date()-refreshTimestamp)/1000 > 300 ) {
    print("refreshing session")
    db.adminCommand({"refreshSessions" : [sessionId]})
    refreshTimestamp = new Date()
  }
  // process cursor normally
}

En la operación de ejemplo, el método db.collection.find() está asociado con una sesión explícita. El cursor está configurado con noCursorTimeout() para evitar que el servidor cierre el cursor si está inactivo. El bucle while incluye un bloque que utiliza refreshSessions para refrescar la sesión cada 5 minutos. Dado que la sesión nunca superará el tiempo de espera de inactividad de 30 minutos, el cursor puede permanecer abierto indefinidamente.

Para los controladores de MongoDB, consulta la documentación del controlador para obtener instrucciones y la sintaxis para crear sesiones.