NoSQL em concursos públicos: o que estudar e como as bancas cobram o assunto

Durante muitos anos, estudar banco de dados para concursos significava conhecer tabelas, relacionamentos, normalização, linguagem SQL e propriedades ACID. Esses assuntos continuam importantes. O problema é que, atualmente, os editais também incluem arquiteturas distribuídas, grandes volumes de dados, aplicações em nuvem e bancos NoSQL. Para quem se prepara para concursos de tecnologia, ignorar essa parte pode custar pontos valiosos.

A primeira dúvida costuma ser a mais óbvia: o que significa NoSQL?

Embora a expressão possa sugerir “sem SQL”, a interpretação mais comum é Not Only SQL, ou seja, “não apenas SQL”. O termo abrange diferentes sistemas de gerenciamento de dados que não se limitam ao modelo relacional tradicional. Isso não significa que esses bancos sejam incapazes de realizar consultas ou que todos rejeitem estruturas organizadas. Significa apenas que adotam abordagens diferentes para representar, armazenar e distribuir informações.

O crescimento das aplicações digitais ajudou a impulsionar essas soluções. Redes sociais, plataformas de comércio eletrônico, serviços de streaming e sistemas públicos podem gerar enormes quantidades de dados, muitas vezes com estruturas variadas e necessidade de respostas rápidas. 

Nesses cenários, determinados bancos NoSQL oferecem vantagens relacionadas à flexibilidade, à distribuição dos dados e à escalabilidade.

E aqui aparece um conceito muito cobrado: escalabilidade horizontal. Em vez de ampliar indefinidamente a capacidade de uma única máquina, adicionando mais memória ou processamento, é possível distribuir a carga entre diferentes servidores. Esse processo pode envolver particionamento dos dados, conhecido como sharding, e replicação para aumentar a disponibilidade. Mas cuidado: escalabilidade horizontal não é exclusividade absoluta de bancos NoSQL, nem todo sistema NoSQL possui exatamente as mesmas características.

Outro aspecto recorrente é a flexibilidade do esquema. Em muitos bancos não relacionais, os registros não precisam apresentar todos os mesmos campos, permitindo acomodar informações heterogêneas. Imagine um cadastro de produtos: um notebook pode ter atributos como memória e processador, enquanto uma geladeira possui capacidade e classificação energética. Essa flexibilidade, entretanto, não significa ausência de organização, validação ou governança.

Os bancos chave-valor utilizam uma estrutura simples: uma chave identifica determinado valor. Pense em um identificador de sessão associado às informações de um usuário ou em uma chave vinculada a um conteúdo armazenado temporariamente. Esse modelo é bastante utilizado em cache, gerenciamento de sessões e consultas diretas. O banco de dados Redis é um exemplo frequentemente mencionado em provas, embora seus recursos vão além de um armazenamento elementar de pares chave-valor.

Já os bancos orientados a documentos armazenam informações em estruturas semelhantes a JSON, geralmente permitindo documentos com campos diferentes dentro de uma mesma coleção. O MongoDB é o exemplo mais conhecido. Em uma questão, a banca pode apresentar um cenário envolvendo catálogos de produtos, cadastros variados ou informações aninhadas e perguntar qual modelo oferece maior flexibilidade. Nesses casos, o armazenamento orientado a documentos costuma ser uma alternativa relevante.

Também existem os bancos de colunas largas, organizados de maneira adequada a determinados cenários de distribuição e grande volume de dados. O Apache Cassandra é um exemplo bastante cobrado. Atenção para não confundir esse modelo com qualquer banco que utilize colunas: sistemas relacionais também organizam informações em colunas, mas isso não os transforma automaticamente em bancos NoSQL de colunas largas. 

Nos bancos orientados a grafos, o foco está nas relações. Os dados costumam ser representados por nós, arestas e propriedades, favorecendo análises de conexões entre pessoas, empresas, transações ou outros elementos. O Neo4j é um exemplo conhecido. Uma aplicação prática seria identificar redes de relacionamento entre fornecedores, sócios e agentes públicos para investigar possíveis vínculos relevantes em uma auditoria.

Quando o assunto avança, entra em cena o teorema CAP. Em linhas gerais, ele trata de três propriedades de sistemas distribuídos: consistência, disponibilidade e tolerância ao particionamento. A pegadinha está em repetir mecanicamente que um sistema “sempre escolhe duas das três”. A interpretação mais precisa é que, diante de uma partição de rede, o sistema precisa lidar com uma escolha entre manter determinadas garantias de consistência e preservar a disponibilidade das respostas.

A consistência eventual também aparece com frequência. Nesse modelo, diferentes réplicas podem apresentar divergências temporárias, mas tendem a convergir quando as atualizações se propagam e não surgem novas alterações. Isso pode ser aceitável em determinadas aplicações, como contadores de visualizações, mas inadequado em outras que exigem confirmação imediata e rigorosa. O ponto central é compreender que a escolha depende dos requisitos do sistema.

Outro contraste bastante explorado pelas bancas envolve ACID e BASE. ACID representa atomicidade, consistência, isolamento e durabilidade, propriedades tradicionalmente associadas às transações. BASE reúne a ideia de disponibilidade básica, estado flexível e consistência eventual. Entretanto, seria incorreto afirmar que todo banco NoSQL rejeita transações ou que nenhum deles oferece garantias consistentes: sistemas modernos podem disponibilizar recursos transacionais, e as características variam conforme o produto e sua configuração.

No setor público, bancos NoSQL podem ser empregados no armazenamento de registros de eventos, documentos, dados de sensores, informações geográficas e relacionamentos complexos. Isso não significa abandonar bancos relacionais. Muitas arquiteturas utilizam persistência poliglota, combinando tecnologias diferentes conforme a necessidade: um banco relacional para transações financeiras, um banco documental para cadastros flexíveis e um banco de grafos para analisar vínculos, por exemplo.

Para estudar NoSQL para concursos, priorize os quatro modelos principais (chave-valor, documentos, colunas largas e grafos), associando cada um às suas características e aplicações. Depois, revise escalabilidade horizontal, replicação, sharding, consistência eventual, teorema CAP e diferenças entre ACID e BASE. Mais do que decorar nomes de ferramentas, procure entender qual solução faz sentido em cada cenário. É justamente aí que as bancas costumam separar quem apenas reconhece a terminologia de quem realmente compreende o assunto.