NoSQL Essencial

A pergunta nunca é "SQL ou NoSQL?" — é "quais garantias este dado exige e quais posso relaxar?"

Um checklist dos fundamentos: as famílias de banco e para que serve cada uma, modelagem a partir das consultas, o vocabulário de CAP/BASE/quóruns que cai em entrevista, e a operação. Cada tópico em poucas linhas, com as armadilhas. Se algo soar novo, o ponteiro → aprofunde em… indica a apostila completa.

10 seções + recapmatriz de decisãoCAP · BASE · quórunsauto-checagem por seçãocross-references

COMO USAR

O formato "Essencial"

Denso, sem rodeios, feito para ser varrido antes de uma entrevista ou de uma decisão de arquitetura.

Leia rápido. Se você já domina o tópico, siga. Se travou, é sinal de estudar/praticar.
→ aprofunde em…: NoSQL — do básico ao muito avançado, MongoDB a fundo, Modelagem de Dados NoSQL, Caching Distribuído & Redis Avançado, Engenharia de Dados, IA Generativa & RAG.
NoSQL não é "SQL evoluído". É um conjunto de trade-offs: cada família abre mão de algo (JOIN, esquema rígido, consistência forte) por escala, flexibilidade ou um modelo de dados especializado.
Caixas ⚠️: o que dá inconsistência silenciosa, perda de dados ou sistema lento. Checklist final para marcar.

O que é NoSQL e quando (não) usar

A decisão vem antes da tecnologia. → aprofunde em NoSQL, Módulo 1

Dimensão	Relacional	NoSQL (o que muda)
Esquema	definido antes (schema-on-write); migração para alterar	flexível (schema-on-read); o esquema migra para o código
Escala	vertical por padrão; sharding é difícil	horizontal por design
Relacionamentos	JOIN no tempo da consulta	em geral sem JOIN; dado pré-agrupado por padrão de leitura
Consistência	ACID forte por padrão	frequentemente BASE / eventual configurável
Modelo	um: tabelas	quatro: documento, chave-valor, coluna larga, grafo

💡 Regra prática de mercado

Comece com Postgres + Redis. Adicione um NoSQL especializado só quando a dor for real e medida (latência, escala de escrita, modelo de consulta que o relacional não atende). "Boring technology wins" — 99% dos sistemas cabem num servidor relacional.

Sinais de que NoSQL ajuda: padrão de acesso conhecido e simples; escala além de um servidor; esquema heterogêneo/volátil; dado naturalmente documento/grafo/série temporal; tolerância a consistência eventual.
Sinais de que relacional é melhor: consultas ad-hoc imprevisíveis; transações multi-entidade (financeiro, estoque); integridade referencial como requisito; dados que cabem num servidor.

✔️ Auto-checagem

Cite três trade-offs concretos de NoSQL vs relacional. Qual a resposta que reprova em "quando usar NoSQL?" (dizer só "quando precisa de performance"). Qual stack começar por padrão?

As 4 famílias + as especializadas

Reconhecer o modelo mental e o caso de uso ideal de cada uma. → aprofunde em NoSQL, Módulo 2

Família	Modelo mental	Campeões	Ideal para
Documento	objeto JSON/BSON completo, aninhado	MongoDB, Couchbase, Firestore	catálogos, perfis, CMS, apps web
Chave-valor	dicionário gigante distribuído; só acesso por chave	Redis, DynamoDB, Memcached, Valkey	cache, sessão, fila leve, contador, rate limit, ranking
Coluna larga	linha por chave de partição, milhares de colunas ordenadas	Cassandra, ScyllaDB, Bigtable, HBase	séries temporais, IoT, mensagens, escrita massiva
Grafo	nós e arestas como cidadãos de 1ª classe; travessia barata	Neo4j, Neptune, Memgraph	fraude, recomendação, redes, grafo de conhecimento

As especializadas que o mercado adora

Busca: Elasticsearch/OpenSearch — busca textual com relevância, facetas, logs e observabilidade.
Série temporal: InfluxDB, TimescaleDB, Prometheus — métricas, sensores, janelas de tempo.
Vetorial: pgvector, Qdrant, Weaviate, Pinecone, Milvus — busca por similaridade de embeddings; base de RAG. → aprofunde em IA Generativa & RAG

💡 Qual aprender primeiro

1º MongoDB (porta de entrada do modelo de documento, líder em vagas). 2º Redis (aparece em quase toda arquitetura de produção). Depois, conforme a trilha: Cassandra/DynamoDB + Elasticsearch (dados/DevOps) ou Neo4j + vetoriais (fraude/recomendação/IA).

✔️ Auto-checagem

Para cada caso, a família: (a) token de sessão; (b) autocomplete de busca; (c) 100 mil leituras de sensor por segundo; (d) "quem comprou X também comprou Y". Qual banco vetorial roda dentro do Postgres?

Modelagem query-first

O erro nº 1 é modelar NoSQL como se fosse relacional. → aprofunde em Modelagem de Dados NoSQL · MongoDB, Módulos 2 e 5

💡 Conceito-chave

No relacional você modela a partir dos dados e as consultas se adaptam. No NoSQL você modela a partir das consultas ("quais perguntas a aplicação fará?") e os dados se adaptam — aceitando duplicação.

Embedding (aninhar): quando os dados são lidos juntos quase sempre e a relação é 1:1 ou 1:poucos (limite conhecido). Uma leitura resolve.
Referencing (guardar o id do outro): quando o lado "muitos" cresce sem limite, ou o dado é acessado/atualizado de forma independente, ou é compartilhado por muitos.
Extended Reference: duplicar 2–3 campos estáveis do referenciado para evitar o segundo fetch (nome do cliente no pedido). Preço e nome do produto dentro do item do pedido são histórico congelado — a duplicação é correta.

Padrões pelo nome (caem em entrevista)

Padrão	Resolve
Subset	array 1:muitos grande — embute os N recentes, referencia o resto
Bucket	séries temporais — 1 documento agrupa uma janela fixa
Computed	agregado caro de recalcular — pré-calcula na escrita (`$inc`)
Schema Versioning	migrar coleção enorme — campo `schemaVersion` + migração preguiçosa/backfill
Outlier	99% pequenos, 1% gigante ("usuário Taylor Swift") — trata o outlier à parte

⚠️ Array sem limite

Embutir "todos os comentários do post" funciona no protótipo e explode em produção (limite de tamanho do documento; cada append reescreve o array). Se o array pode crescer indefinidamente, não pode ser embutido.

✔️ Auto-checagem

Quando embedding, quando referencing? Por que duplicar o preço dentro do item do pedido não é um "erro de normalização"? Nomeie o padrão para: contador de curtidas; IoT a 10k/s; migração gradual de schema.

CAP, BASE e consistência

O vocabulário de sistemas distribuídos — favorito de entrevista pleno/sênior. → aprofunde em NoSQL, Módulo 3

CAP: durante uma partição de rede, escolha entre Consistência (toda leitura vê a escrita mais recente) e Availability (toda requisição responde). P (tolerância a partição) não é opcional num sistema distribuído real.
CP na partição: recusa/atrasa para nunca devolver dado velho — MongoDB (padrão), HBase, etcd, Zookeeper. Bom para saldo, estoque, config.
AP na partição: sempre responde, aceitando dado que converge depois — Cassandra, DynamoDB, Riak. Bom para feed, carrinho, curtidas, telemetria.
BASE: Basically Available, Soft state, Eventually consistent. "Consistência eventual" = se as escritas param, as réplicas convergem.
Níveis intermediários (impressionam): read-your-own-writes, monotonic reads, causal consistency.
PACELC: na ausência de partição (Else), o trade-off é Latência vs Consistência.

⚠️ Pegadinha

Chamar um banco de "CA" em contexto distribuído costuma ser errado. E o rótulo CP/AP é espectro, não prisão: Cassandra ajusta consistência por operação (quóruns, seção 05). CAP descreve o comportamento durante a falha.

✔️ Auto-checagem

Explique CAP em uma frase com exemplo. MongoDB e Cassandra: CP ou AP, e por quê? O que é consistência eventual e quando é aceitável? O que PACELC acrescenta ao CAP?

Replicação, sharding e quóruns

Como o dado fica disponível e como o cluster escala. → aprofunde em NoSQL, Módulo 3 · MongoDB, Módulos 6–7

Replicação = mesma cópia em vários nós → disponibilidade e leitura escalável. Líder-seguidor (MongoDB: escreve no primário) ou sem líder (Cassandra/Dynamo: qualquer nó aceita escrita).
Particionamento (sharding) = dividir o dataset entre nós, cada um dono de uma fatia → escrita e armazenamento escaláveis. A shard key é a decisão de design mais importante.
Boa shard key: alta cardinalidade + distribuição uniforme + presente nas consultas frequentes. Chave monotônica (timestamp, id sequencial) → hot shard na escrita.
Consistent hashing: nós e chaves num "anel"; adicionar/remover 1 nó move só ~1/N das chaves (vs hash % N, que remaneja quase tudo). Usado por Cassandra, DynamoDB, Redis Cluster (via hash slots).
Quóruns (sem líder, N réplicas): W + R > N → leitura e escrita se sobrepõem em ≥ 1 réplica → leitura forte. Ex. N=3: W=2,R=2 equilíbrio; W=1,R=1 rápido e eventual.
LSM-Tree (Cassandra, RocksDB, WiredTiger): escrita vira log sequencial + memtable → SSTable imutável → compaction em segundo plano. Explica por que Cassandra devora escritas.

✔️ Auto-checagem

Replicação vs particionamento — o que cada um escala? Três propriedades de uma boa shard key. Por que hash(chave) % N é ruim ao adicionar um nó? Com N=5, W=3, R=3 a leitura é forte? Quantos nós podem cair sem impedir escrita?

Índices e performance

O que quase todo NoSQL compartilha. → aprofunde em MongoDB, Módulo 4

Índice composto — ordem importa (regra ESR): igualdade primeiro, depois ordenação, depois faixa.
Leia o plano de execução (explain): quer varredura de índice, não da coleção; docsExaminados ≈ retornados. Covered query (tudo no índice) é a mais rápida.
Todo índice custa RAM e torna a escrita mais lenta. Indexe consultas reais e frequentes; remova índices sem uso.
Working set na RAM: se os dados + índices quentes não cabem em memória, a latência despenca. Dimensione por working set, não por dataset total.
Índice parcial/esparso quando só uma fatia dos documentos é consultada (ex.: só pedidos "abertos").
TTL index apaga documentos por idade automaticamente (sessões, eventos efêmeros).

⚠️ $regex / LIKE sem prefixo âncora

/ana/ varre tudo; /^ana/ (prefixo) usa índice. Busca textual de verdade → índice de texto ou um motor de busca (Atlas Search / Elasticsearch).

✔️ Auto-checagem

O que a regra ESR ordena e por quê? O que é uma covered query? Por que "adicionar índice por via das dúvidas" é ruim? O que é working set?

Poliglota e sincronização

Com vários bancos, o problema vira mantê-los coerentes. → aprofunde em NoSQL, Módulo 9 · Engenharia de Dados

Persistência poliglota: o banco certo para cada dado, aceitando o custo de operar vários (deploy, backup, monitoramento, expertise). Só adicione mais um banco com ganho mensurável.
CDC (Change Data Capture): ler o log de transações do banco fonte (WAL do Postgres, oplog do Mongo) e publicar cada mudança num stream (Debezium + Kafka). Consumidores (busca, cache, vetorial) se atualizam a partir dele — eventual, mas garantido.
Transactional Outbox: gravar o evento numa tabela outbox na mesma transação do dado; um processo publica a outbox. Atomicidade sem acesso ao log do banco.
CQRS: separar o modelo de escrita (normalizado) dos modelos de leitura (um por tela, desnormalizados), sincronizados por eventos. É o "query-driven design" em escala arquitetural.

⚠️ Dual-write

Escrever no Postgres e depois no Elasticsearch direto no código da aplicação: se a segunda escrita falhar (deploy, timeout, crash), os sistemas divergem em silêncio e não há transação que os una. Um dos bugs de consistência mais comuns em produção. Use CDC ou outbox.

✔️ Auto-checagem

Por que dual-write é um antipadrão? O que CDC e outbox resolvem, e como diferem? O que CQRS separa e como sincroniza?

Operação: segurança e backup

O que derruba empresas — e é fácil de evitar. → aprofunde em NoSQL, Módulo 9 · Segurança de Aplicações de IA

Nunca exposto: a praga histórica do NoSQL são instâncias Mongo/Redis/Elasticsearch abertas na internet sem auth (milhares de vazamentos e ataques de resgate). Bind em rede privada, auth sempre ligada, TLS, IP allowlist.
NoSQL injection existe: em Node+Mongo, {"senha": {"$ne": null}} passa num login mal escrito. Valide tipos (rejeite objeto onde se espera string); use ODM com schema.
Menor privilégio: um usuário de banco por serviço, só com as ações necessárias. Criptografia at-rest; campos sensíveis com field-level encryption (o servidor nunca vê o claro).
Backup ≠ replicação: a réplica propaga o DROP/deleteMany na hora. Tenha backup com point-in-time recovery testado — "backup que nunca foi restaurado não é backup".
Métricas que você monitora: replication lag; cache hit ratio; consultas com varredura completa; conexões perto do limite (connection storm); p95/p99 de latência (nunca média); saturação de I/O.

✔️ Auto-checagem

Qual a causa dos grandes vazamentos históricos de NoSQL? Como se defende de NoSQL injection? Por que a réplica não substitui o backup? Cite quatro métricas de um cluster em produção.

Matriz de decisão

Da necessidade ao banco, sem hype. → aprofunde em NoSQL, Módulos 2 e 9

Necessidade	Escolha típica	Por quê
Cache, sessão, rate limit, ranking, lock	Redis / Valkey	chave-valor em memória, estruturas ricas, TTL, microssegundos
Catálogo, perfis, CMS, app web com dado aninhado	MongoDB (ou Postgres + JSONB)	documento flexível, modela como a app enxerga
Escrita massiva, séries temporais, mensagens, IoT	Cassandra / ScyllaDB	coluna larga, sem líder, LSM-Tree, escala linear de escrita
Backend AWS-first, chave conhecida, escala previsível	DynamoDB	gerenciado, latência estável, integra com o ecossistema AWS
Busca textual, facetas, logs/observabilidade	Elasticsearch / OpenSearch (ou Atlas Search)	Lucene: relevância, análise linguística, agregações
Fraude, recomendação, "amigos dos amigos", dependências	Neo4j / Neptune	relacionamento é 1ª classe; travessia barata por salto
Busca semântica, RAG, memória de agente	pgvector / Qdrant / Weaviate	kNN aproximado sobre embeddings; filtro híbrido
Transação multi-entidade, integridade referencial, relatórios ad-hoc	Relacional (Postgres)	ACID, JOIN, o dataset cabe num servidor

💡 Resposta de system design

E-commerce grande, arquitetura poliglota típica: catálogo em MongoDB ou Postgres; busca em Elasticsearch (via CDC); carrinho/sessão em Redis (TTL); pedidos/pagamentos em Postgres (ACID inegociável); recomendação em Neo4j ou vetorial; logs em OpenSearch. Cada escolha justificada pelos trade-offs das seções 01–08.

✔️ Auto-checagem

Sem olhar a tabela: banco para cache; para escrita massiva de telemetria; para busca textual com facetas; para recomendação por grafo; para RAG. Quando a resposta certa é "relacional"?

O resto do essencial

Itens que aparecem sempre.

Tópico	O mínimo
Idempotência	escrita que pode ser repetida sem efeito extra (upsert por chave de negócio). Pré-requisito para retry seguro.
Retry storm	retry sem exponential backoff + jitter transforma um soluço em avalanche que derruba o banco.
Hot key / hot partition	inimigo nº 1 em escala. Mitigação: salting da chave (sufixo aleatório), cache local na frente do Redis.
Cache: cache-aside	app lê o cache; se falta, busca no banco e popula. O padrão mais comum. → Caching & Redis
Cache stampede	chaves com TTL uniforme expiram juntas e a recomputação satura o banco. Prevenção: TTL com jitter, lock de recomputação (single-flight), warm-up pós-deploy.
Consistência de cache	invalide na escrita (delete a chave); TTL curto como rede de segurança; nunca confie só em "atualizar o cache junto".
Connection pooling	uma instância de client por processo; em serverless, pool pequeno + client reaproveitado entre invocações.
Percentis	meça p95/p99, nunca média — a média esconde desastres.
Dinheiro	decimal exato (Decimal128) ou centavos em inteiro — nunca float.

✔️ Auto-checagem

Por que idempotência é pré-requisito de retry? O que evita um retry storm? O que é cache-aside e cache stampede? Como se previne o stampede? Por que p99 e não média?

RECAP

Checklist final do NoSQL

Se você marca todos, tem o básico conceitual e de decisão. Onde travar, volte à seção.

✅ Eu sei…

que NoSQL é um conjunto de trade-offs, não uma evolução do SQL; e começar com Postgres + Redis
três diferenças concretas relacional × NoSQL (esquema, escala, relacionamentos, consistência, modelo)
as 4 famílias e o caso de uso ideal de cada uma; e as especializadas (busca, série temporal, vetorial)
modelar a partir das consultas; embedding vs referencing por cardinalidade + acesso
os padrões pelo nome: subset, bucket, computed, extended reference, schema versioning, outlier
o antipadrão do array sem limite e por que duplicar dado histórico é correto
CAP (a escolha só existe durante a partição); CP vs AP com exemplos; MongoDB CP, Cassandra AP
BASE e consistência eventual; read-your-writes, monotonic reads, causal; PACELC
replicação vs particionamento; três propriedades da shard key; o problema da chave monotônica
consistent hashing e o problema que resolve; quóruns W + R > N; ideia do LSM-Tree
índice composto pela regra ESR; ler o explain; covered query; working set na RAM
índice parcial/esparso e TTL; por que regex sem prefixo não usa índice
persistência poliglota com critério; CDC e outbox; o antipadrão dual-write; CQRS
nunca expor a instância; NoSQL injection; menor privilégio; field-level encryption
backup ≠ replicação; PITR testado; métricas (lag, cache hit ratio, COLLSCAN, conexões, p99)
a matriz de decisão necessidade → banco, e quando a resposta é "relacional"
idempotência, retry com backoff+jitter, hot key/salting, cache-aside, cache stampede, pooling, percentis

Aprofundamento: NoSQL — do básico ao muito avançado · MongoDB a fundo · Modelagem de Dados NoSQL · Caching Distribuído & Redis Avançado · Engenharia de Dados.