?? CAPÍTULO 18: NOSQL E MONGODB — DO DOCUMENTO À AGGREGATION

Bem-vindo(a) à fronteira atual da Engenharia de Dados corporativa. A partir de agora, expandiremos a sua mente arquitetural para além do clássico paradigma relacional. ?????

Objetivo: Compreender as motivações essenciais que deram origem ao movimento NoSQL, suas diferenças arquiteturais em relação aos sistemas RDBMS, e o impacto estratégico do Teorema CAP na concepção de sistemas distribuídos de escala global.

?? PASSO 1: A Origem do Paradigma "Not Only SQL"

Por mais de três décadas, bancos como PostgreSQL e SQL Server dominaram absolutos. Contudo, com o advento das Redes Sociais, da Internet das Coisas (IoT) e de volumes na casa dos Petabytes, o modelo relacional rígido sofreu impactos em escalabilidade.

Surgiram então os bancos de dados não-relacionais (NoSQL), priorizando velocidade massiva de leitura/escrita e esquemas flexíveis. Atualmente, o termo é amplamente aceito como Not Only SQL (Não Apenas SQL), indicando que ele complementa o relacional, e não tenta substitui-lo de forma arrogante. ???

?? PASSO 2: O Desafio Estratégico do Teorema CAP

Ao abandonarmos um único servidor potente e passarmos a rodar bancos de dados cruzando oceanos em centenas de máquinas (clusters), esbarramos numa lei física da engenharia de computação postulada por Eric Brewer: O Teorema CAP.

Para qualquer banco de dados distribuído de grande escala, é matematicamente impossível garantir simultaneamente as 3 propriedades abaixo:

1. C (Consistência): Todos os clientes enxergam a mesma informação simultaneamente.
2. A (Disponibilidade): O sistema responde sempre, mesmo que dados estejam desatualizados.
3. P (Tolerância à Partição): O sistema sobrevive se um cabo de rede for cortado entre o Brasil e o Japão.

?? Balanço Arquitetural (Teorema CAP)

flowchart TD
    CAP["⚖️ Teorema CAP"]
    CAP -->|CP| MGB["MongoDB / HBase"]
    CAP -->|AP| CAS["Cassandra / DynamoDB"]
    CAP -->|CA| RDB["PostgreSQL / MySQL"]

    subgraph Prioridade CP
        direction TB
        MGB_info("Garante Consistência<br/>Resiste a quedas de rede<br/>Mas pode falhar na Disponibilidade")
    end
    
    subgraph Prioridade AP 
        direction TB
         CAS_info("Sempre Disponível<br/>Resiste a quedas de rede<br/>Consistência eventual")
    end

?? Atenção: Em sistemas complexos nativos da nuvem (Cloud Native), as "Partições" (quedas de comunicação entre os hubs nos EUA e Europa, por exemplo) não são probabilidades, são certezas. Portanto, você deve escolher na realidade entre CP ou AP. ???

?? PASSO 3: Por que o MongoDB 7.0 LTS?

Dentre de dezenas de modalidades de sistemas "NoSQL", o MongoDB domina a vasta maioria dos cenários contemporâneos.

1. Arquitetura baseada em Documentos: Os dados não são forçados em matrizes bi-dimensionais (tabelas e colunas). Eles fluem de forma hierárquica usando BSON (Uma versão binária de hiper-performance do JSON).
2. Schema Dinâmico (Flexible Schema): Um usuário pode ter um endereço com número de casa e outro usuário com lote, andar de apartamento, tudo sob a mesma entidade sem precisar gerar "colunas nulas".
3. Filosofia CP: Ele prioriza a Consistência dos dados acima de tudo através do sistema elegante do seu "Replica Set".

?? Nota do Arquiteto: Você não precisa escolher entre relacional e NoSQL. A arquitetura corporativa moderna utiliza a Persistência Poliglota: Usar PostgreSQL ?? para auditoria financeira e MongoDB ?? para a navegação acelerada de um feed infinito. ?????

?? MODELAGEM ORIENTADA A DOCUMENTOS

Se na engenharia SQL nós dividimos e isolamos os dados em dezenas de tabelas (Normalização), na engenharia Documental aplicamos frequentemente a fusão das informações vitais num pilar estratégico único. ?????

Objetivo: Diferenciar as abordagens de Modelagem Relacional da Abordagem Documental do MongoDB 7.0, compreendendo os conceitos de Embedding, Referencing e Documentos Aninhados.

?? PASSO 1: O Paradigma do Preço Computacional

Em sistemas RDBMS massivos, o JOIN computacional pode ser dispendioso. No MongoDB 7.0 (arquitetura BSON), se um Cliente possui "Endereços" e "Telefones", qual a forma mais rápida de exibi-los? Guardando tudo junto do Cliente!

O ato de acoplar sub-detalhes dentro do seu registro primário recebe o nome acadêmico de Embedding (Documento Incorporado).

?? PASSO 2: Embedding vs DBRefs (Referências Virtuais)

Devemos analisar a necessidade de arquitetura com precisão lógica:

1. ?? Embedding (Guardar Junto): Acessa tudo numa pancada de I/O em tela. Excelente para relacionamentos 1:1 e relacionamentos 1:N onde "N" é um número controlado.
2. ?? References (Chavear/Apontar): Guarda apenas o _id do documento equivalente (Similar ao modelo Foreign Key - FK do relacional). Obrigatório se envolver um crescimento contínuo e infinito de registros M:N.

?? PASSO 3: Diagrama de Entidade-Documento (Mermaid Híbrido)

A notação de Chen (losangos e elipses) perde eficiência diante de estruturas fortemente encadeadas (Arrays/Objetos profundos).

A notação didática da escola de inteligência de dados sugere fundir o MER (Entidade-Relacionamento) utilizando Tipos JSON explícitos (Array/Object) e detalhando no modelo do conector Mermaid a natureza da associação (EMBEDDED vs REFERENCE):

?? Modelo Híbrido Didático (Composição MongoDB)

erDiagram    
    CLIENTE ||--o{ EMBEDDED_ENDERECO : "EMBEDDED (JSON)"
    CLIENTE ||--o{ COMPRA : "REFERENCE (DBRef)"
    
    CLIENTE {
        ObjectId _id PK
        String nome
        String email
        Array~String~ telefones
        Array~Object~ enderecos
        Document metadados
    }
    
    EMBEDDED_ENDERECO {
        String logradouro
        String cidade
        String uf
    }
    
    COMPRA {
        ObjectId _id PK
        ObjectId cliente_id FK
        Decimal128 valor_total
        Date criado_em
    }

?? Atenção (Rigidez Tecnológica): Na Engenharia MongoDB v7.0, todos os documentos ganham compulsoriamente um identificador único indexado de alta performance chamado _id (do tipo ObjectId, equivalente conceitual ao UUID relacional).

?? PASSO 4: Regra Prática de Engenharia de Sistemas (Desempenho)

A resposta da pergunta clássica moderna — "Qual abordagem usar no Mongo?"

• Você tem um PostBlog que sempre precisa exibir uma miniatura de perfil do Autor (nome e foto_url)? Faça Embedding dos metadados essenciais.
• Você tem um PostBlog que precisa registrar visualizações de milhares de máquinas (Analytics)? O array explodirá muito rápido! Use obrigatoriamente Referencing (DBRefs) via IDs para uma collection de logs secundária separada.

?? Dica de Engenheiro de Dados: A normalização (1NF, 2NF, 3NF) foi projetada historicamente para salvar espaço de disco (que era caro em 1980 na matriz do sistema bancário). Hoje o disco é infinitamente barato comparado ao custo de se demorar 2 minutos aguardando relatórios em RAM para a máquina analítica de negócio (Analytics). Priorize sempre a velocidade das "QueryReads"! ?????

?? OPERAÇÕES CRUD MODERNAS E SINTAXE MQL

Tendo compreendido que o NoSQL é focado em matrizes declarativas flexíveis (Documentos BSON), você deve abandonar a mentalidade rígida do SQL em prol da versatilidade ágil do MQL (MongoDB Query Language). ?????

Objetivo: Diferenciar o comportamento transacional do SQL para a manipulação rápida de documentos usando funções Javascript assíncronas no motor V8 do MongoDB 7.0 (via mongosh e Compass).

?? PASSO 1: Estrutura Base (Collection MQL)

Em ambientes RDBMS (?? PostgreSQL), as faturas dependem dos produtos, os telefones da tabela dependente e todos são fortemente tipados.

No MongoDB 7.0, os dados residem numa Collection. Ao invés de Insert, Select, Update e Delete monolíticos, o MongoDB padronizou seus vetores via métodos tipificados JavaScript.

?? PASSO 2: INSERT (Create)

A função insertOne() e insertMany() recebem objetos literais estruturados e aceitam metadados não tipados (JSON arrays nativos):

/* INSERINDO O CLIENTE COM ARRAY (TELEFONES) NA COLLECTION DE "USUARIOS" */
db.usuarios.insertOne({
    nome: "Linus Torvalds",
    email: "linus@kernel.org",
    idade: 54,
    telefones: ["55-8888-1234", "55-9999-4321"],
    endereco: {
        logradouro: "Rua Open Source, 101",
        cep: "1001-500"
    },
    status_assinatura: "Ativa"
});

?? PASSO 3: FIND (Read)

No MQL, o SELECT * FROM TABELA cede espaço à abstração mais veloz e paramétrica da busca por expressões regulares e encadeamentos ($gt, $in e propriedades dot.notation):

/* BUSCANDO CLI COM MAIS DE 40 ANOS (Gt = Greater Than) */
db.usuarios.find({ idade: { $gt: 40 } });

/* BUSCAR CLIENTE PELO LUGAR NIDIFICADO (DOT NOTATION) */
db.usuarios.find({ "endereco.cep": "1001-500" });

?? PASSO 4: UPDATE (Update Parcial BSON)

Se errar a lógica do comando e submeter o nó inteiro em vez de apenas o parâmetro usando a instrução chave de atualização (O operador set), o arquivo JSON é sobrescrito:

/* O OPERADOR $SET SÓ ALTERA A CHAVE SELECIONADA. SE NÃO LHE INSTRUIR, ELE APAGA TODO RESTO! */
db.usuarios.updateOne(
    { email: "linus@kernel.org" }, 
    { $set: { status_assinatura: "Suspensa" } }
);

/* O OPERADOR $PUSH INSERE UM NOVO ITEM NO FINAL DE UM ARRAY */
db.usuarios.updateOne(
    { nome: "Linus Torvalds" }, 
    { $push: { telefones: "00-0000-0000" } }
);

?? PASSO 5: DELETE (Removendo O Documento Inteiro)

/* Exclui o primeiro documento encontrado que tem menos de 18 anos */
db.usuarios.deleteOne({ idade: { $lt: 18 } });

?? Diferença de Dialeto SQL vs MQL: No PostgreSQL 17, UPDATE table SET campo = valor atinge a tabela inteira se esquecer o WHERE. No MongoDB, o updateOne é cirúrgico e trava na primeira correspondência, evitando acidentes nucleares de DBA. ?????

?? AGGREGATION FRAMEWORK E PIPELINE

Se o find() te leva de 0 a 100 na abstração rápida, o Aggregation Framework te eleva de 100 a 1000, dominando qualquer Business Intelligence complexo. ?????

Objetivo: Extrair poder máximo de relatórios cruzados (Análises, Filtros de Etapas, Projetos de Sub-campos Arrays, Group By nativo MQL).

?? PASSO 1: A Arquitetura do Operador de Tubulação (Pipeline)

No relacional (SQL), a leitura da CPU e Ram do servidor obedece à linearidade estrita SELECT, FROM, WHERE, GROUP BY, HAVING. Na matemática NoSQL distribuída, os dados massivos desistem das tabelas únicas, processando blocos e empurrando o resultado via "Pipeline" (Em lotes de estágios) para que uma máquina minúscula aguente trabalhar grandes Gigabytes.

?? Ciclo de Estágios do Pipeline do BSON

flowchart LR
    M1["🔍 1. $match"] --> G1["👥 2. $group"]
    G1 --> P1["📊 3. $project"]
    P1 --> S1["🔀 4. $sort"]

• $match: Filtra como o clássico WHERE e joga metade dos documentos no Lixo cedo (economiza Ram).
• $group: O clássico GROUP BY e agregadores de soma (SUM, AVG).
• $project: Modela quais atributos a aplicação cliente receberá (Economiza Banda/Tráfego de Internet).
• $sort: Põe os dados em Ordem (ORDER BY).

?? PASSO 2: Anatomia de Extração no MongoDB 7.0

Como o engenheiro descobre "Quantidade de Dinheiro da Filial SP nos últimos 7 dias?".

db.faturas.aggregate([
    
    // 1º ETAPA DO CANO: CORTA O QUE NÃO FOR DE SÃO PAULO
    { 
       $match: { filial: "SP", ano: 2026 } 
    },
    
    // 2º ETAPA: JUNTA TODOS QUE SOBRARAM SOMANDO A FATURA E AGRUPANDO PELO VENDEDOR
    { 
       $group: { 
           _id: "$vendedor", 
           faturamento_total: { $sum: "$valor_liquido" },
           total_vendas: { $sum: 1 } 
       } 
    },
    
    // 3º ETAPA: ORDENANDO O MELHOR FATURAMENTO
    {
       $sort: { faturamento_total: -1 } // -1 = DESCENDING
    }

]);

?? PASSO 3: Cross-Joins $lookup do MQL (DBRefs Profundos)

A ideia de que "MongoDB e NoSQL não faz Join" é Fake News Arquitetônica. Através do estágio $lookup da Pipeline moderna (> MongoDB 6.0+), unimos Arrays nativamente:

/* BUSCANDO PEDIDO E SUAS REFERÊNCIAS DE FATURA EXCLUSIVA */
db.pedidos.aggregate([
   {
     $lookup: {
       from: "detalhesFatura",   // Qual a "tabela" secundária 
       localField: "faturaId",   // Onde está o ID nesse Documento A
       foreignField: "_id",      // Onde está o ID no Documento B (Fatura)
       as: "faturaCorrigida"     // Qual será o nome do Objeto Inserido Array
     }
  }
]);

?? Nota do DBA Master: Assim que uma Collection cresce com velocidade, usar $lookup esgota a CPU (ele compara 1 doc contra milhares toda hora). Se precisar buscar juntas sempre, mude a estrutura do projeto da Empresa e faça EMBEDDING JSON direto! ?????

?? PERFORMANCE: ÍNDICES E SCHEMA ANALYSIS

Como engenheiro estrito do NoSQL, não há compilação linear como no RDBMS, há verificação de cache e leituras contínuas (I/O). Se a coleção da empresa tem milhões de usuários, um db.usuarios.find({ status: "Ativo" }) fará uma verificação um por um no HD (Collection Scan). ?????

Objetivo: Explorar os mecanismos nativos de performance visual do Compass v1.4x, criando Índices B-Tree eficientes para evitar Gargalos de I/O em produções NoSQL de larga escala.

?? PASSO 1: Índices Básicos via Shell

Um índice empacota metadados de acesso (Ponteiros Lógicos) na RAM e os ordena (ASC/DESC). No MQL, adicionamos performance com precisão em Campos Filhos de forma fluída.

/* CRIANDO O MAPEAMENTO RÁPIDO PARA ORDENAR IDADES DOS CLIENTES (-1 para Z-A Descendente) */
db.usuarios.createIndex({ idade: -1 });

/* ÍNDICES DE ARRAYS INTEIROS (Multikey Index) */
db.loja.createIndex({ "categorias_produto": 1 });

?? PASSO 2: O Poder do Compass (Visual Schema Analysis)

Diferente do SQL (onde você sabe na vírgula quais são os campos tipados de uma Tabela Fixa), no MongoDB 7.0 um documento pode ser livre de Schema ("Schemaless"). Então, como descobrir as chaves de 1 milhão de Jsons diferentes salvos lá dentro em um servidor AWS? Através do Compass!

1. Aba Schema: No MongoDB Compass, abra a Collection e vá na aba Schema.
2. Analyze (Amostragem Rápida): Clique em Analyze Schema. O Compass irá varrer alguns milhares de BSONs originais e exibir um Gráfico de Barras indicando que:
   • 80% dos documentos possuem a chave data_criacao.
   • Os 20% restantes possuem um createdAt (Sujeira do legado NoSQL).
3. Tome a Decisão: Faça correções com $set ou indexe ambos se for um Legacy Bank.

?? PASSO 3: Identificando Lerdeza (.explain())

Mesmo com Índices, como provar se uma Query está utilizando ele de verdade (Sendo performática) ou lendo TUDO na marra (COLLSCAN)?

/* O EXPLAIN() MOSTRARÁ OS BASTIDORES DO MOTOR (PLANO DE EXECUÇÃO), TEMPO DE MILISEGUNDOS, ETC */
db.faturas.find({ filial: "SP" }).explain("executionStats");

O que Focar na Resposta MQL?

• executionTimeMillis: Tempo (Menos é Mais).
• totalDocsExamined: Quantos Documentos ele puxou para analisar um a um? Se deu 10.000 e ele retornou apenas 50 resultados reais, seu servidor está processando e apagando o excedente do Lixo na RAM por falta flagrante de Índice exato!

?? Dica de Infra: Se um índice consome 2 Gigabytes da Ram, o motor do MongoDB se sente à vontade para expulsar a sua base diária principal pro SwapHD limitando a velocidade. Analise e Crie índices apenas para os campos "Mais Buscados do WHERE e ORDER BY". Não construa Índices baseados na esperança do Cliente! ?????

?? CONSIDERAÇÕES FINAIS E DESAFIOS: UNIDADE VI (NOSQL)

O Engenheiro Poliglota não teme o paradigma Não-Relacional. Ele sabe que a escolha da tecnologia deve pender para o melhor benefício da Aplicação (App) da Empresa, e não para preferências literais de uma década. ?????

Objetivo: Formatar o domínio lógico recém-adquirido entre os paradigmas Relacionais (SQL) e Orientados a Documento (MQL), mesclando uma lista robusta de avaliações Múltipla Escolha e Desafios Práticos com resoluções explicativas.

? Lista de Exercícios: Questões Objetivas

1. Sob a visão estratégica do Teorema CAP, a Arquitetura do MongoDB prioriza qual das combinações em sua entrega de Distribuição Padrão? a) AP (Disponibilidade contínua acima de Consistência). b) AC (Consistência Forte em um Único Servidor). c) CP (Consistência Constante e Tolerância a Partição de Redes). d) CA (Alta Disponibilidade com Particionamento Relacional).

2. Na Arquitetura MongoDB (NoSQL de Documentos), qual o maior motivador para a Abordagem Didática de Embedding (Fusão de Documentos)? a) Fazer com que o campo ocupe o mínimo tamanho no disco rígido do servidor. b) Simular tabelas fixas Relacionais. c) Facilitar os $lookups no motor V8 de MapReduce. d) Reduzir a latência do aplicativo, centralizando a massa de metadados em uma única operação de Leitura (I/O).

3. Por que o Operador de Pipeline da Collection MongoDB inicia, em 99% das vezes Profissionais (Escala Analítica), com a Etapa $match na Função de Aggregations? a) Porque sem Ordenação Linear não existe Agrupamento. b) Para diminuir o peso final do tráfego JSON pela internet. c) Para cortar imediatamente da Memória RAM os documentos inúteis à pergunta, agilizando os cruzamentos das fases subsequentes. d) O $match apenas renomeia os campos internos cruzando referências.

4. Em Operações CRUD MQL, qual o comportamento imediato de proteção ao utilizar a função updateOne() (com os parâmetros corretos de filtro e $set), em comparação direta a um UPDATE equivalente no SQL Padrão? a) O MQL atualizará todos os documentos por padrão, igual ao SQL sem WHERE. b) O MQL travará na primeira correspondência encontrada, protegendo a base de adulterações acidentais em massa. c) O MQL criará uma nova coleção de backup temporária. d) O MQL deletará o documento caso o $set inclua campos nulos.

?? Lista de Desafios Práticos MongoDB 7.0

Desafio 1: Inserção Multi-nível (O CRUD Moderno)

Você foi encarregado de modelar a inserção de um Aluno na nova plataforma NoSQL do MEC. O Aluno possui RG, Nome e concluiu dois cursos de tecnologia em anos distintos.

• Tarefa: Crie o comando em MQL que insira este único documento na collection estudantes, garantindo que o histórico de cursos seja Embutido (Array de Objetos).

Desafio 2: Análise de Performance Visual

Após subir uma collection de Pedidos_Ecommerce com 1 milhão de vendas, o seu aplicativo web começa a congelar (Timeout) na tela de "Pedidos do Vendedor Z".

• Tarefa: Explique como utilizar as ferramentas embutidas (db.collection.explain() ou Compass) e quais métricas chaves ler para comprovar a falta de índices e resolver o estrangulamento.

Desafio 3: O Paradigma MQL Translator (Refatoração Analítica)

O sistema antigo em PostgreSQL possuía um relatório gerencial que avaliava o total arrecadado das vendas feitas fisicamente na loja ('POS'):

SELECT VENDEDOR_NOME, 
       SUM(VALOR_TOTAL) AS ARRECADACAO 
FROM VENDAS 
WHERE TIPO_VENDA = 'POS' 
GROUP BY VENDEDOR_NOME 
ORDER BY ARRECADACAO DESC;

• Tarefa: Reescreva esse comportamento mental do administrador para a abordagem de Aggregation Pipeline do MongoDB. Traduza linha a linha o sentido do motor de dados.

db.estudantes.insertOne({
    rg: "123.456.789",
    nome: "Ricardo Machado",
    historico_cursos: [
        { nome: "Arquitetura Python", ano_conclusao: 2024 },
        { nome: "SQL Transacional", ano_conclusao: 2025 }
    ]
});

db.vendas.aggregate([
    // 1ª Etapa (WHERE SQL): Corta tudo da RAM que NÃO vier do canal físico (POS).
    { $match: { tipo_venda: "POS" } },

    // 2ª Etapa (GROUP/SUM): Agrupa a massa sobrevivente criando o novo eixo virtual.
    { $group: {
        _id: "$vendedor_nome",                   // O EIXO Agrupador
        arrecadacao: { $sum: "$valor_total" }    // O Acumulador
    }},

    // 3ª Etapa (ORDER BY DESC): Ordena o novo objeto finalizado
    { $sort: { arrecadacao: -1 } }
]);