Limites e limiares do MongoDB

Tamanho da collection e do banco de dados

O MongoDB não impõe um limite rígido nos tamanhos das collections ou dos banco de dados . O tamanho máximo depende do sistema de arquivos do host:

• 4ext: 16 tamanho máximo do arquivo de tebibytes (TiB)

• XFS: 8 exbibytes (EiB) tamanho máximo do arquivo

Para escalar além dos limites do sistema de arquivos ou do hardware, use afragmentação para sistemas que não sejam do Atlas. Para collections no local que se aproximam desses limites ou estão com gargalos de desempenho, o MongoDB recomenda fragmentar ou migrar para o MongoDB Atlas, que oferece suporte ao auto-scaling.

Ao fragmentar uma collection, o MongoDB determina os intervalos iniciais de chunks com base na chave de shard:

• Default chunkSize: 128 MB

• Tamanho médio típico da chave de shard: 16 bytes

Documentos BSON

Tamanho do documento BSON

O tamanho máximo do documento BSON é de 16 mebibytes.

O tamanho máximo do documento ajuda a garantir que documento não possa usar uma quantidade excessiva de RAM ou uma quantidade excessiva de largura de banda durante a transmissão. Para armazenar documentos maiores que o tamanho máximo, o MongoDB fornece a API GridFS . Para obter mais informações sobre a GridFS,mongofiles consulte e a documentação do seu driver.

Profundidade aninhada para documentos BSON

O MongoDB permite no máximo 100 níveis de aninhamento para documentos BSON. Cada objeto ou array adiciona um nível.

Restrições de nomeação

Uso de letras maiúsculas e minúsculas em nomes de banco de dados

Não use maiúsculas e minúsculas para distinguir entre bancos de dados. Depois de criar um banco de dados, use a capitalização consistente quando se referir a ele.

Por exemplo, você não pode usar dois bancos de dados com nomes como salesData e SalesData. Se você criar o banco de dados salesData, não faça referência a ele usando letras maiúsculas alternativas, como salesdata ou SalesData.

Restrições em nomes de bancos de dados para Windows

No Windows, os nomes dos banco de dados não podem conter nenhum dos seguintes caracteres:

/\. "$*<>:|?

Restrições em nomes de bancos de dados para sistemas Unix e Linux

Nos sistemas Unix e Linux, os nomes dos banco de dados não podem conter nenhum dos seguintes caracteres:

/\. "$

Caractere nulo em nomes de banco de dados

Os nomes do banco de dados não podem conter o caractere nulo em qualquer plataforma.

Comprimento dos nomes dos bancos de dados

Os nomes do banco de dados não podem estar vazios e devem ser menores que 64 bytes.

Restrição de nomes de coleções

Os nomes das collections devem começar com um sublinhado ou um caractere de letra, e não podem:

• contém o $

• seja uma string vazia (por exemplo. "")

• contém o caractere nulo

• começar com o prefixo system. (reservado para uso interno)

• contém .system.

Se o nome da coleção incluir caracteres especiais, como o underscore, ou começar com números, para acessar a coleção use o método db.getCollection() em mongosh ou um método semelhante para o driver.

Comprimento do namespace

O limite de comprimento do namespace para coleções e visualizações não fragmentadas é de 255 bytes e 235 bytes para coleções fragmentadas. Para uma coleção ou visualização, o namespace inclui o nome do banco de dados, o separador de ponto (.) e o nome da coleção/visualização (por exemplo, <database>.<collection>).

Restrições em nomes de campo

• Os nomes de campo não podem conter o caractere null.

• O servidor permite armazenar nomes de campos que contêm pontos (.) e sinais de dólar ($).

• MongodB 5.0 adiciona suporte melhorado para o uso de ($) e (.) em nomes de campo. Existem algumas restrições. Consulte Considerações sobre o nome do campo para obter mais detalhes.

• Cada nome de campo deve ser exclusivo dentro do documento. Você não deve armazenar documentos com campos duplicados porque as operações CRUD do MongoDB podem se comportar de forma inesperada se um documento tiver campos duplicados.

Restrições em _id

O nome do campo _id é reservado para uso como chave primária; seu valor é imutável, deve ser único na coleção e pode ser de qualquer tipo, exceto uma array ou regex. Se o _id contiver subcampos, os nomes dos subcampos não poderão começar com um símbolo ($).

Avisos de nomenclatura

O MongoDB não suporta nomes de campo duplicados

A linguagem de query do MongoDB tem as seguintes restrições ao criar ou atualizar nomes de campo:

• O MongoDB não oferece suporte à inserção de documentos com nomes de campo duplicados. Embora alguns construtores de BSON possam oferecer suporte à criação de tais documentos, o MongoDB não oferece suporte a eles, mesmo que a inserção seja bem-sucedida ou pareça ter sucesso.

• A atualização de documentos com nomes de campo duplicados não é suportada, mesmo que a atualização seja bem-sucedida ou pareça ser bem-sucedida.

Por exemplo, inserir um documento BSON com nomes de campo duplicados por meio de um driver MongoDB pode resultar na liberação silenciosa dos valores duplicados antes da inserção, ou pode resultar na inserção de um documento inválido que contenha campos duplicados. A consulta desses documentos leva a resultados inconsistentes.

A partir do MongoDB,6.1 para ver se um documento tem nomes de campo duplicados, use o comando com validate o full campo definido true como. Em qualquer versão do MongoDB , use o $objectToArray operador de agregação para ver se um documento tem nomes de campo duplicados.

Evite nomes de campo ambíguos

Não utilize um nome de campo que coincida com a notação de ponto para um campo incorporado. Se você tiver um documento com um campo incorporado { "a" : { "b": ... } }, outros documentos nessa coleção não devem conter um campo de nível superior "a.b".

Se você puder fazer referência a um campo incorporado e a um campo de nível superior da mesma maneira, as operações de indexação e fragmentação ocorrerão no campo incorporado. Você não pode indexar ou fragmentar no campo de nível superior "a.b" enquanto a collection tiver um campo incorporado ao qual você faz referência da mesma maneira.

Por exemplo, se sua collection contiver documentos com um campo incorporado { "a" : { "b": ... } } e um campo de nível superior "a.b", as operações de indexação e fragmentação ocorrerão no campo incorporado . Não é possível indexar ou fragmentar no campo de nível superior "a.b" quando sua coleção também contém um campo incorporado { "a" : { "b": ... } }.

Preocupações de importação e exportação com assinaturas de dólar (''$'') e períodos (''.'')

A partir do MongoDB 5.0, os nomes dos campos do documento podem ter prefixo de cifrão ($) e podem conter pontos (.). No entanto, mongoimport e mongoexport podem não funcionar como esperado em algumas situações com nomes de campo que fazem uso destes caracteres.

O JSON estendido v2 MongoDB não consegue diferenciar entre os wrappers de tipo e os campos que têm o mesmo nome dos wrappers de tipo. Não use formatos JSON estendidos em contextos onde as representações BSON correspondentes possam incluir chaves prefixadas com cifrões ($). O mecanismo DBRef é uma exceção a esta regra geral.

Também há restrições quanto ao uso de mongoimport e mongoexport com pontos (.) em nomes de campos. Como os arquivos CSV usam o ponto (.) para representar hierarquias de dados, um ponto (.) em um nome de campo será interpretado incorretamente como um nível de aninhamento.

Possível perda de dados com cifrões (``$``) e períodos (``.``)

Há uma pequena chance de perda de dados ao usar nomes de campo com prefixo de cifrão ($) ou nomes de campo que contenham pontos (.) se esses nomes de campo forem usados em conjunto com gravações não reconhecidas de (write concern w=0) em servidores mais antigos que o MongoDB 5.0.

Ao executar os comandos insert, update e findAndModify, os drivers compatíveis com a versão 5.0 removem as restrições de uso de documentos com nomes de campo com prefixo de cifrão ($) ou que contenham pontos (.). Esses nomes de campo geraram um erro do lado do cliente nas versões anteriores do driver.

As restrições são removidas independentemente da versão do servidor à qual o driver está conectado. Se um driver do 5.0 enviar um documento para um servidor mais antigo, o documento será rejeitado sem enviar um erro.

Indexes

Número de índices por collection

Uma única collection não pode ter mais de 64 índices.

Número de campos indexados em um índice composto

Um índice composto não pode ter mais de 32 campos.

As queries não podem usar índices geoespaciais e de texto

Você não pode combinar a query $text, que exige um índice de texto especial, com um operador de query que exige um tipo diferente de índice especial. Por exemplo, você não pode combinar a query $text com o operador $near.

Campos com índices 2dsphere só podem conter geometrias

Campos com índices 2dsphere devem conter dados de geometria na forma de pares de coordenadas ou dados GeoJSON . Se você tentar inserir um documento com dados não geométricos em um campo indexado do 2dsphere ou construir um índice do 2dsphere em uma construir onde o campo indexado tem dados não geométricos, a operação falhará.

Dica

O limite exclusivo de índices nas restrições operacionais de fragmentação.

Número limitado de chaves de índice 2dsphere

Para gerar chaves para um índice 2dsphere, mongod mapeia formas GeoJSON para uma representação interna. A representação interna resultante pode ser uma grande array de valores.

Quando mongod gera chaves de índice em um campo que contém uma array, mongod gera uma chave de índice para cada elemento da array. Para índices compostos, o mongod calcula o produto cartesiano dos conjuntos de chaves que são geradas para cada campo. Se ambos os conjuntos forem grandes, o cálculo do produto cartesiano poderá fazer com que a operação exceda os limites de memória.

indexMaxNumGeneratedKeysPerDocument limita o número máximo de chaves geradas para um único documento para evitar erros de falta de memória. O padrão é 100000 chaves de índice por documento. É possível aumentar o limite, mas se uma operação exigir mais chaves do que o parâmetro indexMaxNumGeneratedKeysPerDocument especifica, a operação falhará.

Os valores NaN retornados de Queries Cobertas pelo mecanismo de armazenamento do WiredTiger são sempre de tipo double

Se o valor de um campo retornado de uma query coberta por um índice for NaN, o tipo desse valor NaN será sempre double.

Multikey Index

Os índices com várias chaves não podem cobrir queries em campos de array.

Índice Geoespacial

Os índices geoespaciais não podem cobrir uma query.

Uso de memória em compilações de índice

O createIndexes permite criar um ou mais índices em uma collection. createIndexes usa uma combinação de memória e arquivos temporários no disco para criar índices. O limite de memória padrão é de 200 megabytes por comando createIndexes, compartilhados igualmente entre todos os índices construídos nesse comando. Por exemplo, se você construir índices 10 com um comando createIndexes, o MongoDB alocará cada índice 20 megabytes para o processo de construção de índice ao utilizar o limite de memória padrão de 200. Quando você atinge o limite de memória, o MongoDB cria arquivos temporários no subdiretório _tmp dentro de --dbpath para concluir a compilação.

Ajuste o limite de memória com o parâmetro maxIndexBuildMemoryUsageMegabytes. O aumento desse parâmetro só é necessário em casos raros, como quando você executa muitas compilações simultâneas de índice com um único comando createIndexes ou quando indexa um conjunto de dados maior que 500GB.

Cada createIndexes comando tem um limite de maxIndexBuildMemoryUsageMegabytes. Ao usar o maxNumActiveUserIndexBuilds padrão de 3, o uso total de memória para todas as compilações de índice simultâneas pode chegar a até 3 vezes o valor de maxIndexBuildMemoryUsageMegabytes.

O limite maxIndexBuildMemoryUsageMegabytes aplica-se a todas as compilações de índice iniciadas por comandos de usuário como createIndexes ou processos administrativos como sincronização inicial.

Uma sincronização inicial preenche apenas uma coleção de cada vez e não tem risco de exceder o limite de memória. No entanto, é possível para um usuário iniciar construções de índice em várias collections em vários bancos de dados simultaneamente.

Tipos de agrupamento e índice

Os tipos de índice a seguir oferecem suporte apenas à comparação binária simples e não oferecem suporte ao agrupamento:

• Text indexes

• 2d indexes

Dica

Para criar um índice text ou 2d em uma collection que tem um agrupamento não simples, você deve especificar explicitamente {collation: {locale: "simple"} } ao criar o índice.

Hidden Indexes

• Você não pode ocultar o índice _id.

• Você não pode utilizar hint() em um índice oculto.

Tipos

Número máximo de chaves de classificação

• Você pode ordenar o máximo de 32 chaves.

• Fornecer um padrão de classificação com campos duplicados causa um erro.

Capped collections

Número máximo de documentos em uma capped collection

Se você especificar o número máximo de documentos em uma capped collection com o parâmetro max de create, o valor deverá ser menor que 2 ³¹ documentos.

Se você não especificar um número máximo de documentos ao criar uma collection limitada, não haverá limite para o número de documentos.

Conjuntos de réplicas

Número de membros de um conjunto de réplicas

Os conjuntos de réplica podem ter até 50 membros.

Número de membros votantes de um conjunto de réplicas

Os conjuntos de réplicas podem ter até 7 membros votantes. Para conjuntos de réplicas com mais de 7 membros, consulte Membros não votantes.

Tamanho máximo do Oplog criado automaticamente

Se você não especificar explicitamente um tamanho de oplog (ou seja, com oplogSizeMB ou ), o MongoDB criará um oplog que não será maior --oplogSize que 50 gigabytes. []1

[1]	O oplog pode ultrapassar seu limite de tamanho configurado para evitar a exclusão do majority commit point.

Clusters fragmentados

Operações indisponíveis em ambientes compartilhados

$where não permite referências ao objeto db da função $where. Isso é incomum em collections não fragmentadas.

Queries cobertas em clusters fragmentados

Ao executar no mongos, os índices só podem cobrir queries em collections fragmentadas e o índice contiver a chave de shard.

Operações de Modificação de Documentos Únicos em Coleções Compartilhadas

Para usar operações update e remove() para uma coleção fragmentada que especifique a opção justOne ou multi: false:

• Se você segmentar apenas um fragmento, poderá usar uma chave de fragmento parcial na especificação da consulta ou,

• Você pode fornecer a chave de estilhaço ou o campo _id na especificação de consulta.

Índices exclusivos em coleções fragmentadas

O MongoDB não oferece suporte a índices exclusivos entre shards, exceto quando o índice exclusivo contém a chave completa do shard como um prefixo do índice. Nessas situações, o MongoDB reforçará a exclusividade em toda a chave, não em um único campo.

Dica

Consulte:

Restrições únicas em campos arbitrários para uma abordagem alternativa.

Número máximo de documentos por intervalo para migração

Por padrão, o MongoDB não poderá mover um intervalo se o número de documentos do intervalo for maior do que o dobro do resultado da divisão do tamanho do intervalo configurado pelo tamanho médio do documento. Se o MongoDB puder mover um subintervalo de um bloco e reduzir o tamanho para menos do que isso, o balanceador o fará migrando um intervalo. db.collection.stats() inclui o campo avgObjSize, que representa o tamanho médio do documento na coleção.

Para chunks grandes demais para serem migrados:

• A configuração do balanceador attemptToBalanceJumboChunks permite que o balanceador migre os blocos grandes demais para serem movidos, desde que os blocos não sejam rotulados como jumbo. Consulte Intervalos de equilíbrio que excedem o limite de tamanho para detalhes.

  Ao emitir comandos do moveRange e moveChunk, é possível especificar a opção forceJumbo para permitir a migração de intervalos que são muito grandes para mover. Os intervalos podem ou não ser rotulados como jumbo.

Chaves de fragmentação

Tipo de índice de chave de shard

Um índice de chave de fragmento pode ser um índice ascendente na chave de fragmento, um índice composto que começa com a chave de fragmento e especifica a ordem ascendente para a chave de fragmento ou um índice com hash.

Um índice de chave de fragmento não pode ser:

• Um índice descendente na chave de fragmento

• Um índice parcial

• Qualquer um dos seguintes tipos de índice:

  • Geoespacial

  • Multichave

  • Text

  • Curinga

Seleção de chave de shard

Suas opções para alterar uma chave de shard dependem da versão do MongoDB que você está executando:

• A partir do MongoDB 5.0, você pode fazer o reshard de uma collection alterando a chave de shard de um document.

• Você pode refinar uma chave de fragmento adicionando um ou mais campos de sufixo à chave de fragmento existente.

O aumento monotônico das chaves de shard pode limitar a taxa de transferência da inserção

Para clusters com altos volumes de inserção, uma chave de shard com chaves crescentes e decrescentes monotonicamente pode afetar a taxa de transferência da inserção. Se a chave de shard for o campo _id, esteja ciente de que os valores padrão dos campos _id são ObjectIds que geralmente têm valores crescentes.

Ao inserir documentos com chaves de shard crescentes monotonicamente, todas as inserções pertencem ao mesmo chunk em um único shard. O sistema eventualmente divide a faixa de chunk que recebe todas as operações de gravação e migra seu conteúdo para distribuir dados de forma mais uniforme. No entanto, a qualquer momento o cluster direciona as operações de inserção apenas para um único shard, o que cria um afunilamento na taxa de transferência de inserção.

Se as operações no cluster forem principalmente operações de leitura e atualizações, essa limitação poderá não afetar o cluster.

Para evitar essa restrição, use uma hashed shard key ou selecione um campo que não aumente ou diminua monotonicamente.

As chaves de shard e os índices de hash armazenam hashes de valores de chaves em ordem ascendente.

operações

Operações de classificação

Se o MongoDB não puder usar um índice ou índices para obter a ordem de classificação, o MongoDB deverá executar uma operação de classificação na memória dos dados.

Para obter mais informações sobre classificações e uso de índices, consulte Uso de classificação e índice.

Estágios do pipeline de agregação

O MongoDB limita o número de fases do pipeline de agregação permitidos em um único pipeline a 1000.

Se um pipeline de agregação exceder o limite de estágio antes ou depois de ser analisado, você receberá um erro.

Memória do pipeline de agregação

A partir do MongoDB 6.0, o parâmetro allowDiskUseByDefault controla se os estágios do pipeline que exigem mais de 100 megabytes de memória para execução de arquivos de escrita temporários no disco por padrão.

• Se allowDiskUseByDefault for definido como true, os estágios do pipeline que exigem mais de 100 megabytes de memória para serem executados gravam arquivos temporários no disco por padrão. Você pode desabilitar a gravação de arquivos temporários em disco para comandos find ou aggregate específicos usando a opção { allowDiskUse: false }.

• Se allowDiskUseByDefault for definido como false, os estágios do pipeline que exigem mais de 100 megabytes de memória para serem executados geram um erro por padrão. Você pode ativar a gravação de arquivos temporários em disco para find ou aggregate específicos usando a opção { allowDiskUse: true }.

O estágio de agregação $search não está restrito a 100 megabytes de RAM porque é executado em um processo separado.

Exemplos de estágios que podem escrever arquivos temporários no disco quando o allowDiskUse é true são:

• $bucket

• $bucketAuto

• $group

• $setWindowFields

• $sort quando a operação de classificação não é suportada por um índice

• $sortByCount

Observação

Os estágios de pipeline operam em fluxos de documentos, em que cada estágio de pipeline recebe documentos, processa-os e, em seguida, gera os documentos resultantes.

Alguns estágios podem não gerar documentos até que tenham processado todos os documentos recebidos. Esses estágios do pipeline devem armazenar os resultados na memória RAM até que todos os documentos recebidos sejam processados. Como resultado, estes estágios do pipeline podem exigir mais espaço do que o limite de 100 MB.

Se os resultados de um dos seus $sort estágios do pipeline excederem o limite, considere adicionar um estágio $limit.

As mensagens de registro do criador de perfil e as mensagens de registro de diagnóstico incluem um indicador usedDisk se algum estágio de agregação gravou dados em arquivos temporários devido a restrições de memória.

Aggregation e read concern

• O estágio $out não pode ser usado em conjunto com preocupação de leitura "linearizable". Se você especificar a preocupação de leitura "linearizable" para db.collection.aggregate(), não poderá incluir o estágio $out no pipeline.

• O estágio $merge não pode ser usado em conjunto com a read concern "linearizable". Ou seja, se você especificar "linearizable" read concern para db.collection.aggregate(), não poderá incluir o estágio $merge no pipeline.

Queries geoespaciais 2D não podem usar o operador $or

Dica

Consulte:

• $or

• Internos do índice 2d

Consultas geoespaciais

Usar um índice 2d para queries sobre dados esféricos pode retornar resultados incorretos ou um erro. Por exemplo, índices 2d não suportam queries esféricas que envolvam em torno dos pólos.

Coordenadas geoespaciais

• Os valores de longitude válidos estão entre -180 e 180, ambos inclusos.

• Os valores de latitude válidos estão entre -90 e 90, ambos inclusos.

Área de Polígonos GeoJSON

Para $geoIntersects ou $geoWithin, se você especificar um polígono de anel único que tenha uma área maior que um único hemisfério, inclua o sistema de referência de coordenadas personalizado do MongoDB na expressão $geometry. Caso contrário, $geoIntersects ou $geoWithin consulta a geometria complementar. Para todos os outros polígonos GeoJSON com áreas maiores que um hemisfério, $geoIntersects ou $geoWithin consulta a geometria complementar.

Transações multidocumento

Para transações com vários documentos:

• Você pode criar coleções e índices em transações. Para obter detalhes, consulte Crie coleções e índices em uma transação

• A coletas utilizadas em uma transação podem estar em diferentes bancos de dados.

  Observação

  Você não pode criar uma nova coleta em transações de gravação entre fragmentos. Por exemplo, se você gravar em uma coleta existente em um fragmento e criar implicitamente uma coleta em um fragmento diferente, o MongoDB não poderá executar ambas as operações na mesma transação.

• Você não pode gravar em coletas limitadas .

• Não é possível usar read concern "snapshot" ao ler em uma capped collection. (A partir do MongoDB 5.0)

• Você não pode ler/gravar em coletas nos bancos de dados config, admin ou local.

• Você não pode gravar na coleção system.*.

• Não é possível retornar o plano de query da operação compatível utilizando explain ou comandos semelhantes.

• Para cursores criados fora de uma transação, você não pode chamar getMore dentro da transação.

• Para cursores criados em uma transação, não é possível chamar getMore fora da transação.

• Você não pode especificar o comando como a primeira operação em killCursors uma transação.

  Além disso, se você executar o comando killCursors em uma transação, o servidor interromperá imediatamente os cursores especificados. Não espera que a transação seja confirmada.

As seguintes operações não são permitidas nas transações:

• Criação de nova coleta em transações de gravação entre fragmentos. Por exemplo, se você gravar em uma coleta existente em um fragmento e criar implicitamente uma coleta em um fragmento diferente, o MongoDB não poderá executar ambas as operações na mesma transação.

• Criação explícita de coleções, por exemplo, Método db.createCollection() e índices, por exemplo, db.collection.createIndexes() e db.collection.createIndex() métodos, ao usar um nível de read concern diferente "local".

• Os comandos listCollections e listIndexes e seus métodos de auxiliar.

• Outras operações não CRUD e não informacionais, tais como createUser, getParameter, count, etc. e seus auxiliares.

• Operações paralelas. Para atualizar vários namespaces simultaneamente, considere usar o comando bulkWrite.

As transações têm um limite de vida útil, conforme especificado por transactionLifetimeLimitSeconds. O padrão é 60 segundos.

Tamanho limite do lote de comandos de gravação

Não há limite para a quantidade de operações de gravação que o driver pode gerenciar. Os drivers agrupam dados em lotes de acordo com o maxWriteBatchSize, que é 100 000 e não pode ser modificado. Se o lote contiver mais 100 de,000 operações, o driver dividirá o lote em grupos menores com contagens menores ou iguais ao maxWriteBatchSize. Por exemplo, se a operação 250 contiver,000 operações, o driver criará três lotes: dois 100 com,000 operações e um com,50 000 operações.

Visualizações

Uma definição de visualização pipeline não pode incluir o estágio $out ou $merge. Essa restrição também se aplica a pipelines incorporados, como pipelines usados em estágios $lookup ou $facet.

As visualizações têm as seguintes restrições de operação:

• As visualizações são somente leitura.

• Não é possível renomear visualizações.

• As operaçõesfind() em visualizações não suportam os seguintes operadores de projeção de comando find:

  • $

  • $elemMatch

  • $slice

  • $meta

• As visualizações não suportam $text.

• As visualizações não suportam operações de redução de mapa.

Restrições de projeção

Restrição de caminho do campo prefixado ``$``

find() findAndModify() A projeção e não pode projeto um campo que comece $ com com exceção dos campos DBRef.

Por exemplo, operação a seguir é inválida:

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

Restrição de colocação do operador posicional ``$``

O operador de projeção $ só pode aparecer no final do caminho do campo, por exemplo "field.$" ou "fieldA.fieldB.$".

Por exemplo, operação a seguir é inválida:

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

Para resolver, remova o componente do caminho do campo que segue o operador de projeção $.

Restrição de projeção de nome de campo vazio

find() A findAndModify() projeção e não pode incluir uma projeção de um nome de campo vazio.

Por exemplo, operação a seguir é inválida:

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

Nas versões anteriores, o MongoDB tratava a inclusão/exclusão do campo vazio como trataria a projeção de campos inexistentes.

Colisão de caminho: documentos incorporados e seus campos

Não é possível projetar um documento incorporado com qualquer um dos campos do documento incorporado.

Por exemplo, considere uma collection inventory com documentos que contêm um campo size:

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

A operação a seguir falha com um erro Path collision porque tenta projetar o documento size e o campo size.uom:

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

Em versões anteriores, a projeção mais recente definida nos documentos incorporados e seus campos determinava a projeção:

• Se a projeção do documento incorporado ocorrer após todas as projeções de seus campos, o MongoDB projetará o documento incorporado. Por exemplo, o documento de projeção { "size.uom": 1, size: 1 } produz o mesmo resultado que o documento de projeção { size: 1 }.

• Se a projeção do documento incorporado ocorrer antes da projeção de qualquer um dos seus campos, o MongoDB projetará o campo ou campos especificados. Por exemplo, o documento de projeção { "size.uom": 1, size: 1, "size.h": 1 } produz o mesmo resultado que o documento de projeção { "size.uom": 1, "size.h": 1 }.

Colisão de caminhos: ``$slice`` de uma array e campos incorporados

find() A findAndModify() projeção e não pode conter um de uma array e um campo incorporado na $slice array.

Por exemplo, considere uma collection inventory que contém um campo de array instock:

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

A seguinte operação falha com um erro Path collision:

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

Nas versões anteriores, a projeção aplica ambas as projeções e retorna o primeiro elemento ($slice: 1) na array instock, mas suprime o campo warehouse no elemento projetado. A partir do MongoDB 4.4, para obter o mesmo resultado, use o método db.collection.aggregate() com dois estágios $project separados.

Operador posicional ``$`` e restrição ``$slice``

find() e projeção findAndModify() não podem incluir expressão de projeção $slice $ como parte de uma expressão de projeção.

Por exemplo, operação a seguir é inválida:

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

Nas versões anteriores, o MongoDB retorna o primeiro elemento (instock.$) na anterior instock que corresponde à condição de query, ou seja, a projeção posicional "instock.$" tem precedência e a $slice:1 não contém nenhum oplog. "instock.$": { $slice: 1 } não exclui nenhum outro campo do documento.

Sessões

Limite de Sessões e $external Username

Para usar Sessões de cliente e garantias de consistência causal com usuários de autenticação $external (usuários Kerberos, LDAP ou X.509), os nomes de usuário não podem ter mais de 10k bytes.

Tempo-limite de inatividade da sessão

As sessões que não recebem operações de leitura ou gravação por 30 minutos ou que não são atualizadas usando refreshSessions são marcadas como expiradas e podem ser fechadas pelo servidor MongoDB . Fechar uma sessão elimina as operações em andamento e os cursores abertos, incluindo aqueles configurados com noCursorTimeout() ou maior maxTimeMS() que 30 minutos.

Operações de cursor de longa duração

Para operações que retornam um cursor que pode ficar ocioso por mais de 30 minutos, emita a operação em uma sessão explícita usando e atualize Mongo.startSession() refreshSessions periodicamente a sessão usando. Por exemplo:

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 exemplo usa a refreshSessions cada 5 minutos para evitar 30o tempo limite de inatividade de minutos. O cursor permanece aberto indefinidamente.

Para drivers MongoDB , consulte a documentação do driver para criar sessões.

Limites de cluster

Limites de conexão por camada do cluster

O MongoDB Atlas limita as conexões concomitantes de entrada com base na camada do cluster e na classe do cluster.

• Os limites de conexão se aplicam por nó

• Para clusters fragmentados, os limites se aplicam por roteador mongos (o número de roteadores é igual ao número de nós do conjunto de réplicas em todos os fragmentos)

• Sua preferência de leitura também afeta o total de conexões alocadas por query

Limites de conexão para camadas do cluster:

Limitação de conexão multinuvem

Se você estiver se conectando a um sistema MongoDB Atlas multinuvem por meio de uma conexão privada, poderá acessar apenas os nós no mesmo provedor de nuvem do qual está se conectando. Esse provedor de nuvem pode não ter o nó primary em sua região. Quando isso acontecer, especifique o modo de preferência de leitura secundário na string de conexão.

Para acessar todos os nós do seu fornecedor atual por meio de uma conexão privada, configure uma VPN ou um endpoint privado para o MongoDB Atlas para cada provedor de nuvem restante.

Limites de collection e índice

Não há limite rígido para o número de collections em um MongoDB Atlas cluster. No entanto, o desempenho se degrada com muitas coletas e índices. Coleções maiores têm maior impacto.

Número máximo combinado recomendado de collections e índices por camada do cluster:

Limites de organização e projeto

As implantações do MongoDB Atlas possuem os seguintes limites de organização e projeto:

Limites da conta de serviço

Limites de etiquetas

O MongoDB Atlas limita o comprimento e força os requisitos do ReGex para as seguintes etiquetas de componentes:

Limitações de cluster gratuito e flexível

Limitações adicionais se aplicam aos clusters gratuitos do MongoDB Atlas e aos clusters Flex. Para saber mais, consulte:

• Limitações de cluster gratuito do Atlas

• Limitações do Atlas Flex

Limitações de comando

Alguns comandos do MongoDB não são suportados no MongoDB Atlas. Adicionalmente, alguns comandos são suportados somente em clusters gratuitos do MongoDB Atlas. Para aprender mais, consulte:

• Comandos Não Suportados no Atlas

• Comandos disponíveis apenas em clusters gratuitos