Límites y umbrales de MongoDB

Tamaño de la colección y de la base de datos

MongoDB no impone un límite estricto al tamaño de las colecciones o bases de datos. El tamaño máximo depende del sistema de archivos del host:

• 4ext: 16 tebibytes (TiB) tamaño máximo de archivo

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

Para escalar más allá de los límites del sistema de archivos o del hardware, utilice Fragmentación para implementaciones que no son de Atlas. Para colecciones locales que se acercan a estos límites o experimentan cuellos de botella de rendimiento, MongoDB recomienda fragmentar o migrar a MongoDB Atlas, que admite escalado automático.

Al fragmentar una colección, MongoDB determina los rangos de fragmentos iniciales según la clave de fragmento:

• predeterminado chunkSize: 128 MB

• Tamaño promedio típico de clave de fragmento: 16 bytes

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 del documento ayuda a garantizar que un solo documento no utilice una cantidad excesiva de RAM ni de ancho de banda durante la transmisión. Para almacenar documentos que superen el tamaño máximo, MongoDB proporciona la API GridFS. Para obtener más información sobre GridFS, consulte mongofiles y la documentación de su conductor.

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 utilice mayúsculas y minúsculas para distinguir entre bases de datos. Después de crear una base de datos, utilice mayúsculas y minúsculas de forma coherente al referirse a ella.

Por ejemplo, no se pueden usar dos bases de datos con nombres como salesData y SalesData. Si se crea la base de datos salesData, no se debe usar mayúsculas y minúsculas alternativas para referirse a ella, como salesdata o SalesData.

Restricciones en los nombres de bases de datos para Windows

En Windows, los nombres de bases de datos no pueden contener ninguno de los siguientes caracteres:

/\. "$*<>:|?

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

En los sistemas Unix y Linux, los nombres de las bases de datos no pueden contener ninguno de los siguientes caracteres:

/\. "$

Carácter nulo en los nombres de bases de datos

Los nombres de bases de datos no pueden contener el carácter nulo en ninguna plataforma.

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:

• contener el $

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

• contener el carácter nulo

• comienzan 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.

• Cada nombre de campo debe ser único dentro del documento. No debes almacenar documentos con campos duplicados porque las operaciones CRUD de MongoDB podrían comportarse de manera inesperada si un documento tiene campos duplicados.

Restricciones en el campo _id

El nombre de campo _id está reservado para usarse como clave principal; su valor es inmutable, debe ser único en la colección y puede ser de cualquier tipo, excepto una matriz o una expresión regular. Si _id contiene subcampos, sus nombres no pueden comenzar con el símbolo ($).

Advertencias de nombres

MongoDB no admite nombres de campo duplicados

El lenguaje de consulta MongoDB tiene las siguientes restricciones al crear o actualizar nombres de campos:

• MongoDB no permite insertar documentos con nombres de campo duplicados. Si bien algunos compiladores BSON permiten la creación de dichos documentos, MongoDB no los admite, incluso si la inserción se realiza correctamente o parece hacerlo.

• No se admite la actualización de documentos con nombres de campos duplicados, incluso si la actualización tiene éxito o parece tener éxito.

Por ejemplo, insertar un documento BSON con nombres de campos duplicados a través de un controlador de MongoDB puede resultar en que el controlador descarte silenciosamente los valores duplicados antes de la inserción, o puede resultar en que se inserte un documento inválido que contenga campos duplicados. Realizar un query en esos documentos lleva a resultados inconsistentes.

A partir de MongoDB 6.1, para ver si un documento tiene nombres de campo duplicados, utiliza el comando validate con el campo full establecido en true. En cualquier versión de MongoDB, utiliza el operador de agregación $objectToArray para ver si un documento tiene nombres de campo duplicados.

Evite nombres de campos ambiguos

No utilice un nombre de campo que sea igual a la notación de puntos para un campo incrustado. Si tiene un documento con un campo incrustado { "a" : { "b": ... } }, los demás documentos de esa colección no deben tener un campo de nivel superior "a.b".

Si puede referenciar un campo incrustado y un campo de nivel superior de la misma manera, las operaciones de indexación y fragmentación ocurren en el campo incrustado. No se puede indexar ni fragmentar en el campo de nivel superior "a.b" mientras la colección tiene un campo incrustado al que se hace referencia de la misma manera.

Por ejemplo, si su colección contiene documentos con un campo incrustado { "a" : { "b": ... } } y un campo de nivel superior "a.b", las operaciones de indexación y fragmentación ocurren en el campo incrustado. No es posible indexar o fragmentar en el campo de nivel superior "a.b" cuando su colección también contiene un campo incrustado { "a" : { "b": ... } }.

Preocupaciones sobre importación y exportación con signos de dólar (``$``) y puntos (``.``)

A partir de MongoDB 5.0, los nombres de los campos del documento pueden tener prefijo de dólar ($) y pueden contener puntos (.). Sin embargo, mongoimport y mongoexport pueden no funcionar como se espera en algunas situaciones con nombres de campos que utilizan estos caracteres.

MongoDB Extended JSON v2 no puede diferenciar entre los contenedores de tipo y los campos que tienen el mismo nombre que los contenedores de tipo. No utilices formatos JSON extendidos en contextos donde las representaciones BSON correspondientes puedan incluir claves con prefijo de dólar ($). El mecanismo DBRef es una excepción a esta regla general.

También hay restricciones en el uso de mongoimport y mongoexport con puntos (.) en los nombres de campo. Dado que los archivos CSV utilizan el punto (.) para representar jerarquías de datos, un punto (.) en el nombre de un campo se interpretará incorrectamente como un nivel de anidamiento.

Posible pérdida de datos con signos de dólar (``$``) y puntos (``.``)

Existe una pequeña posibilidad de pérdida de datos cuando se utilizan nombres de campo con el prefijo dólar ($) o nombres de campo que contienen puntos (.) si estos nombres de campo se utilizan junto con escrituras no reconocidas (nivel de confirmación de escritura w=0) en servidores que sean anteriores a MongoDB 5.0.

Al ejecutar los comandos insert, update y findAndModify, los controladores compatibles con la versión 5.0 eliminan las restricciones sobre el uso de documentos con nombres de campo que tengan el prefijo dólar ($) o que contengan puntos (.). Estos nombres de campo generaban un error del lado del cliente en versiones anteriores del controlador.

Las restricciones se eliminan independientemente de la versión del servidor a la que esté conectado el controlador. Si un controlador 5.0 envía un documento a un servidor más antiguo, el documento será rechazado sin enviar un error.

Indexes

Número de índices por colección

Una sola colección no puede tener más de 64 índices.

Número de campos indexados en un índice compuesto

Un índice compuesto no puede tener más de 32 campos.

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.

Colecciones con tamaño fijo

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 registro de operaciones (es decir, con o), MongoDB creará un registro de operaciones que no sea mayor oplogSizeMB --oplogSizea 50 gigabytes. []1

[1]	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

Operaciones no disponibles en entornos fragmentados

$where no permite referencias al objeto db desde la función $where. Esto es poco común en colecciones no particionadas.

Queries cubiertos en clústeres fragmentados

Cuando se ejecutan en mongos, los índices solo pueden cubrir las query sobre colecciones fragmentadas si el índice contiene la clave de fragmentación.

Operaciones de modificación de un solo documento en colecciones fragmentadas

Para utilizar las operaciones update y remove() en una colección particionada que especifique la opción justOne o multi: false:

• Si solo apunta a un fragmento, puede usar una clave de fragmentación parcial en la especificación de query o,

• Puede proporcionar la clave de fragmentación o el campo _id en la especificación de la query.

Índices únicos en colecciones fragmentadas

MongoDB no admite índices únicos entre fragmentos, excepto cuando el índice único contiene la clave de fragmentación completa como prefijo del índice. En estas situaciones, MongoDB aplicará la unicidad en toda la clave, no en un solo campo.

Tip

Consulte:

Restricciones únicas en campos arbitrarios para un enfoque alternativo.

Cantidad máxima de documentos por rango para migrar

Por defecto, MongoDB no puede mover un rango si el número de documentos en el rango es mayor que 2 veces el resultado de dividir el tamaño del rango configurado por el tamaño promedio de los documentos. Si MongoDB puede mover un subrango de un fragmento y reducir su tamaño a menos de eso, el balanceador lo hace migrando un rango. db.collection.stats() incluye el campo avgObjSize, que representa el tamaño medio de los documentos en la colección.

Para fragmentos que son demasiado grandes para migrar:

• La configuración del balanceador attemptToBalanceJumboChunks permite que el balanceador migre fragmentos demasiado grandes para mover, siempre que los fragmentos no estén etiquetados como jumbo. Consulte los rangos de balance que exceden el límite de tamaño para obtener más detalles.

  Al emitir los comandos moveRange y moveChunk, es posible especificar la opción forceJumbo para permitir la migración de rangos que son demasiado grandes para moverse. Los rangos pueden o no estar etiquetados como jumbo.

Claves de partición

Tipo de índice de clave de fragmentación

Un índice de clave de fragmentación puede ser un índice ascendente en la clave de fragmentación, un índice compuesto que comienza con la clave de fragmentación y especifica el orden ascendente para la clave de fragmentación, o un índice encriptado.

Un índice de clave de fragmentación no puede ser:

• Un índice descendente en la clave de fragmentación

• Un índice parcial

• Cualquiera de los siguientes tipos de índices:

  • Geoespacial

  • Multikey

  • Text

  • Comodín

Selección de Shard Key

Las opciones para cambiar una clave de partición dependen de la versión de MongoDB que está ejecutando:

• A partir de MongoDB 5.0, puedes refragmentar una colección al cambiar la clave de fragmentación de un documento.

• Para ajustar una clave de fragmentación, agrega un campo o campos de sufijo a la clave de fragmentación existente.

Las claves de fragmentación que aumentan de manera monótona pueden limitar el rendimiento de inserción

Para los clústeres con volúmenes de inserción altos, una clave de fragmentación con claves que aumentan o disminuyen de manera monótona puede afectar el rendimiento de inserción. Si la clave de fragmentación es el campo _id, se debe tener en cuenta que los valores por defecto de los campos _id son ObjectIds que generalmente tienen valores crecientes.

Al insertar documentos con claves de fragmentación que aumentan de forma monótona, todas las inserciones pertenecen al mismo fragmento en una sola partición. El sistema eventualmente divide el rango de fragmentos que recibe todas las operaciones de guardado y migra su contenido para distribuir los datos de manera más uniforme. Sin embargo, en cualquier momento, el clúster dirige las operaciones de inserción únicamente a una partición, lo que crea un cuello de botella en el rendimiento de inserción.

Si las operaciones en el clúster son predominantemente de lectura y actualizaciones, esta limitación puede no afectar al clúster.

Para evitar esta restricción, usa una clave de fragmentación encriptada o selecciona un campo que no aumente ni disminuya de forma monótona.

Claves de partición con hash y índices encriptados almacenan hashes de claves con valores ascendentes.

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, los procesa y luego produce 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.

• Operaciones paralelas. Para actualizar varios espacios de nombres simultáneamente, considera usar el comando bulkWrite en cambio.

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

El controlador puede gestionar un número ilimitado de operaciones de escritura.Los controladores agrupan los datos en lotes según el valor maxWriteBatchSize, que 100 es,000 y no se puede modificar. Si el lote contiene más 100 de,000 operaciones, el controlador lo divide en grupos más pequeños con recuentos menores o iguales al valor maxWriteBatchSize. Por ejemplo, si la operación 250 contiene,000 operaciones, el controlador crea tres lotes: dos 100 con,000 operaciones y uno 50 con,000 operaciones.

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 ruta de campo con prefijo ``$``

Las find() proyecciones y no pueden proyectar un campo que comience con findAndModify() $ 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 del operador posicional ``$``

El $ operador de proyección solo puede aparecer al final de la ruta del campo, por ejemplo "field.$" "fieldA.fieldB.$"o.

Por ejemplo, la siguiente operación es invá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

find() Las findAndModify() proyecciones y 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 se puede proyectar un documento incrustado con ninguno de los campos del documento incrustado.

Por ejemplo, considere 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 rutas: ``$slice`` de una matriz y campos incrustados

find() Las findAndModify() proyecciones y no pueden contener un de una matriz y un campo incrustado en la $slice matriz.

Por ejemplo, considere una colección inventory que contiene un campo de matriz 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 ``$slice``

Las proyeccionesfind()yfindAndModify()no pueden incluir la expresión de proyección$slicecomo parte de una expresión de proyección$.

Por ejemplo, la siguiente operación es invá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 ni escritura durante 30 minutos o que no se actualizan con refreshSessions se marcan como expiradas y el servidor MongoDB puede cerrarlas. Al cerrar una sesión, se cancelan las operaciones en curso y los cursores abiertos, incluidos aquellos configurados con noCursorTimeout() o un superior maxTimeMS() a 30 minutos.

Operaciones de cursor de larga duración

Para las operaciones que devuelven un cursor que puede estar inactivo durante más de 30 minutos, ejecute la operación dentro de una sesión explícita usando Mongo.startSession() y actualice la sesión periódicamente usando. Por refreshSessions 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
}

Este ejemplo usa refreshSessions cada 5 minutos para evitar 30el tiempo de inactividad de minutos. El cursor permanece abierto indefinidamente.

Para los controladores MongoDB, consulte la documentación del controlador para crear sesiones.

Límites del clúster

Límites de conexión por nivel de clúster

MongoDB Atlas limita las conexiones entrantes simultáneas según el nivel y la clase del clúster.

• Se aplican límites de conexión por nodo

• Para los clústeres fragmentados, se aplican límites por enrutador mongos (la cantidad de enrutadores es igual a la cantidad de nodos del conjunto de réplicas en todos los fragmentos)

• Su preferencia de lectura también afecta el total de conexiones asignadas por consulta

Límites de conexión para niveles de clúster:

Limitación de la conexión multinube

Si se conecta a una implementación multinube de MongoDB Atlas mediante una conexión privada, solo podrá acceder a los nodos del mismo proveedor de nube desde el que se conecta. Es posible que este proveedor no tenga el nodo principal en su región. En este caso, especifique el modo de preferencia de lectura secundario en la cadena de conexión.

Para acceder a todos los nodos de su proveedor actual a través de una conexión privada, configure una VPN o un punto final privado para MongoDB Atlas para cada proveedor de nube restante.

Límites de colección e índices

No existe un límite estricto para la cantidad de colecciones en un clúster de MongoDB Atlas. Sin embargo, el rendimiento se degrada con muchas colecciones e índices. Las colecciones más grandes tienen un mayor impacto.

Número combinado máximo recomendado de colecciones e índices por nivel de clúster:

Organización y límites del proyecto

Las implementaciones de MongoDB Atlas tienen los siguientes límites de organización y proyecto:

Límites de la cuenta de servicio

Límites de etiquetas

MongoDB Atlas limita la longitud y aplica los requisitos de ReGex para las siguientes etiquetas de componentes:

Limitaciones de los clústeres gratuitos y flexibles

Se aplican limitaciones adicionales a los clústeres gratuitos de MongoDB Atlas y Flex. Para obtener más información, consulte:

• Limitaciones del clúster gratuito de Atlas

• Limitaciones de Atlas Flex

Limitaciones de los comandos

Algunos comandos de MongoDB no son compatibles con MongoDB Atlas. Además, algunos comandos solo son compatibles con clústeres gratuitos de MongoDB Atlas. Para obtener más información, consulta:

• Comandos no admitidos en Atlas

• Comandos disponibles solo en clústeres gratuitos