Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/
Introdução

Documentos

Nesta página

  • Compatibilidade
  • Estrutura do documento
  • Notação de ponto
  • Limitações de documentos
  • Outros usos da estrutura de documentos
  • Leitura adicional

O MongoDB armazena registros de dados como documentos BSON. O BSON é uma representação binária de documentos JSON embora contenha mais tipos de dados do que o JSON. Para a especificação BSON, consulte bsonspec.org. Consultetambém Tipos de JSON.

Um documento MongoDB.

Compatibilidade

O MongoDB armazena registros como documentos para sistemas hospedados nos seguintes ambientes:

  • MongoDB Atlas: o serviço totalmente gerenciado para implantações do MongoDB na nuvem

  • MongoDB Enterprise: a versão autogerenciada e baseada em assinatura do MongoDB

  • MongoDB Community: uma versão com código disponível, de uso gratuito e autogerenciada do MongoDB

Estrutura do documento

Os documentos do MongoDB são compostos por pares de campo e valor e têm a seguinte estrutura:

{
   field1: value1,
   field2: value2,
   field3: value3,
   ...
   fieldN: valueN
}

O valor de um campo pode ser qualquer um dos tipos de dados BSON, incluindo outros documentos, matrizes e matrizes de documentos. Por exemplo, o documento a seguir contém valores de vários tipos:

var mydoc = {
               _id: ObjectId("5099803df3f4948bd2f98391"),
               name: { first: "Alan", last: "Turing" },
               birth: new Date('Jun 23, 1912'),
               death: new Date('Jun 07, 1954'),
               contribs: [ "Turing machine", "Turing test", "Turingery" ],
               views : NumberLong(1250000)
            }

Os campos acima têm os seguintes tipos de dados:

  • _id contém um ObjectId.

  • name Contém um documento incorporado que contém os campos first e last.

  • birth e death contêm valores do tipo Data .

  • contribs contém uma array de strings.

  • views contém um valor do tipo NumberLong .

Nomes dos campos

Os nomes dos campos são strings.

Os documentos têm as seguintes restrições em nomes de campos:

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

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

A linguagem de query do MongoDB não oferece suporte a documentos com nomes de campo duplicados:

  • Embora alguns construtores BSON possam suportar a criação de um documento BSON com nomes de campo duplicados, a inserção desses documentos no MongoDB não é suportada mesmo que a inserçã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 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.

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 como true. Em qualquer versão do MongoDB , use o $objectToArray operador de agregação para ver se um documento tem nomes de campo duplicados.

Notação de ponto

O MongoDB usa a notação de ponto para acessar os elementos de uma array e para acessar os campos de um documento incorporado.

arrays

Para especificar ou acessar um elemento de uma array pela posição de índice baseada em zero, concatene o nome da array com o ponto (.) e a posição de índice baseada em zero e coloque entre aspas:

"<array>.<index>"

Por exemplo, dado o seguinte campo em um documento:

{
   ...
   contribs: [ "Turing machine", "Turing test", "Turingery" ],
   ...
}

Para especificar o terceiro elemento na array contribs, utilize a notação de ponto "contribs.2".

Para ver exemplos de arrays de consulta, consulte:

Dica

Veja também:

  • $[] todos os operadores posicionais para operações de atualização,

  • $[<identifier>] operador posicional filtrado para operações de atualização,

  • $ operador posicional para operações de atualização,

  • $ operador de projeção quando a posição do índice da array é desconhecida

  • Consulte um array para obter exemplos de notação de ponto com arrays.

Documentos incorporados

Para especificar ou acessar um campo de um documento incorporado com notação de ponto, concatene o nome do documento incorporado com o ponto (.) e o nome do campo, e coloque entre aspas:

"<embedded document>.<field>"

Por exemplo, dado o seguinte campo em um documento:

{
   ...
   name: { first: "Alan", last: "Turing" },
   contact: { phone: { type: "cell", number: "111-222-3333" } },
   ...
}

  • Para especificar o campo denominado last no campo name, utilize a notação de ponto "name.last".

  • Para especificar o number no documento phone no campo contact, use a notação de ponto "contact.phone.number".

Aviso

Os campos de partição não podem usar nomes de campos que contêm um ponto (.).

Para ver exemplos de consultas de documentos incorporados, consulte:

Limitações de documentos

Os documentos têm os seguintes atributos:

Limite de tamanho do documento

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 do que o tamanho máximo, o MongoDB fornece a API GridFS. Para obter mais informações sobre o GridFS, consulte mongofiles e a documentação do seu driver.

Ordem dos campos do documento

Ao contrário dos objetos JavaScript, os campos em um documento BSON são ordenados.

Ordem dos campos nas consultas

Para consultas, o comportamento da ordem dos campos é o seguinte:

  • Ao comparar documentos, o pedido de campo é significativo. Por exemplo, ao comparar documentos com campos a e b em uma consulta:

    • {a: 1, b: 1} é igual a {a: 1, b: 1}

    • {a: 1, b: 1} não é igual a {b: 1, a: 1}

  • Para uma execução de consulta eficiente, o mecanismo de consulta pode reordenar campos durante o processamento de consulta. Entre outros casos, a reordenação de campos pode ocorrer ao processar estes operadores de projeção: $project, $addFields, $set e $unset.

    • A reordenação dos campos pode ocorrer em resultados intermediários, bem como nos resultados finais retornados por uma consulta.

    • Como algumas operações podem reordenar campos, você não deve confiar na ordenação de campos específicos nos resultados retornados por uma consulta que usa os operadores de projeção listados anteriormente.

Ordem dos campos em operações de gravação

Para operações de gravação, o MongoDB preserva a ordem dos campos do documento,exceto para os seguintes casos:

  • O campo _id é sempre o primeiro campo do documento.

  • As atualizações que incluem renaming dos nomes de campos podem resultar na reordenação de campos no documento.

O campo _id

No MongoDB, cada documento armazenado em uma collection padrão requer um campo _id exclusivo que atua como uma chave primária. Se um documento inserido omitir o _id campo, o driver MongoDB gerará automaticamente um ObjectID para o _id campo.

Isso também se aplica a documentos inseridos por meio de operações de atualização com upsert: true.

Observação

Em coleções de séries temporais, os documentos não exigem um campo _id exclusivo porque o MongoDB não cria um índice no _id campo.

O campo _id tem o seguinte comportamento e restrições:

  • Por padrão, o MongoDB cria um índice único no campo _id durante a criação de uma coleta.

  • O campo _id é sempre o primeiro campo nos documentos. Se o servidor receber um documento que não tenha o campo _id primeiro, o servidor moverá o campo para o início.

  • Se o _id contiver subcampos, os nomes dos subcampos não poderão começar com um símbolo ($).

  • O campo _id pode conter valores de qualquer tipo de dados BSON, exceto uma matriz, regex ou indefinido.

    Aviso

    Para garantir o funcionamento da replicação, não armazene valores que sejam do tipo de expressão regular BSON no campo _id.

A seguir encontram-se opções comuns para armazenar valores para _id:

  • Usar um ObjectId.

  • Use um identificador exclusivo natural, se disponível. Isso economiza espaço e evita um índice adicional.

  • Gerar um número de incremento automático.

  • Gere um UUID no código da sua aplicação. Para um armazenamento mais eficiente dos valores de UUID na coleta e no índice _id, armazene o UUID como um valor do tipo BSON BinData.

    As chaves de índice que são do tipo BinData são armazenadas de forma mais eficiente no índice se:

    • o valor do subtipo binário está na faixa de 0-7 ou 128-135, e

    • o comprimento da array de bytes é: 0, 1, 2, 3, 4, 5, 6, 7, 8, 10, 12, 14, 16, 20, 24 ou 32.

  • Use a instalação BSON UUID do seu driver para gerar UUIDs. Esteja ciente de que as implementações de drivers podem implementar a lógica de serialização e desserialização do UUID de forma diferente, o que pode não ser totalmente compatível com outros drivers. Consulte a documentação do driver para obter informações sobre a interoperabilidade do UUID.

Observação

A maioria dos clientes de driver do MongoDB inclui o campo _id e gera um ObjectId antes de enviar a operação de inserção para o MongoDB. Entretanto, se o cliente enviar um documento sem um campo _id , o mongod adiciona o campo _id e gera o ObjectId.

Outros usos da estrutura de documentos

Além de definir registros de dados, o MongoDB usa a estrutura do documento por toda parte, incluindo, mas não limitado a: filtros de queries, documentos de especificações de atualização e documentos de especificação de índice

Documentos do filtro de consulta

Os documentos de filtro de consulta especificam as condições que determinam quais registros selecionar para as operações de ler, atualizar e excluir.

Você pode utilizar expressões do <field>:<value> para especificar a condição de igualdade e expressões do operador de consulta.

{
  <field1>: <value1>,
  <field2>: { <operator>: <value> },
  ...
}

Para exemplos, consulte:

Atualizar documentos de especificação

Os documentos de especificação de atualização usam operadores de atualização para especificar as modificações de dados a serem executadas em campos específicos durante uma operação de atualização.

{
  <operator1>: { <field1>: <value1>, ... },
  <operator2>: { <field2>: <value2>, ... },
  ...
}

Por exemplo, consulte Atualizar especificações.

Documentos de especificação de índices

Os documentos de especificação de índices definem o campo para o índice e o tipo de índice:

{ <field1>: <type1>, <field2>: <type2>, ...  }

Leitura adicional

Para obter mais informações sobre o modelo de documento do MongoDB, baixe o Guia de modernização de aplicativos do MongoDB.

O download inclui os seguintes recursos:

  • Apresentação sobre a metodologia de modelagem de dados com o MongoDB

  • Artigo técnico que aborda as melhores práticas e considerações para migrar de um modelo de dados SGBD para o MongoDB

  • Referenciar o esquema do MongoDB com seu equivalente em SGBD

  • Scorecard de modernização de aplicativos

Voltar

Clustered Collections

Próximo

API de Consulta