Questão de Banco de Dados — Banco de Dados Paralelos e Distribuídos — FURB 2025
Banco de Dados›Banco de Dados Paralelos e Distribuídos
Código
qg497145
Banca
FURB
Órgão
Prefeitura de Florianópolis - SC
Ano
2025
Nível
Superior
Cargo
Auditor Fiscal de Tributos Municipais - Tecnologia da Informação - 2º Dia
Sistemas de banco de dados NoSQL do tipo chave-valor distribuído são frequentemente utilizados em ambientes que priorizam alta disponibilidade e escalabilidade horizontal. Para isso, muitos desses sistemas permitem que o desenvolvedor escolha entre diferentes modelos de consistência para equilibrar latência, disponibilidade e precisão dos dados. Considerando um cenário no qual a prioridade é minimizar a latência de leitura, mesmo que isso implique retornar dados possivelmente desatualizados, assinale a alternativa a seguir que apresenta o modelo de consistência mais adequado:
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Sistemas NoSQL e Modelos de Consistência
Gabarito: Letra D. Em bancos de dados NoSQL distribuídos, quando o objetivo é minimizar a latência de leitura, aceitando dados possivelmente desatualizados, o modelo de consistência mais adequado é a consistência eventual (eventual consistency). Esse modelo, alinhado ao Teorema CAP, sacrifica a consistência imediata em favor da disponibilidade e da tolerância a partições, permitindo respostas rápidas mesmo que nem todos os nós estejam sincronizados.
A questão cobra o entendimento do trade-off entre consistência e desempenho em sistemas distribuídos, tema central do Teorema CAP (Consistência, Disponibilidade, Tolerância a Partição). Para baixa latência, modelos de consistência forte (como strong consistency ou linearizability) são contraindicados, pois exigem sincronização entre nós, aumentando o tempo de resposta.
Alternativa A — ❌ Incorreta
A consistência forte (strong consistency) garante que todos os nós vejam os mesmos dados a todo instante, mas isso exige coordenação que aumenta a latência. Não atende ao requisito de baixa latência.
Alternativa B — ❌ Incorreta
A consistência causal (causal consistency) preserva a ordem das operações causalmente relacionadas. Embora mais relaxada que a forte, ainda impõe alguma sincronização que pode elevar a latência, não sendo a mais adequada para o cenário descrito.
Alternativa C — ❌ Incorreta
A consistência de sessão (session consistency) garante que, dentro de uma mesma sessão, o usuário vê suas próprias atualizações, mas não oferece a mesma flexibilidade de baixa latência que a consistência eventual.
Alternativa D — ✅ Correta ⟵ GABARITO
A consistência eventual (eventual consistency) permite que, após um período sem novas atualizações, todos os nós converjam para o mesmo valor. As leituras podem retornar dados desatualizados, mas são extremamente rápidas, pois não exigem confirmação de outros nós. É a escolha ideal para sistemas que priorizam disponibilidade e baixa latência.
Alternativa E — ❌ Incorreta
A consistência linearizável (linearizability) é um modelo forte que torna as operações instantaneamente visíveis para todos, como se houvesse um único sistema de tempo real. Isso implica alta latência e não se alinha ao cenário.
PEGA ESSA DICA!
Lembre-se do Teorema CAP: para minimizar latência, você está no lado AP (Availability + Partition Tolerance) e abre mão da Consistência forte. A consistência eventual é a manifestação prática desse trade-off.