O que é MongoDB? Recursos, modelagem de documentos e quando usar

O MongoDB é um banco de dados que armazena dados como documentos em vez de organizá-los principalmente em tabelas relacionais. Considere-o para dados frequentemente lidos juntos, como catálogos de produtos com atributos variados ou perfis de usuário aninhados, ao mesmo tempo em que se projeta o esquema e se verifica o desempenho.

Este guia explica o modelo de armazenamento do MongoDB, suas funcionalidades, casos de uso e critérios de adoção. Para uma visão mais ampla, veja a comparação de modelos NoSQL e bancos de dados relacionais.

Como o MongoDB armazena dados?

Um documento consiste em pares de campo e valor. Uma coleção é um agrupamento lógico de documentos, e um banco de dados pode conter coleções para diferentes finalidades, como produtos, pedidos e clientes.

O MongoDB armazena documentos como BSON (Binary JSON). BSON expressa estruturas JSON (JavaScript Object Notation) em forma binária e suporta tipos adicionais, incluindo datas e valores ObjectId. Portanto, o MongoDB não deve ser entendido apenas como um repositório que salva arquivos de texto JSON. A referência de documento explica os tipos e as regras de identificadores.

Este JSON de produto fictício ilustra a forma de um documento. Em uma coleção padrão, o _id identifica um documento. O exemplo usa uma string legível; uma aplicação ainda precisa de um formato de identificador e regras para tratamento de duplicatas.

{
  "_id": "book-101",
  "name": "Database Basics",
  "category": "books",
  "price_krw": 24000,
  "attributes": {
    "author": "Mina Kim",
    "pages": 320
  },
  "tags": [
    "database",
    "beginner"
  ]
}

attributes é um objeto aninhado e tags é um array. Livros podem ter campos de autor e página, enquanto eletrônicos têm informações sobre bateria. Preserve regras compartilhadas para tipos de preço, campos obrigatórios e valores ausentes.

Principais recursos e suas condições

Esquema flexível e validação

Um esquema define campos, tipos e condições obrigatórias. O MongoDB não exige que todos os documentos de uma coleção possuam campos idênticos por padrão. Essa flexibilidade não elimina o design de esquema.

Validação de esquema pode restringir tipos permitidos e intervalos de valores. Coordene verificações da aplicação e validações do banco de dados para evitar preços mistos de números/strings ou representações de datas inconsistentes. Antes de adicionar regras aos dados existentes, identifique documentos não conformes e decida como as atualizações serão tratadas.

Consultas, agregação e dados relacionados

Consultas MongoDB usam condições de campo e operadores em vez de aceitar instruções SQL sem alterações. Aprenda a sintaxe usada pelo driver da sua linguagem ou pelo shell. A notação de ponto acessa campos aninhados, e as consultas também podem expressar condições de arrays.

Um pipeline de agregação processa documentos através de etapas como filtragem, agrupamento e cálculo. Por exemplo, filtrar itens de pedidos não cancelados e totalizar quantidades por produto. O guia pipeline de agregação explica como as etapas funcionam.

$lookup fornece um join externo à esquerda para outra coleção, então “MongoDB não tem joins” é impreciso. Revise suporte a $lookup e condições de desempenho. Não presuma que referências recebem automaticamente a aplicação de integridade referencial associada a constraints de chave estrangeira relacionais.

Índices e desempenho

Um índice é uma estrutura de dados que pode reduzir os dados examinados para encontrar documentos correspondentes. Índices de campo único e compostos atendem a diferentes padrões de acesso. A documentação do índice explica tanto os benefícios da consulta quanto os custos de escrita.

Mais índices exigem armazenamento e trabalho para mantê-los durante as gravações. O desempenho também depende do tamanho do documento, da mistura de leitura/gravação, da memória, dos discos e da rede. Avalie consultas representativas usando planos de execução e carga realista, em vez de assumir que NoSQL é inerentemente rápido.

Transações e garantias de leitura/gravação

Uma atualização de documento único é atômica: ela não aplica parcialmente essa atualização. Para alterações que devem ter sucesso ou falhar juntas em vários documentos, considere transações de múltiplos documentos em conjuntos de réplicas ou clusters particionados. Não presuma que a mesma capacidade exista em um servidor autônomo.

ACID significa Atomicidade, Consistência, Isolamento e Durabilidade. Revise as condições de implementação e configuração na documentação de transações. Quando a criação de pedidos e a redução de inventário afetam documentos separados, defina limites de transação, gerenciamento de solicitações concorrentes e comportamento de repetição.

O parâmetro read concern controla o estado dos dados que uma leitura pode observar, enquanto o parâmetro write concern controla o nível de reconhecimento para uma gravação. Estabeleça as garantias necessárias antes de informar a um usuário que um pagamento foi concluído e distinga operações que podem aceitar valores mais antigos das réplicas.

Os dados relacionados devem ser incorporados ou referenciados?

Incorporar coloca os dados relacionados dentro de um documento. Referenciar cria um vínculo com o identificador de outro documento. O guia de modelagem recomenda armazenar juntos o que é acessado junto; o guia sobre incorporação versus referências explica os trade-offs para relacionamentos e atualizações.

Área de decisão Considere incorporar quando Considere referências quando
Leitura Detalhes do pai e relacionados normalmente são lidos juntos Detalhes relacionados são lidos independentemente
Atualização Valores pertencem a uma unidade de atualização Informações compartilhadas mudam independentemente
Tamanho O grupo tem tamanho e quantidade limitados Itens continuam crescendo ou são grandes
Exemplos Endereço de entrega de um pedido e nome do produto comprado Histórico completo de avaliações ou um perfil de cliente compartilhado

Copiar um endereço de entrega em um pedido pode preservar seu significado histórico. Copiar os dados de contato atuais de um cliente em cada pedido cria cópias para manter quando esses dados mudam. Primeiro, distinguem-se os fatos históricos dos valores que devem estar sempre atualizados.

Um documento BSON comum tem tamanho máximo de 16 mebibytes (MiB). Adicionar cada comentário ou registro de log a um único array pode atingir esse limite e aumentar o custo das atualizações. Use coleções separadas, referências ou grupos de tamanho limitado, levando em conta o limite de tamanho dos documentos.

Quais casos de uso merecem consideração?

Estas são razões para avaliar um modelo de documento, em vez de garantias baseadas em rótulos da indústria. Leituras e atualizações reais devem orientar a escolha.

Caso de uso Razão para considerar documentos Condições a verificar
Catálogo de produtos Diferentes atributos e detalhes aninhados do produto Validação de campo compartilhado e índices de filtragem/classificação
Perfis e conteúdo Leitura de propriedades relacionadas em uma tela Permissões de acesso, grandes arrays e dados duplicados
Eventos e registros de dispositivos Estrutura específica do evento e propriedades extras Consultas de retenção, dispositivo/tempo e crescimento de capacidade
Pedidos Uma captura do estado do pedido Corretude de inventário/pagamento, atualizações concorrentes e transações

Também compare bancos de dados relacionais quando relatórios flexíveis entre tabelas, relacionamentos e restrições compartilhadas ou atualizações complexas muitos-para-muitos são requisitos centrais. Armazenar apenas JSON não justifica substituir um banco de dados existente. Verifique se um modelo de documentos melhora as consultas importantes e a carga operacional.

Um pequeno exemplo de inserção e consulta

Os seguintes comandos usam o MongoDB Shell, mongosh. Conecte-se primeiro a uma implantação de prática separada, usando uma conta com permissões de leitura, escrita e criação de índice para o banco de dados alvo e um shell instalado. Veja a documentação do MongoDB Shell para instruções de conexão.

O exemplo insere um produto em product_catalog no banco de dados mongodb_intro_demo. Comece com uma coleção vazia com este nome em um ambiente de prática e verifique se sua conexão está apontando para esse ambiente antes de executar os comandos.

db = db.getSiblingDB("mongodb_intro_demo");

db.product_catalog.insertMany([
{
  "_id": "book-101",
  "name": "Database Basics",
  "category": "books",
  "price_krw": 24000,
  "attributes": {
    "author": "Mina Kim",
    "pages": 320
  },
  "tags": [
    "database",
    "beginner"
  ]
}
]);

insertMany() insere documentos. Repetir o mesmo _id em uma coleção padrão produz um erro de chave duplicada. Para prática repetida, use um banco de dados de prática novo ou identifique e manipule explicitamente apenas o documento de exemplo que você adicionou. Não exclua uma coleção existente para resolver esse erro.

Esta consulta encontra produtos em books com preço abaixo de 30.000 won coreanos, retorna seus identificadores, nomes e preços e ordena por preço crescente. Com apenas os dados de exemplo presentes, book-101 atende às condições.

db.product_catalog.find(
  { category: "books", price_krw: { $lt: 30000 } },
  { _id: 1, name: 1, price_krw: 1 }
).sort({ price_krw: 1 });

$lt significa “menor que.” O segundo objeto especifica os campos retornados, uma projeção, e 1 em sort() significa ordem ascendente. A referência de find() explica filtros e projeções.

Para filtros de preço específicos de categoria frequentes e ordenação, considere este índice composto. Examine a distribuição real e outras consultas antes de aplicar createIndex() em produção.

db.product_catalog.createIndex(
  { category: 1, price_krw: 1 }
);

O seguinte comando executa a consulta e relata estatísticas de execução sem alterar os documentos. Nos resultados de explain("executionStats"), inspecione o plano escolhido, as chaves e os documentos examinados, e os documentos retornados. Uma coleção pequena pode usar uma varredura de coleção; apenas criar um índice não demonstra uma melhoria de velocidade.

db.product_catalog.find(
  { category: "books", price_krw: { $lt: 30000 } }
).sort({ price_krw: 1 }).explain("executionStats");

Replicação e sharding têm funções diferentes

Um conjunto de réplicas é um grupo de servidores que mantém os mesmos dados. Normalmente, um primário aceita gravações e os secundários replicam as alterações; membros elegíveis podem eleger um novo primário após uma falha. O guia de replicação explica eleições e replicação assíncrona.

A transferência de função (failover) pode causar atrasos temporários nas gravações ou erros, e as leituras dos secundários podem refletir atraso na replicação. A replicação não garante incondicionalmente um serviço contínuo nem previne toda perda de dados. Projete mecanismos de nova tentativa, tratamento de solicitações duplicadas e garantias necessárias de leitura/gravação juntamente com a aplicação.

O sharding distribui dados entre servidores para escalabilidade horizontal. A chave de shard contém os campos usados para distribuição e roteamento das consultas. Chaves concentradas ou consultas que precisam visitar todos os shards podem limitar o benefício. O guia de sharding explica a escolha das chaves e a complexidade operacional.

Replicação e sharding podem ser usados juntos, mas servem a propósitos diferentes. Verifique o modelo, os índices e os gargalos atuais antes de introduzir o sharding apenas porque os dados podem crescer. Deve haver um motivo para aceitar sua complexidade e custo extra.

O que você deve verificar antes de adotar o MongoDB?

  1. Defina operações importantes. Especifique filtros, ordenação e unidades de atualização para detalhes de produtos, buscas de preços por categoria e criação de pedidos; compare implementações relacionais e de documentos reais.
  2. Revise o modelo e a correção dos dados. Decida sobre a utilização de incorporação ou referências, tamanho do documento, validação, índices, transações e requisitos de leitura imediata.
  3. Compare cargas representativas. Meça latência, taxa de transferência e erros com dados realistas e distribuição de solicitações. Registre versões, hardware e configurações, e examine cenários de falha e recuperação.
  4. Escolha um modelo operacional. Decida entre autogerenciamento e um serviço gerenciado, atribuindo responsabilidade por backup, restauração, monitoramento, atualizações e suporte.
  5. Prepare a migração e uma rota de retorno. Defina conversões de identificador/tipo, verificações de dados ausentes, gravações durante a transição e condições para retornar ao armazenamento existente.

MongoDB Atlas é um serviço em nuvem gerenciado com uma divisão de responsabilidade operacional diferente de uma implantação autogerida. Use a documentação do Atlas para verificar os recursos e opções de implantação necessários. Inclua armazenamento, backups, rede e trabalho operacional juntamente com os custos da instância.

Em produção, revise contas com privilégio mínimo, conexões criptografadas, restrições de rede e gerenciamento de credenciais conforme as orientações de segurança do MongoDB adequadas à sua implantação. Uma exclusão acidental pode se propagar às réplicas, por isso a replicação não substitui o backup. Siga as orientações sobre métodos de backup e verifique se a restauração realmente funciona.