A SoundByte lançou um aplicativo de streaming. Agora recebe 2 milhões de eventos por hora: cliques, pausas, buscas, comentários, avaliações com emojis e dados de localização com precisão de GPS. Cada usuário interage de um jeito diferente. O banco de dados relacional trava quando tenta armazenar isso.
Conjuntos de dados tão grandes, rápidos ou variados que as ferramentas tradicionais não conseguem processar. Definido pelos 5 Vs: Volume, Velocidade, Variedade, Veracidade e Valor.
80% dos dados do mundo não cabem em linhas e colunas fixas: textos, imagens, áudios, vídeos, posts de redes sociais, logs de eventos.
Conjunto de conceitos para tratar dados não estruturados com rapidez e confiabilidade. Surgiu da necessidade de ir além do que bancos relacionais conseguem atender.
Armazena dados em estruturas semelhantes a documentos JSON. Cada documento pode ter campos diferentes — sem esquema fixo. Principal representante: MongoDB.
JavaScript Object Notation — formato de texto leve para troca de dados, com pares chave-valor e suporte a listas e objetos aninhados. Base do modelo de documentos.
Uso do banco certo para a pergunta certa. SQL e NoSQL coexistem na mesma arquitetura — cada um otimizado para um tipo de consulta.
Campos que alguns têm e outros não: certificações, idiomas, publicações, projetos. Uma tabela com colunas fixas deixaria 80% das células vazias.
Cada categoria tem atributos completamente diferentes: um livro tem ISBN e autor; um tênis tem numeração e material; um DVD tem resolução e legendas.
Eventos sem estrutura fixa por usuário: um ouve, pausa, busca, cria playlist, compartilha, pula. Cada sessão é uma sequência única de ações.
Conceitos de Big Data (V's), bancos de dados NoSQL (Documento, Chave-Valor, Grafos) e limitações do modelo relacional.
Utilizando o MongoDB Atlas (plano gratuito), os alunos criarão uma coleção de documentos JSON simulando perfis de usuários com campos variáveis e praticarão consultas básicas.
Prompt sugerido: "Converta esta estrutura de tabelas de Clientes e Endereços SQL em um único documento JSON otimizado para leituras frequentes em um banco NoSQL como o MongoDB."
| Dados Estruturados | Dados Não Estruturados | |
|---|---|---|
| Características |
|
|
| Armazenados em |
|
|
| Gerados por |
|
|
| Aplicações típicas |
|
|
| Exemplos |
|
|
Armazena elementos de dados em estruturas semelhantes a documentos que codificam informações em formatos como JSON.
Cada documento pode ter campos completamente diferentes — sem esquema rígido definido previamente.
Usos comunsGerenciamento de conteúdo, monitoramento de aplicativos móveis e da Web, perfis de usuários, catálogos de produtos.
// Documento simples
{
"FirstName": "Bob",
"Address": "5 Oak St.",
"Hobby": "sailing"
}
// Documento com subdocumentos
{
"_id": "123",
"date": "10/10/2017",
"ship_status": "backordered",
"orderitems": [
{ "itemid": "4348", "price": 10.00 },
{ "itemid": "5648", "price": 15.00 }
]
}
Enfatiza as conexões entre os elementos de dados, armazenando "nós" relacionados em grafos para acelerar as consultas.
Ideal quando os relacionamentos entre os dados são tão importantes quanto os dados em si.
Usos comunsMecanismos de recomendação, aplicativos geoespaciais, redes sociais, detecção de fraudes.
// Exemplo de grafo
// Nós: Julie, Bob, Jim, Steve
// Nós: Rock Music, BMW, IBM, Fido
Julie ──Sister In-Law To──▶ Steve
│
Listens To
│
▼
Rock Music ◀── Listens To ── Bob
│
┌──────────┼──────┐
Married Drives Works
To │ For
│ BMW IBM
▼
Colleague Of
│
▼
Jim ── Has Pet ──▶ Fido
│
Works For
│
▼
IBM
Usa um modelo de dados simples que combina uma chave exclusiva e seu valor associado no armazenamento de elementos de dados.
Extremamente rápido para leituras e gravações — ideal para dados acessados com frequência.
Usos comunsArmazenamento de dados de fluxo de cliques, logs de aplicativos, cache de sessões, filas de mensagens.
// Estrutura Chave → Valor
user:1001 → { nome: "Alice",
plano: "premium" }
session:xyz → { userId: 1001,
expires: "2026-06-01",
token: "abc123" }
// Exemplo DynamoDB
// Partition Key + Sort Key
Product ID │ Type │ Attributes
───────────┼───────────┼──────────────────
1 │ Book ID │ Odyssey, Homer
2 │ Album ID │ 6 Partitas, Bach
3 │ Movie ID │ The Kid, Chaplin
Também chamados de bancos de dados em estilo de tabela. Armazenam dados em tabelas que podem ter um número muito grande de colunas — e cada linha pode ter colunas diferentes.
Projetados para escalar horizontalmente por clusters de servidores.
Usos comunsPesquisa na Internet e outros aplicativos da Web em grande escala, IoT, análise de séries temporais.
// Tabela UserProfile (Wide-column)
// Cada linha tem colunas diferentes!
Bob:
emailAddress: bob@example.com
gender: male
age: 35
Britney:
emailAddress: brit@example.com
gender: female
// sem campo "age"
Tori:
emailAddress: tori@example.com
country: Sweden
hairColor: Blue
// sem "gender" nem "age"
| Modelo | Estrutura do valor | Como se consulta | Quando usar |
|---|---|---|---|
| Documento | Documentos estruturados (JSON/BSON), com campos aninhados e arrays. | Consulta por chave e por campos internos; possível indexar atributos e realizar filtros ricos. | Perfis de usuário, catálogos, CMS, e-commerce, logs estruturados, qualquer cenário com esquema flexível. |
| Grafo | Nós (entidades) e arestas (relacionamentos), com propriedades em ambos. | Consulta focada em relacionamentos e travessias (ex.: "amigos de amigos", caminhos, recomendações). | Redes sociais, recomendação de produtos, fraud detection, sistemas com grafos densos de relacionamentos. |
| Chave-Valor | Par simples: chave → valor; o valor é tratado como blob/opaco. |
Acesso muito rápido apenas pela chave; não há consulta interna ao valor. | Sessões de usuário, cache, flags de configuração, carrinhos temporários, quando o acesso é sempre por ID. |
| Coluna Larga | Linhas com conjuntos de colunas muito esparsas, agrupadas em famílias; cada linha pode ter colunas diferentes. | Consulta por chave de linha e por faixa de colunas; otimizada para escanear muitas colunas em poucas linhas. | Logs de eventos, métricas de tempo (time series), big data analítico, histórico de atividades com muitas colunas esparsas. |
| Relacional (SQL) | Tabelas com linhas e colunas fixas, relacionadas por chaves estrangeiras. | Consulta com SQL: filtros, joins, agrupamentos, subquerys etc.; forte suporte a transações ACID. | Sistemas com dados bem estruturados e relacionamentos fixos (ERP, financeiro, inventário, CRM, aplicações transacionais críticas). |
Estudantes têm hobbies. Um estudante pode ter vários hobbies e um hobby pode ser compartilhado por vários estudantes (relação M:M). Veja como cada paradigma resolve este problema.
No modelo inicial, cada estudante só pode ter um hobby — porque a coluna hobby admite apenas um valor.
A solução relacional exige uma tabela intermediária Estudantes_Hobbies para modelar a relação M:M. Resultado: 4 tabelas, 3 JOINs para uma consulta simples.
CREATE TABLE `Disciplinas` (
`id` INT,
`nome_disciplina` VARCHAR(45),
PRIMARY KEY (`id`)
);
CREATE TABLE `Estudantes` (
`id` INT,
`nome` VARCHAR(45),
`disciplinas_id` INT,
PRIMARY KEY (`id`),
FOREIGN KEY (`disciplinas_id`)
REFERENCES `Disciplinas`(`id`)
);
CREATE TABLE `Hobbies` (
`id` INT,
`hobby` VARCHAR(45),
PRIMARY KEY (`id`)
);
CREATE TABLE `Estudantes_Hobbies` (
`estudantes_id` INT,
`hobbies_id` INT,
FOREIGN KEY (`hobbies_id`)
REFERENCES `Hobbies`(`id`),
FOREIGN KEY (`estudantes_id`)
REFERENCES `Estudantes`(`id`)
);
INSERT INTO Disciplinas (`id`, `nome_disciplina`)
VALUES
(1, 'eletromagnetismo'),
(2, 'cálculo diferencial');
INSERT INTO Estudantes (`id`, `nome`, `disciplinas_id`)
VALUES
(1, 'Emmanuel Kant', 1),
(2, 'Albert Einstein', 2);
INSERT INTO Hobbies (`id`, `hobby`)
VALUES
(1, 'jardinagem'), (2, 'leitura'),
(3, 'natação'), (4, 'corrida'),
(5, 'xadrez');
INSERT INTO Estudantes_Hobbies
(`estudantes_id`, `hobbies_id`)
VALUES
(1, 1), -- Kant: jardinagem
(2, 3), -- Einstein: natação
(2, 4); -- Einstein: corrida
No NoSQL, tudo em um único documento. Os hobbies são arrays embutidos, os campos são livres por documento — sem necessidade de tabelas intermediárias.
db.disciplina.insert_many([
{
"nome": "Emmanuel Kant",
"hobbies": "jardinagem",
"nome_disciplina": "eletromagnetismo"
},
{
"nome": "Albert Einstein",
"hobbies": {
"exercícios": ["natação", "corrida"],
"jogos": "xadrez"
},
"nome_disciplina": "cálculo diferencial",
"notas_provas": [100, 100, 100]
}
])
soundbyte e uma coleção chamada usuarios.
[
{
"nome": "Ana Souza",
"plano": "premium",
"generos_favoritos": ["pop", "mpb"],
"localizacao": {
"cidade": "São Paulo",
"lat": -23.5,
"lon": -46.6
},
"ultima_sessao": "2026-05-30T14:22:00",
"avaliacoes": ["😍", "🔥", "😴"]
},
{
"nome": "Bruno Mendes",
"plano": "gratuito",
"generos_favoritos": ["rock"],
"dispositivos": ["android", "smart_tv"],
"ultima_sessao": "2026-05-29T08:05:00"
},
{
"nome": "Carla Lima",
"plano": "premium",
"podcast_favorito": "Roda Viva",
"horas_ouvidas_mes": 42.5,
"historico_recente": [
{
"faixa": "Aquarela",
"artista": "Toquinho",
"duracao_s": 240
},
{
"faixa": "Garota de Ipanema",
"artista": "Tom Jobim",
"duracao_s": 186
}
]
}
]
{}
{ "plano": "premium" }
{ "generos_favoritos": "rock" }
{ "horas_ouvidas_mes": { "$gt": 40 } }
"notificacoes_ativas": true diretamente no JSON — sem precisar tocar nos documentos de plano gratuito.
{ "plano": "premium" }
{
"nome": "Ana Souza",
"plano": "premium",
"generos_favoritos": ["pop", "mpb"],
"localizacao": {
"cidade": "São Paulo",
"lat": -23.5,
"lon": -46.6
},
"ultima_sessao": "2026-05-30T14:22:00",
"avaliacoes": ["😍", "🔥", "😴"],
"notificacoes_ativas": true
}
{ "plano": "premium" }
{
"$set": {
"notificacoes_ativas": true
}
}
Faturamento por usuário, histórico de assinaturas, relatórios financeiros, dados transacionais. Respostas para o conselho e para o BI.
Perfis de usuários, catálogo de músicas, avaliações com emojis, histórico detalhado de reprodução. Esquema flexível por usuário.
Sessões ativas, cache de recomendações, fila de eventos em tempo real. Baixíssima latência para os 2 milhões de eventos por hora.
Engine de recomendação: "usuários que ouviram X também ouviram Y". Relacionamentos entre artistas, gêneros e ouvintes.