NoSQL: BASE, consistência eventual; chave-valor, documentos, colunar, grafos; CAP

A ideia que organiza o assunto

NoSQL não é um banco de dados; são quatro famílias com estruturas de armazenamento diferentes, unidas por duas escolhas comuns: escalar horizontalmente (mais máquinas, não máquinas maiores) e não exigir esquema declarado antes da escrita.

Isso é o que o corpus cobra. Não há um conceito central de que tudo decorra — há quatro estruturas, e a pergunta quase sempre é qual delas está sendo descrita:

família	unidade	como se consulta
chave-valor	par chave → valor opaco	put/get pela chave, e só
documento	documento JSON/BSON numa coleção	por qualquer campo, com índice
colunar (família de colunas)	linha com famílias de colunas	pela chave de linha e pela família
grafo	nó e aresta, ambos com propriedades	percorrendo arestas

A segunda ideia, que decide quase tantos itens quanto a primeira: schemaless não significa “sem estrutura”. O esquema existe; ele é implícito e validado na leitura (schema-on-read), não declarado antes da escrita. A validação foi deslocada, não suprimida.

Por que se usa (e o que custa)

O ganho é escala horizontal e tolerância a dados heterogêneos. O custo é que esse ganho decresce à medida que o modelo fica mais relacionado: quando os dados têm muitas ligações entre si, o trabalho que o banco relacional faz com junções reaparece na aplicação. Um item do corpus é exatamente isso — o NoSQL é em geral mais otimizado, mas a vantagem diminui com a complexidade do modelo.

O outro custo é de consistência. BASE flexibiliza ACID: em vez de garantir consistência a cada operação, promete convergência — consistência eventual. Quando a replicação é assíncrona, isso deixa de ser escolha e passa a ser consequência: não há como replicar de forma assíncrona e prometer leitura sempre atualizada.

Como funciona

Chave-valor. Todos os registros vivem num mesmo espaço de nomes e o valor é opaco para o banco. Daí a limitação que o corpus cobra duas vezes: não se consulta por valor, nem se cruzam dois armazenamentos. É a família menos indicada quando a consulta precisa olhar dentro do dado.

Documento. JSON ou BSON, agrupados em coleções. O mapeamento com o mundo relacional é fixo e é cobrado literalmente: coleção ≈ tabela, documento ≈ linha. Documentos aninhados trocam redundância por leitura em uma só ida ao banco — é a razão de existir do modelo. A ausência de esquema não impede indexação: índices são criados sobre os campos que existirem.

Grafo. Nó e aresta são cidadãos de primeira classe, e a aresta é dado, com direção e propriedades. O que dá desempenho é a adjacência sem índice: cada nó guarda referência direta aos vizinhos, de modo que percorrer não custa a junção que custaria no relacional. Em Cypher, a seta do padrão define o sentido: (a)-[r:FALA_COM]->(b) é de a para b.

Colunar. No Cassandra a consistência é ajustável (tunable): o cliente escolhe por operação quantas réplicas precisam responder. No HBase a região é a unidade básica de distribuição.

Elasticsearch, que é o produto mais cobrado do tópico. Motor de busca distribuído construído sobre o Lucene, com API REST e documentos JSON — não é uma ferramenta SQL. Indexa todos os campos, cada um com estrutura própria. Um índice divide-se em shards, e cada shard é um índice Lucene autônomo e completo. O Kibana é a camada de visualização.

O que decide os itens

par que a banca troca	o que é
documento × tabela/coluna	documento vive em coleção, não em tabela
coleção × documento	coleção ≈ tabela; documento ≈ linha
nó/aresta × tabela/linha	grafo não tem tabela
grafo × relacional	modelagem em grafos não segue o princípio das tabelas
delete() × drop() no MongoDB	remove documentos × remove a coleção
JSON × XML	pares chave:valor × elementos marcados
H2 × NoSQL	H2 é relacional embarcado em Java
Elasticsearch × SQL	REST/JSON sobre Lucene
ingestão em lote × em tempo real	acumulada × contínua

E três afirmações que o corpus trata como falsas sempre que aparecem:

• “NoSQL é imune a injeção.” Injeção é falha de construção de consulta na aplicação; ocorre em NoSQL também.
• “NoSQL não permite atualização.” O modelo de dados não restringe as operações de escrita.
• “NoSQL dispensa qualquer modelo lógico.” Schema-on-read desloca a validação para a leitura; não a elimina.

Como a CEBRASPE derruba você aqui

Medido sobre os 54 itens do tópico: 25 Certo, 29 Errado.

A estrutura de uma família descrita com o vocabulário de outra — 8 dos 29 itens errados (28%), o movimento mais frequente. O documento guardado “em tabelas e colunas”; o objeto do grafo representado “por uma tabela”; a modelagem em grafos seguindo “o mesmo princípio das tabelas relacionais”; o documento declarado “equivalente a uma tabela”. A defesa é sempre a mesma: identifique a unidade de armazenamento antes de aceitar o nome — se a frase fala em linha e coluna, ela não está falando de documento nem de grafo.

A generalização que apaga a ressalva — 7 de 29 (24%). “São imunes a ataques de injeção”, “não permitem a atualização de seus dados”, “a inexistência de esquema impossibilita a indexação”, “dispensa a definição de qualquer modelo lógico”. Note o padrão: todas atribuem ao modelo de dados uma propriedade que pertence à aplicação ou à implementação.

O produto trocado — 4 de 29. H2 apresentado como chave-valor e depois como banco de documentos; Elasticsearch como ferramenta SQL; PDI como ferramenta de visualização. Meia dúzia de itens do tópico são, na prática, perguntas de catálogo: o candidato precisa saber o que cada produto é, não como funciona.

A propriedade levada ao absoluto — e o que a salva. “A consistência forte é garantida” no Cassandra é errado porque a consistência lá é ajustável; “a replicação garante consistência” é errado porque a replicação é assíncrona. Em ambos, o absoluto é do examinador. Quando o absoluto é da definição — “todos os registros fazem parte da mesma coleção” no chave-valor, “indexa todos os dados em cada campo” no Elasticsearch — o item é Certo.

O que o título promete e o corpus não cobra. CAP aparece em 1 dos 54 itens; consistência eventual como expressão, em nenhum — o conceito é cobrado, mas pela via da replicação assíncrona e do BASE. Colunar não aparece como palavra: as duas famílias de colunas que caem vêm pelos produtos, Cassandra e HBase. E a metade do tópico é produto, não teoria: Elasticsearch sozinho responde por 6 itens, mais que CAP, BASE e chave-valor somados.

Erros clássicos

• Traduzir documento por “tabela e coluna”. Coleção é que faz as vezes de tabela; documento faz as vezes de linha.
• Achar que grafo é tabela com ponteiros. Nó e aresta, e a aresta carrega propriedades e direção.
• Dizer que a falta de esquema impede índice. Índices são criados sobre os campos existentes; o esquema é que não é declarado antes.
• Ler schemaless como “sem estrutura”. É esquema flexível, validado na leitura.
• Culpar o modelo pela injeção. A falha é de quem monta a consulta.
• Prometer consistência forte com replicação assíncrona. Assíncrono e imediato não convivem.
• Confundir delete() com drop() no MongoDB. Um esvazia, o outro remove a coleção.
• Tratar o H2 como NoSQL. É relacional, embarcado, escrito em Java.
• Chamar o Elasticsearch de ferramenta SQL. REST e JSON, sobre Lucene, e cada shard é um índice Lucene inteiro.