1.1 O processo relacional (que você provavelmente já tem no reflexo)

1. Identificar entidades e relacionamentos (ERD).
2. Normalizar (1FN, 2FN, 3FN) para eliminar redundância.
3. Criar tabelas e chaves estrangeiras.
4. Escrever as consultas depois — o otimizador e os JOINs se viram.

Isso funciona porque um banco relacional resolve qualquer consulta razoável sobre um schema normalizado, ao custo de JOINs em tempo de execução.

1.2 O processo NoSQL

1. Levantar todos os padrões de acesso da aplicação (as perguntas que ela fará), com frequência e volume estimados.
2. Projetar as estruturas de armazenamento para que cada padrão seja atendido com uma operação barata (idealmente uma leitura por chave, sem JOIN, sem varredura).
3. Aceitar duplicação de dados como preço da leitura rápida.
4. Só então nomear coleções/tabelas/chaves.

1.3 Por que a duplicação deixa de ser pecado

• Armazenamento é barato; latência e I/O não. Guardar o nome do cliente em 10 mil pedidos custa alguns MB; fazer JOIN em 10 mil pedidos a cada listagem custa CPU e tempo em toda requisição.
• Dado copiado ≠ dado que muda junto. Muita duplicação é de dado histórico (o preço no momento da compra) ou de projeção de exibição (o nome para a lista) — nesses casos, a cópia é a modelagem correta, não um efeito colateral.
• O custo real da duplicação aparece quando um dado mutável e compartilhado é copiado em muitos lugares (ex.: o nome do usuário em milhões de comentários). Aí entra a análise de "taxa de mudança × fan-out" (módulo 3).

2.1 A tabela de padrões de acesso

Antes de qualquer schema, liste cada operação de leitura e escrita que a aplicação faz. Para cada uma: o que entra (parâmetros), o que sai, com que frequência, em que volume, e qual latência é aceitável.

2.2 De onde tirar os padrões

• Telas e endpoints: cada tela do app e cada rota da API é um ou mais padrões de acesso. Percorra o Figma / a spec da API.
• Jobs e relatórios: exportações, e-mails agendados, reconciliações — costumam ser os padrões mais pesados e mais esquecidos.
• Eventos e integrações: webhooks, filas, sincronização com outros sistemas.
• Futuro previsível: só o que já está no roadmap. Não modele para requisitos imaginários — mas deixe explícito o que não está coberto.

2.3 Classificar cada padrão

3.1 As quatro variáveis

3.2 O problema do fan-out de atualização

Se você embute o nome do usuário em cada comentário e ele tem 2 milhões de comentários, trocar o nome vira 2 milhões de escritas. Duas saídas de mercado:

• Não duplicar o mutável: guardar só userId no comentário e resolver o nome na leitura (via $lookup pontual, cache, ou uma segunda consulta em lote por lista de ids).
• Duplicar e aceitar atualização assíncrona: um job/stream propaga a mudança em segundo plano, com a UI tolerando alguns minutos de inconsistência. Válido para nome de exibição; inválido para permissões.

3.3 O mapa por cardinalidade

4.1 A tabela de referência

4.2 Padrões de árvore — o mais errado na prática

// parentRef: fácil de escrever, caro para ler a subárvore inteira
{ _id: "c3", nome: "Tênis", parentId: "c1" }

// materialized path: leitura de subárvore e "breadcrumbs" viram 1 consulta por prefixo
{ _id: "c3", nome: "Tênis", path: ["c0", "c1"], pathStr: "/c0/c1/" }
// "toda a subárvore de c1": find({ path: "c1" })  — com índice em path

// array of ancestors + parentId: combina os dois; padrão recomendado pela MongoDB
{ _id: "c3", parentId: "c1", ancestors: ["c0", "c1"] }

Regra: se você lê subárvores inteiras com frequência, materialize o caminho; se só sobe um nível por vez, parentId basta; se a árvore quase nunca muda mas é lida o tempo todo, considere nested sets.

4.3 Combinar padrões é o normal

Um documento de post real pode usar Subset (comentários recentes) + Computed (contadores) + Extended Reference (autor) + Bucket (visualizações por dia) ao mesmo tempo. Os padrões não competem; compõem.

5.1 O modelo do DynamoDB em 90 segundos

• Uma tabela tem uma Partition Key (PK) e, opcionalmente, uma Sort Key (SK). Juntas formam a chave primária.
• Você só consulta eficientemente por: PK exata + (SK exata | faixa de SK | prefixo de SK). Nada de "WHERE qualquer coisa".
• Global Secondary Index (GSI): uma "cópia" da tabela com outra PK/SK, para atender outros padrões de acesso. Custa armazenamento e escrita.
• Sem JOIN. Sem varredura barata. O Scan existe e é o último recurso.

5.2 Por que uma tabela só

Cada Query do DynamoDB lê uma partição de uma tabela. Se as entidades relacionadas (um pedido e seus itens, um usuário e seus endereços) compartilham a mesma PK, uma única Query traz o "agregado" inteiro — o equivalente ao JOIN, pré-computado pela colocação física.

// Item collection: tudo do pedido #123 sob a mesma PK
PK              SK                    ...atributos
ORDER#123       META#123              status, total, criadoEm
ORDER#123       ITEM#001              sku, nome, preco, qtd
ORDER#123       ITEM#002              sku, nome, preco, qtd
ORDER#123       SHIPMENT#001          transportadora, rastreio

// "traga o pedido 123 inteiro": Query(PK = "ORDER#123")  → 1 request

5.3 Key overloading e GSIs

Os nomes PK/SK são genéricos de propósito: cada tipo de item os preenche com um prefixo diferente (USER#, ORDER#, PRODUCT#). Para atender "todos os pedidos de um usuário, por data", cria-se um GSI:

// GSI1 — inverte a visão para consultar por usuário
GSI1PK          GSI1SK
USER#u1         ORDER#2026-06-04#123
USER#u1         ORDER#2026-05-21#118

// Query(GSI1PK = "USER#u1", GSI1SK begins_with "ORDER#")  ordenado por data

• Sparse index: um GSI só indexa itens que têm os atributos da sua chave. Coloque GSI2PK só nos pedidos status = "aberto" → o GSI vira uma "fila" barata de pedidos abertos.
• Adjacency list para N:N: cada aresta é um item (PK = USER#u1, SK = GROUP#g9 e o inverso), permitindo "grupos do usuário" e "usuários do grupo" com Query nos dois sentidos.

6.1 O modelo físico

PRIMARY KEY ( (partition_key) , clustering_col_1, clustering_col_2 )
                  └─ define o NÓ         └─ define a ORDEM dentro da partição

• A partition key decide em qual nó (via consistent hashing) a linha vive. Toda consulta eficiente precisa fornecer a partition key inteira.
• As clustering columns ordenam fisicamente as linhas dentro da partição e permitem faixas e ORDER BY — só nelas, só na ordem declarada.
• Não há JOIN. Não há WHERE livre (usar ALLOW FILTERING em produção é quase sempre um erro).

6.2 A regra: uma tabela por padrão de consulta

Se a aplicação consulta "mensagens por canal, recentes primeiro" e "mensagens por autor", são duas tabelas, alimentadas pela mesma escrita (desnormalização deliberada):

CREATE TABLE mensagens_por_canal (
  canal_id uuid, bucket text, msg_id timeuuid, autor_id uuid, texto text,
  PRIMARY KEY ( (canal_id, bucket), msg_id )
) WITH CLUSTERING ORDER BY (msg_id DESC);

CREATE TABLE mensagens_por_autor (
  autor_id uuid, msg_id timeuuid, canal_id uuid, texto text,
  PRIMARY KEY ( autor_id, msg_id )
) WITH CLUSTERING ORDER BY (msg_id DESC);

A aplicação escreve nas duas (idealmente com BATCH logged para as duas linhas relacionadas, ou aceitando reconciliação). Storage duplicado é o preço; leitura de partição única é o prêmio.

6.3 Os inimigos: partições grandes, hot partitions e tombstones

• Partição grande: alvo < 100 MB e < ~100 mil linhas por partição. "Mensagens por canal" sem bucket cresce para sempre → adicione um componente de tempo à partition key ((canal_id, ano_mes) ou dia).
• Hot partition: uma partition key que concentra escrita (o canal viral, o "cliente do dia"). Mitigação: bucketing por sufixo, ou distribuir com um shard sintético ((canal_id, bucket, shard 0..9)).
• Tombstones: deletar em Cassandra escreve um marcador; ler uma partição cheia de tombstones é lento e pode estourar limites. Modele para não deletar — use TTL, ou partições que são descartadas inteiras (DROP de bucket antigo), em vez de DELETE linha a linha.

7.1 Nó, aresta ou propriedade?

• Vira nó o que tem identidade própria e é ponto de partida/chegada de consultas (Pessoa, Produto, Empresa, Cidade).
• Vira aresta o relacionamento que você percorre ((:Pessoa)-[:COMPROU]->(:Produto), (:Pessoa)-[:AMIGO_DE]->(:Pessoa)). Arestas têm tipo e direção e podem ter propriedades (desde, peso, quantidade).
• Vira propriedade o atributo que você lê junto com o nó mas nunca usa como ponto de partida de travessia (nome, e-mail, data de nascimento).

7.2 Direção e tipo de aresta

Neo4j armazena arestas dirigidas, mas a travessia pode ignorar a direção. Modele a direção que faz sentido semântico (SEGUE, GEROU, PERTENCE_A) e consulte com ou sem direção conforme a pergunta. Prefira tipos específicos (:ENVIOU_MENSAGEM, :CURTIU) a um genérico :REL {tipo:"..."} — o motor indexa por tipo de aresta.

7.3 Supernós o problema nº 1

Um nó com milhões de arestas (o país "Brasil" ligado a todas as pessoas; a hashtag viral) faz qualquer travessia que o toque explodir. Mitigações:

• Nós intermediários: em vez de (:Pessoa)-[:MORA_EM]->(:Pais), insira (:Pessoa)-[:MORA_EM]->(:Cidade)-[:EM]->(:Estado)-[:EM]->(:Pais).
• Particionar a aresta por tempo/categoria: [:CURTIU_EM_2026_06] em vez de um só [:CURTIU].
• Não modelar como grafo o que é agregação: "quantas curtidas o post tem" é um contador (Computed), não uma travessia.

7.4 Grafo de conhecimento (KG) e GraphRAG tema em alta

Um KG modela entidades e relações extraídas de texto/dados. Decisões de modelagem específicas: ontologia (quais tipos de nó e aresta são permitidos), resolução de entidades (o "Lula" do documento A e do documento B são o mesmo nó?), e proveniência (cada aresta guarda a fonte). O GraphRAG usa o KG para dar ao LLM contexto estruturado — a modelagem do KG é o que determina a qualidade das respostas. Aprofunde na apostila de IA Generativa & RAG e na de Grafos Aplicados.

8.1 Bucketing e a granularidade do documento

Um documento por leitura (milhões/dia) é ineficiente: overhead por documento, índices gigantes, varreduras longas. Um documento por (série, janela) agrupa: 1 doc por sensor por hora, com um array de { t, v } e agregados pré-calculados (min, max, soma, n). Escolha a janela pela consulta dominante: se o dashboard mostra por minuto, bucket de 1 h; se mostra por dia, bucket de 1 dia.

8.2 Rollups e retenção

• Rollup: materializar agregados por janela maior (hora → dia → mês) num job/stream, e servir os dashboards a partir deles. O dado bruto tem TTL curto; o rollup vive muito mais.
• Retenção em camadas: bruto por 7–30 dias (TTL), rollup horário por 1 ano, rollup diário para sempre. Modele cada camada como sua própria coleção/tabela.
• Descarte por partição, não por linha: em coluna larga, dropar a partição do mês antigo é O(1); DELETE linha a linha gera tombstones. Em documento, TTL index; em série temporal nativa, expireAfterSeconds.

8.3 Event sourcing e modelos append-only

Em vez de guardar o estado atual, guarde a sequência imutável de eventos (PedidoCriado, ItemAdicionado, PedidoPago); o estado é a soma dos eventos. Implicações de modelagem:

• O stream é a unidade: chave = { agregadoId }, ordenação por número de sequência. Toda leitura de um agregado lê seu stream inteiro (ou desde o último snapshot).
• Snapshots: a cada N eventos, materialize o estado para não reprocessar milhões de eventos na leitura.
• Projeções (read models): consumidores do stream constroem visões desnormalizadas, uma por tela — é o CQRS. Cada projeção é modelada com os padrões dos módulos 3–4.
• Versionamento de evento: o schema do evento evolui; consumidores precisam lidar com versões antigas para sempre (o passado é imutável).
• Dados que chegam atrasados (late-arriving): em analytics, um evento com timestamp de ontem chegando hoje obriga o rollup a ser reprocessável por janela, não só incremental.

9.1 "Schemaless" é mentira útil

O esquema não desaparece quando o banco não o impõe — ele migra para o código da aplicação, que passa a ser o único guardião da forma dos dados. Sem disciplina, uma coleção acumula 5 formatos diferentes do mesmo documento ao longo de anos, e cada leitura vira um campo minado de if (doc.x) ... else if (doc.y).

9.2 O padrão expand / contract (paralelo ao "parallel change")

1. Expand: a aplicação passa a escrever o formato novo e a ler os dois (novo e antigo). Nenhum dado foi tocado ainda; deploy reversível.
2. Migrate: backfill converte os documentos antigos em lotes (ver 9.3). Novas escritas já nascem no formato novo.
3. Contract: quando 100% está migrado e estável, remova o código que lê o formato antigo e, opcionalmente, ligue a validação de schema.

Cada passo é um deploy independente e reversível. Nunca "big bang".

9.3 Backfill que não derruba o banco

• Pagine por índice (_id ou uma chave indexada), lotes de alguns milhares, com limit. Nunca updateMany({}, ...) numa coleção gigante — segura locks e satura o I/O.
• Respire entre lotes (sleep de dezenas a centenas de ms) e observe métricas de latência/replication lag — reduza o ritmo se subirem.
• Retomável: persista o último _id processado; o job pode cair e continuar.
• Idempotente: filtrar por { schemaVersion: { $lt: 2 } } e escrever schemaVersion: 2 garante que reprocessar não estraga.
• Migração preguiçosa como complemento: ao ler/gravar um documento antigo, converta-o na hora. Cobre os "quentes" de graça; o backfill cobre os frios.

// esqueleto de backfill retomável
let ultimoId = carregarCheckpoint();
while (true) {
  const lote = await col.find({ _id: { $gt: ultimoId }, schemaVersion: { $lt: 2 } })
                        .sort({ _id: 1 }).limit(2000).toArray();
  if (lote.length === 0) break;
  for (const d of lote) await col.updateOne({ _id: d._id }, { $set: converter(d) });
  ultimoId = lote[lote.length - 1]._id;
  salvarCheckpoint(ultimoId);
  await sleep(50);
}

9.4 Validação e governança

• JSON Schema validation (MongoDB $jsonSchema, ou na aplicação com Zod/Pydantic/Mongoose): depois do contract, ligue validationLevel: "moderate" para impedir regressão ao formato antigo sem quebrar documentos legados intocados.
• Schema como código: versione a definição do schema junto com a aplicação; toda mudança passa por review.
• Registro de eventos/mensagens: em arquiteturas event-driven, um schema registry (Avro/Protobuf/JSON Schema) versiona os contratos entre produtores e consumidores e valida compatibilidade (backward/forward).
• Documentação viva: uma coleção com 8 tipos de item (single-table) ou polimórfica precisa de um documento de referência mantido — o schema implícito tem de estar explícito em algum lugar.

9.5 Modelagem para IA: metadados que o RAG precisa tema em alta

Guardar embeddings num campo é o começo. O que faz o retrieval funcionar é a modelagem dos metadados: tenantId e ACLs para filtro de segurança antes da busca vetorial; fonte, página, secao para citação; dataDoc e versao para recência; chunkId/parentId para reconstruir o contexto ao redor do trecho. Um chunk é um documento; o design dele determina a qualidade da resposta. Detalhes na apostila de RAG.

10.1 Onde a modelagem aparece nas vagas

10.2 Roadmap de estudo (4 semanas)

• Semana 1 — módulos 1–2: pegue um app que você conhece e escreva a tabela de padrões de acesso completa. Sem schema ainda.
• Semana 2 — módulos 3–4: modele esse app em documento (MongoDB), aplicando e nomeando os padrões. Rode local, popule, meça.
• Semana 3 — módulo 5: remodele o mesmo app como single-table no DynamoDB (DynamoDB Local + NoSQL Workbench). Compare.
• Semana 4 — módulos 6–9: modele a parte de "eventos/telemetria" em Cassandra; faça uma migração expand/contract de propósito e documente.

10.3 Banco de perguntas (com a resposta que aprova)

10.4 Projetos de portfólio

1. "O mesmo app, três modelagens": um domínio (ex.: reservas de restaurante) modelado em MongoDB (documento + padrões), DynamoDB (single-table) e Cassandra (tabela-por-consulta), com um README comparando padrões de acesso atendidos, custo de escrita e trade-offs. Raro e muito convincente.
2. Migração documentada: um repo que parte de um schema "ingênuo", tem um branch com o backfill expand/contract completo (job retomável, testes, métricas antes/depois) e um post-mortem.
3. Modelagem de KG para RAG: extrair entidades/relações de um corpus, definir ontologia e resolução de entidades, e comparar RAG puro vs GraphRAG em algumas perguntas.

10.5 Fontes

• Livros: The DynamoDB Book (Alex DeBrie) — a bíblia de single-table e access patterns; Designing Data-Intensive Applications (Kleppmann) para a base; o MongoDB Blog (série "Building with Patterns") para o catálogo do módulo 4.
• Ferramentas de prática: DynamoDB Local + NoSQL Workbench; MongoDB local + Compass; um cluster Cassandra/Scylla em Docker.
• Apostilas irmãs: NoSQL (famílias e teoria distribuída), MongoDB a fundo, Engenharia de Dados (CDC, lakehouse), Grafos Aplicados.