Banco de dados · tema 20 de 40
Relacional e NoSQL: ACID, BASE e a escolha real
35 min · 2 vídeos · 12 cards · 1 drill
Por que cai
É o tema em que se vê se a pessoa decide por moda ou por requisito. A banca pergunta 'quando você usaria NoSQL' esperando ouvir padrão de acesso, escala e tolerância a inconsistência temporária, não 'quando o dado não tem esquema'. Erro comum é explicar CAP errado, dizendo que se escolhe duas das três.
Pré-teste · 1 de 2
responda antes de verO que o teorema CAP afirma sobre um sistema distribuído?
Vídeo · português · 7 min
Em uma frase
A escolha não é entre "antigo" e "moderno": é entre impor correção a cada instante (ACID, relacional) e priorizar disponibilidade aceitando convergência (BASE, muitos NoSQL) — e ela se faz por requisito, às vezes por operação.
ACID, letra por letra
| Letra | Garante | Exemplo do que quebra sem ela |
|---|---|---|
| Atomicidade | Tudo ou nada | Débito sai e crédito não entra |
| Consistência | Estado válido antes e depois, pelas regras do banco | Pedido apontando para cliente que não existe |
| Isolamento | Transações simultâneas não veem estados intermediários | Dois saques leem o mesmo saldo e ambos passam |
| Durabilidade | O confirmado sobrevive a queda | Servidor cai e a confirmação some |
Não é ausência de garantia: é outra garantia. Para um contador de visualizações, convergir em segundos é irrelevante. Para uma transferência, é inaceitável. O critério é o dano que a janela de inconsistência causa.
O teorema CAP, sem a versão errada
A frase popular — "escolha duas entre consistência, disponibilidade e tolerância a partição" — engana. Em sistema distribuído, partição de rede acontece: cabo cai, zona fica inalcançável. Tolerância a partição não é escolha, é condição.
A escolha real aparece durante a partição:
- 1O sistema continua respondendo, arriscando devolver dado desatualizado (prioriza disponibilidade).
- 2Ou recusa a operação para não violar a consistência (prioriza consistência).
- 3Fora da partição, os dois caminhos podem oferecer consistência forte; a diferença é o comportamento no incidente.
As famílias, e o que cada uma resolve
| Família | Modelo | Padrão de acesso que ela serve |
|---|---|---|
| Chave-valor | Chave aponta para um valor opaco | Buscar por identificador conhecido, em escala e baixa latência |
| Documento | JSON com campos indexáveis | Entidade completa lida junta, com atributos que variam |
| Colunar largo | Linhas com colunas dinâmicas por família | Escrita altíssima com leitura por faixa de chave |
| Grafo | Nós e arestas | Percorrer relacionamentos a várias profundidades |
O erro de vocabulário mais comum: "NoSQL não tem esquema". O esquema existe; ele só não é imposto pelo banco. Passa a viver no código e nos dados — e, sem governança, vira esquema implícito e inconsistente, que é pior que o declarado.
Quando trocar de paradigma
Três condições juntas, não uma:
- Padrão de acesso conhecido e estável. Em NoSQL você modela a partir da consulta. Sem saber como vai ler, a escolha de chave é chute.
- Escala que justifica. Relacional escala bem verticalmente e com réplicas de leitura; nem todo problema de volume exige mudar de família.
- Tolerância a consistência eventual naquele dado específico.
O que se abre mão é o que o relacional impõe por você: junção eficiente, integridade referencial, transação entre entidades, consulta ad hoc que ninguém previu. Isso não desaparece — migra para a aplicação.
Como responder isso em voz alta
Comece pelo requisito, não pelo rótulo: o que precisa ser atômico, como o dado é lido, quanto de atraso causa dano. Dê um exemplo que atende e um que não atende. E formule o CAP pela partição — é o detalhe que separa quem entendeu de quem repetiu.
Se quiser outro ângulo1 vídeo
Como cai na sabatina
“Quando você usaria um banco NoSQL em vez de um relacional, e o que perderia?”
Erros comuns
- Dizer que o teorema CAP permite escolher duas das três propriedades. Em sistema distribuído, partição de rede acontece; a escolha real é entre consistência e disponibilidade quando ela ocorre.
- Achar que NoSQL significa 'sem esquema'. Significa que o esquema não é imposto pelo banco; ele continua existindo, e passa a ser responsabilidade da aplicação e da governança.
- Tratar BASE como ausência de garantias. É um conjunto diferente: disponibilidade em primeiro lugar e consistência que converge com o tempo, o que é adequado para muitos casos e inadequado para transferência de dinheiro.
- Escolher NoSQL por volume sem olhar o padrão de acesso. O ganho vem de conhecer a consulta antes de modelar; sem isso, o mesmo volume vira consulta cara e varredura.
- Esquecer que bancos relacionais escalam bem verticalmente e com réplicas de leitura. Nem todo problema de escala exige trocar de paradigma.
- Dizer que relacional não serve para JSON. Postgres e outros tratam JSON com índices há anos; a escolha é de padrão de acesso e escala, não de formato.
Flashcards
Card 1 de 12
0 certos · 0 a reverDrill
Relacional ou NoSQL?
Para cada requisito, diga qual paradigma a banca espera ouvir.
1.Transferência entre contas, com débito e crédito atômicos.
2.Carrinho de compras lido milhões de vezes por segundo, sempre pela chave do usuário.
3.Relatórios que cruzam sete tabelas de formas diferentes a cada pergunta.
4.Catálogo de produtos com atributos que variam por categoria.
5.Sessão de usuário que precisa responder em microssegundos e pode ser recriada.
Quiz · 1 de 2
Qual afirmação sobre ACID e BASE é mais defensável?
Explique para um gerente
Explique em um minuto para alguém de negócio o que significa 'o saldo pode ficar desatualizado por alguns segundos' e em que situações isso é aceitável.
Se travar numa palavra técnica, é sinal de que ainda não entendeu essa parte.
Prefiro falar em voz alta
00:00
Toque para gravar, ou responda em voz alta sem gravar
Perguntas de sabatina deste tema2
- · Quando você usaria um banco NoSQL em vez de um relacional, e o que estaria abrindo mão?
- · Explique o teorema CAP e o que ele significa na prática para uma equipe que opera um banco distribuído.