banco-de-dados
MongoDB
MongoDB em entrevista testa se você modela pelo padrão de acesso, não por reflexo relacional: quando embutir um subdocumento e quando referenciar, o limite de 16 MB por documento, como índices e o aggregation pipeline funcionam, e reconhecer os casos (transações multi-documento complexas, relatórios ad-hoc com muitos joins) em que um relacional seria a escolha certa.
Tópicos por senioridade
Perguntas mais cobradas
ver todas →- Médio
Embutir x referenciar num modelo de documento
Embuta o que é lido junto, pertence ao pai e não cresce sem limite. Referencie muitos-para-muitos, dado compartilhado/mutável, ou array que cresceria sem teto (limite de 16 MB).
- Difícil
Quando um relacional seria a escolha melhor que MongoDB
Relacional: muitos joins ad-hoc imprevisíveis, transações multi-tabela com invariantes fortes, BI/agregações arbitrárias, constraints declarativas, schema estável. Mongo: documento = objeto, acesso previsível, sharding.
- Médio
Índices no MongoDB e o índice composto
B-tree acelera match/range/sort, custa escrita. Índice composto serve só consultas pelo PREFIXO dos campos, na ordem (regra ESR). `explain()` mostra IXSCAN vs COLLSCAN.
- Difícil
Aggregation pipeline e por que a ordem dos estágios importa
Sequência de estágios, saída de um vira entrada do outro. `$match`/`$sort` no início podem usar índice (depois de `$group`/`$unwind` não); `$project` cedo reduz o que trafega; `$lookup` é caro, filtre antes.
- Difícil
Write concern e read preference
Write concern: quando o write é confirmado (`w:1` rápido/arriscado, `w:majority` durável/lento). Read preference: de onde ler (primary consistente, secondary distribui mas com lag). Escolha por operação.
- Médio
Antipadrões de modelagem no MongoDB
Arrays sem limite (rumo aos 16 MB), coleções pequenas demais, documentos inchados com campos raramente usados, índice pra tudo, e modelar relacional com `$lookup` em toda query.