Bancos NoSQL e bancos vetoriais

Do zero

O banco relacional é uma planilha muito bem organizada: tabelas com colunas fixas, ligadas por chaves. Funciona para quase tudo, mas há casos em que outro formato serve melhor. NoSQL (“não só SQL”) é o nome dos bancos que guardam dados de outros jeitos:

• Documento: cada registro é uma ficha completa, em formato parecido com JSON, e fichas da mesma pasta podem ter campos diferentes. Exemplo: MongoDB.
• Chave-valor: um armário de escaninhos numerados: você guarda e pega pelo número (a chave), muito rápido. Exemplo: Redis, que trabalha com os dados na memória (por isso é tão rápido) e pode gravar cópias em disco para não perdê-los num reinício.
• Família de colunas (wide-column): tabelas gigantes, espalhadas por muitos servidores, em que cada linha pode ter colunas diferentes. Exemplo: Cassandra.
• Grafo: um mapa de pessoas e ligações: nós (empresas, sócios) e arestas (é sócio de, contratou). Exemplo: Neo4j.

E o banco vetorial é o arquivo da IA: guarda embeddings, listas de números que representam o significado de um texto (textos de sentido parecido viram listas parecidas), e encontra os mais parecidos com uma pergunta. É a peça de busca do RAG (geração aumentada por recuperação): o assistente primeiro busca os trechos relevantes e depois responde com base neles.

Frase para guardar: documento para fichas flexíveis, chave-valor para velocidade, colunas para volume distribuído, grafo para relações, vetorial para busca por significado.

Em 1 minuto

• NoSQL costuma trocar parte das garantias do relacional (esquema rígido, JOINs, ACID completo) por flexibilidade e escala horizontal (mais servidores, dados divididos em shards).
• Teorema CAP: num sistema distribuído, quando há partição de rede, é preciso escolher entre consistência (todos veem o mesmo dado) e disponibilidade (todos recebem resposta). A tolerância a partição é obrigatória. Em prova, costuma-se classificar o Cassandra como AP (prioriza disponibilidade) e o HBase e o MongoDB como CP (priorizam consistência).
• BASE (basicamente disponível, estado flexível, consistência eventual) é o contraponto ao ACID: os dados ficam consistentes com o tempo.
• Redis: dados na memória, com persistência opcional em disco (instantâneos RDB e log AOF) e expiração por chave (TTL). O valor pode ser texto ou uma estrutura (lista, conjunto, conjunto ordenado, hash, stream); por isso serve para cache, sessões, filas (listas) e rankings (conjuntos ordenados).
• Banco vetorial: busca por similaridade (cosseno, distância euclidiana), com índices aproximados (como o HNSW, um grafo de atalhos que acha vizinhos próximos sem comparar a pergunta com todos os vetores) para ser rápido em milhões de vetores. Exemplos: pgvector (extensão do PostgreSQL), Milvus, Qdrant, Weaviate, Pinecone.

Exemplo concreto: o mesmo assunto em quatro modelos

Documento (MongoDB): uma prestação de contas com tudo dentro, inclusive anexos variáveis.

{
  "_id": "pc-2026-123",
  "municipio": "Anápolis",
  "exercicio": 2026,
  "responsaveis": [{ "nome": "Ana Souza", "cargo": "Prefeita" }],
  "anexos": [{ "tipo": "balanco", "url": "…" }, { "tipo": "folha", "url": "…" }]
}

Chave-valor (Redis): a sessão do usuário, que expira em 30 minutos.

SET sessao:8f3a "matricula=1234;perfil=auditor" EX 1800
GET sessao:8f3a

Grafo (Neo4j): quem é sócio de quem, para achar empresas ligadas disputando a mesma licitação.

MATCH (a:Empresa)<-[:SOCIO_DE*1..3]-(p:Pessoa)-[:SOCIO_DE*1..3]->(b:Empresa),
      (a)-[:PARTICIPOU]->(l:Licitacao)<-[:PARTICIPOU]-(b)
WHERE a.cnpj < b.cnpj
RETURN a.nome, b.nome, p.nome, l.numero

O trecho *1..3 segue de um a três níveis de participação (a pessoa é sócia de uma empresa que é sócia de outra), e o WHERE evita listar o mesmo par duas vezes, como (a, b) e (b, a). No relacional, essa pergunta exigiria vários JOINs encadeados, um por nível; no grafo, as ligações são o próprio dado.

Vetorial: os pareceres do Tribunal viram embeddings; a pergunta “contratação emergencial de TI sem pesquisa de preços” encontra os pareceres de sentido parecido, mesmo que usem outras palavras.

Comparação: os modelos e quando usar

Como a FCC cobra

• Características e casos de uso de cada modelo.
• Teorema CAP e BASE × ACID.
• Escalabilidade horizontal e sharding.
• Banco vetorial, embeddings e busca por similaridade em RAG.

Pegadinhas

Explique com suas palavras

Explique a um auditor por que um banco de grafos ajuda a achar empresas ligadas por sócios em comum numa licitação, e o que um banco vetorial acrescenta a um assistente de IA.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

No banco de grafos, empresas e pessoas são pontos, e “é sócio de” e “participou da licitação” são linhas entre eles. Perguntar “há duas empresas na mesma licitação com um sócio em comum?” é seguir as linhas do mapa, o que o grafo faz de forma direta e rápida. Num banco de tabelas, seria preciso juntar várias tabelas, uma consulta pesada e difícil de escrever.

O banco vetorial guarda o significado dos textos como listas de números. Quando alguém pergunta algo ao assistente, a pergunta vira números também, e o banco devolve os pareceres de sentido mais parecido, mesmo com outras palavras. O assistente responde com base neles.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

Num caso de análise de fraudes em licitações, proponha um banco de grafos para as relações societárias; num caso de assistente de IA sobre as normas do Tribunal, um banco vetorial (por exemplo, pgvector no PostgreSQL já usado) para o RAG; e mantenha os dados transacionais (contratos, pagamentos) no relacional, que garante ACID.

Fontes da lição

• Edital nº 01/2026, Anexo II, Banco de Dados (fontes/edital-01-2026.txt).
• Pramod Sadalage e Martin Fowler, NoSQL Distilled (modelos NoSQL, consistência eventual).
• Eric Brewer, “Towards Robust Distributed Systems” (2000), origem do teorema CAP.
• pgvector, extensão de vetores do PostgreSQL