Limites e limiares do MongoDB

Limitações do Atlas do MongoDB

As limitações a seguir se aplicam apenas a implantações hospedadas no MongoDB Atlas. Se algum desses limites apresentar um problema para sua organização, entre em contato com o suporte do Atlas.

Documentos BSON

Tamanho do documento BSON

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

O tamanho máximo do documento ajuda a garantir que este não possa usar uma quantidade excessiva de RAM ou, durante a transmissão, uma quantidade excessiva de largura de banda. Para armazenar documentos maiores que o tamanho máximo, o MongoDB fornece a API GridFS. Para obter mais informações sobre a GridFS, consulte mongofiles 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. Por exemplo, você não pode usar dois bancos de dados com nomes como salesData e SalesData.

Depois de criar um banco de dados no MongoDB, você deve usar a capitalização consistente quando se referir a ele. Por exemplo, 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

Para implantações do MongoDB executadas no Windows, os nomes dos bancos de dados não podem conter nenhum dos seguintes caracteres:

/\. "$*<>:|?

Os nomes do banco de dados também não podem conter o caractere nulo.

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

Para implantações do MongoDB executadas em sistemas Unix e Linux, os nomes dos bancos de dados não podem conter nenhum dos seguintes caracteres:

/\. "$

Os nomes do banco de dados também não podem conter o caractere nulo.

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.)

Se o nome da collection incluir caracteres especiais, como o caractere sublinhado, ou começar com números, para acessar a collection 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 collection e visualizações não fragmentadas é de 255 bytes e 235 bytes para collection fragmentadas. Para uma collection ou visualização, o namespace inclui o nome do banco de dados, o separador do ponto (.) e o nome da collection/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.

Restrições em _id

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

Avisos de nomenclatura

Namespaces

Comprimento do namespace

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

Dica

Veja também:

Restrições de nomeação

Índices

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

Não pode haver mais de 32 campos em um índice composto.

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

Veja também:

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 duplo

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

Índice Multichave

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 concluir as compilações de índice. O limite padrão de uso de memória para createIndexes é 200 megabytes, compartilhados entre todos os índices compilados usando um único comando createIndexes . Após o limite de memória ser alcançado, o createIndexes utiliza arquivos de disco temporários em um subdiretório denominado _tmp dentro do diretório --dbpath para concluir a compilação.

Você pode substituir o limite de memória configurando o parâmetro do servidor maxIndexBuildMemoryUsageMegabytes. A definição de um limite de memória maior pode resultar na conclusão mais rápida das compilações de índices. No entanto, um limite muito alto em relação à RAM não utilizada no seu sistema pode resultar no esgotamento da memória e no desligamento do servidor.

• Para "4.2" e posteriores da versão de compatibilidade de recursos (fcv), o limite de memória de compilação de índice se aplica a todas as compilações de índice.

As compilações de índice podem ser iniciadas por um comando de usuário, como createIndexes, ou por um processo administrativo, como uma initial sync. Ambos estão sujeitos ao limite definido por maxIndexBuildMemoryUsageMegabytes.

Uma initial sync preenche apenas uma collection 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 ao mesmo tempo e potencialmente consumir uma quantidade de memória maior do que o limite definido por maxIndexBuildMemoryUsageMegabytes.

Dica

Para minimizar o impacto da criação de um índice em conjunto de réplicas e clusters fragmentados com fragmentos de conjuntos de réplicas, use um procedimento de compilação de índice contínuo, conforme descrito em Rolling Index Builds on Replica Sets.

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:

• Índices de texto

• Índices 2d

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.

Índices ocultos

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

Dados

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 --oplogSize), o MongoDB criará um oplog que não seja maior que 50 gigabytes. [4]

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

Clusters fragmentados

Os clusters fragmentados têm as restrições e limites descritos aqui.

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 ordenador bloqueante nos dados. O nome refere-se ao requisito de que o estágio SORT leia todos os documentos de entrada antes de retornar documentos de saída, bloqueando o fluxo de dados para essa query específica.

Se o MongoDB exigir o uso de mais de 100 megabytes de memória do sistema para a operação de block sort, o MongoDB retornará um erro a menos que a query especifique cursor.allowDiskUse(). allowDiskUse() permite que o MongoDB use arquivos temporários no disco para armazenar dados que excedam o limite de memória do sistema de 100 megabytes ao processar uma ordenador bloqueante.

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

Operação do aggregation pipeline

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 aggregation $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 read concern "linearizable". Se você especificar "linearizable" read concern 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 killCursors como a primeira operação em uma transação.

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.

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

100,000 escritas são permitidas em uma única operação em lote, definida por uma única solicitação ao servidor.

Alterado na versão 3.6: O limite aumenta de 1,000 para 100,000 gravações. Este limite também se aplica a mensagens de versões antigas OP_INSERT .

As operações Bulk() no mongosh e métodos comparáveis nos drivers não têm este limite.

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ções find() nas exibições não são compatíveis com os seguintes operadores de query e projeção:

  • $

  • $elemMatch

  • $slice

  • $meta

• Os modos de exibição não oferecem suporte à pesquisa de texto.

• 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

A projeção find() e findAndModify() não pode projetar um campo que começa com $ com exceção dos campos DBRef.Por exemplo, a seguinte operação é 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, a seguinte operação é 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

A projeção find() e findAndModify() não pode incluir uma projeção de um nome de campo vazio. Por exemplo, a seguinte operação é 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

Você não pode projeto um documento incorporado com nenhum 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 resultará em um erro Path collision pois ela tenta projetar o documento size e o campo size.uom simultaneamente:

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 caminho: $slice de uma array e campos incorporados

As projeções find() e findAndModify() não podem conter um $slice de uma array e um campo embutido na 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

A projeção find() e findAndModify() não podem incluir a expressão de projeção $slice como parte de uma expressão de projeção $ . Por exemplo, a seguinte operação é 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 Client Sessions e Causal Consistency Guarantees 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 dentro desse limite são marcadas como expiradas e podem ser fechadas pelo servidor MongoDB a qualquer momento. Fechar uma sessão elimina as operações em andamento e os cursores abertos associados à sessão. Isso inclui cursores configurados com noCursorTimeout() ou maxTimeMS() maior que 30 minutos.

Considere um aplicativo que emite um db.collection.find(). O servidor retorna um cursor junto com um lote de documentos definido pelo cursor.batchSize() do find(). A sessão é atualizada toda vez que o aplicativo solicita um novo lote de documentos do servidor. No entanto, se o aplicativo demorar mais de 30 minutos para processar o lote atual de documentos, a sessão será marcada como expirada e encerrada. Quando o aplicativo solicita o próximo lote de documentos, o servidor retorna um erro, pois o cursor foi eliminado quando a sessão foi fechada.

Para operações que retornam um cursor, se o cursor ficar inativo por mais de 30 minutos, execute a operação em uma sessão explícita usando e atualize periodicamente Mongo.startSession() refreshSessions a sessão usando o comando. 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
}

Na operação de exemplo, o método db.collection.find() está associado com uma sessão explícita. O cursor é configurado com noCursorTimeout() para evitar que o servidor feche o cursor se estiver ocioso. O loop while inclui um bloco que utiliza refreshSessions para atualizar a sessão a cada 5 minutos. Como a sessão nunca excederá o tempo-limite de inatividade de 30 minutos, o cursor pode permanecer aberto indefinidamente.

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